Failing to complete stories during sprints will happen in every Scrum Team, even in High Performing Teams. Not because of lack of motivation or laziness. It is because of the nature of working in an uncertain environment.
If your teams fail again and again to deliver, you risk not being able to adapt to changes in the market quickly, because excessive undone work is building up.
Stakeholders will lose trust in your team and the ability to deliver working software predictably. But that is what your stakeholders want:
Your stakeholders want some sort of predictability in an uncertain environment.
If your team can deliver predictably, your team will gain trust from their stakeholders and can avoid having unwanted conversations about justifying why their sprints are failing.
Here are 5 common reasons (and how to avoid them) why Scrum Teams fail to complete stories during the sprint:
Your User Stories Are Too Big
The bigger your stories are, the higher the risk of non-completion. Think about the following situation:
If 100 customers arrive at the same time in a restaurant then the waiting staff and kitchen won’t be able to cope. This will result in huge queues, long waits, and unhappy customers.
On the other hand, if customers arrive in smaller groups, there will be enough resources available to complete each order in a good time. The same applies to your User Stories (or backlog items).
👍 Rule of thumb: Aim for sizes of approximately 1/10 to ⅙ of the team’s velocity.
Not Allowing a Buffer
If you are not allowing a buffer during Sprint Planning, everything needs to work exactly as you planned. Without some bandwidth you can not deal with unexpected findings:
- absence of team members due to illness
- unknown complexity
- external dependencies
- bugs on production
👍 Rule of thumb: Aim for 20% buffer during Sprint Planning.
Not Handling External Dependencies
Allowing a buffer alone, won’t help you, especially for external dependencies. They are everywhere, and most of the time it is not possible to eliminate those dependencies. Image a sprint where you finished almost everything to close your Story but at the finish line, some external blocking issues occur.
👍 Suggestion: Tackle the User Stories with the highest risk and most dependencies at the start of the Sprint. More often than not, you find a way to complete a story despite some blocking issues occur.
Not Having a Plan on How to Achieve the Sprint Goal
Let’s face it: Writing Jira sub-tasks does not help you get a plan for achieving your Sprint Goal!
What you want is a kind of map on how your team will achieve the sprint goal. Think about the kind of map your parents used for their road trip, when they were young. (I know you would use Google Maps, so I need to find another metaphor here).
👍 Suggestion: Draw your plan on how to achieve the sprint goal like a map. Mark risks and dependencies. Identify steps and mini-milestones for achieving the sprint goal.
Lack of Focus in Daily Scrum Meeting
Instead of talking about who worked on what yesterday, focus on what needs to be done to satisfy the Sprint Goal. What kind of work is at risk of not being completed? What kind of dependencies and blockers arose?
👍 Suggestion: Drop the “famous” 3 questions (What have I done?, What will I do?, Do I see any impediments?) and answer the following questions for every story:
- What needs to be done?
- What work is at risk of not being completed?
- What dependencies and blockers we have to deal with?
Try to aim for a sprint completion rate of approximately 80%. If you manage to finish 8 out of 10 times all items you planned during Sprint Planning consistently over a long period, your team will be able to produce value predictably, and gain trust from their stakeholders and organization.
If you can’t measure it, you can’t improve it.Peter Drucker
👉 Action Items:
- Calculate your team’s sprint completion rate (=number of completed sprint / total number of sprints)
- Pick one of the issues from the list above your team can benefit the most and suggest your team working on it.