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:

• User stories are implemented as described but don’t meet users’ needs or expectations.
• Critical production bugs and issues arise as users cannot complete newly released journeys.
• User stories become blocked mid-development as previously unknown, critical dependencies emerge.
• Features aren’t sufficiently understood, so it is incomplete and often unusable even when all user stories are done.
• 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 a sprint to keep all team members busy.
• User stories, which are too ambiguous to implement, are brought into sprint only to 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 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 becomes outdated by the time the developers start working on the story.
• Data migration required for production release has not been considered or documented.

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

If you are unhappy with your development team, they may need more detailed guidance.

Better software requirements can help with this.