Gnarly behaviours of Scrum teams

I’ve seen some pretty interesting things in the Scrum teams I’ve worked in over the years.

And it’s what makes this work so interesting.

In no particular order, these are the most common issues and behaviours I’ve encountered in scrum teams:

  • User stories are implemented as described, but don’t meet users’ needs or expectations
  • Critical production bugs and issues arise as users find themselves unable to complete newly released journeys
  • User stories become blocked mid-development as previously unknown, critical dependencies emerge
  • Features aren’t sufficiently understood, so even when all user stories are done, the feature is incomplete and often unusable
  • User story acceptance criteria is missing or incomplete
  • Integration test scenarios for end-to-end journeys is missing or incomplete
  • Developers don’t know what they should be working on
  • Developers add their own stories to the current sprint to account for their daily tasks
  • Developers proactively add “As a developer I want…” stories to the backlog for the PO to consider
  • Team members regularly run out of planned work mid-sprint
  • Expecting to carry over incomplete stories from sprint to sprint becomes standard practice
  • User stories have remained ‘in progress’ for many multiple sprints
  • Difficulty knowing how much work to bring into sprint to keep all team members busy
  • User stories, which are too ambiguous to implement, are brought into sprint only to then become blocked and require additional refinement
  • User stories are UI-specific, often oriented around a given page or specific control, rather than end-to-end journeys that could be potentially shippable
  • Flat UI designs dictate implementation, but the designers have not considered edge cases and non-happy paths
  • User stories contain too much technical detail, which is then out of date by the time the developers start working on the story
  • Data migration required for production release has not been considered or documented

Reassuringly, all of these behaviours can be improved upon or completely replaced with better alternatives, team willing.

Frank Ray Consulting. Software requirements for agile development teams, particularly distributed, remote and offshore development teams working in financial services.

Get in touch if you need our help