Sprint Planning from Hell

Imagine Sprint Planning meetings with a team of developers, business analysts, one lonely tester, a Product Owner, and a Scrum Master. They sit for 2+ hours, debating the size of user stories that no one understands. They leave the room with an alleged plan, but no real belief that they can deliver it. They spent all of that time, and left with the feeling that their opinions didn’t matter. The PO and stakeholders told them, “We need these items done by the end of the Sprint. You’re committed, right?”

Variations of this story are so common, it makes me sad. This wasn’t a collaborative planning activity, it was a waste of time. This is the kind of thing that people mean when they say “Scrum (or Agile) in name only”. As usual, the problem isn’t the planning event itself - it’s just acting as the canary in the coal mine. There are many potential causes for why Sprint Planning goes awry.

Poor Product Backlog Refinement

I’ll be blunt. The leading cause of poor Sprint Planning is poor Product Backlog Refinement. When looking for the problem, odds are that you can start here:

• Not enough time was spent refining the candidate items. In Planning, when we don’t understand the items, we can’t commit to them. This is closely related to…
• Not all team members participated in the Refinement session and so they don’t understand the Backlog Items.
• The items at the top of the Product Backlog are too large, making it difficult for team members to commit to them.
• Dependencies, especially on other teams, haven’t been identified.
• The Items are too technically complex, making it unclear for the team how they will build them.

Inadequate Definition of Done

• An unclear Definition of Done means team members can’t agree on the amount of rigour required to finish a Product Backlog Item. (Hint: Definition of Done should cover: how we test the Feature, security, accessibility, usability and …)
• Worse, some teams don’t even have a Definition of Done or, if they do, it’s buried in SharePoint.

Core Planning Problems

• Attempting to estimate the Product Backlog Items in the Planning event​ when that should have happened in the Refinement session.
• No Sprint Goal. Having a clear Sprint Goal makes the rest of the Sprint Planning much easier because it tells the team what they’re working towards.
• Lack of clarity on the priorities in the Product Backlog means the Product Owner won’t be able to articulate a clear Sprint Goal.

Facilitation Issues

• Forgetting to account for small improvements that the team committed to in the last Sprint Retrospective
• Failure to account for unfinished work from the last Sprint (if there is a consistent carryover, that is another problem that needs to be addressed)​
• Planning event is poorly facilitated

Morale and Communication Challenges

• Senior team members dominate Sprint Planning and everyone else is expected to say yes
• Team members don’t ask questions or speak up about concerns because they don’t think they will be listened to
• Team members haven’t taken the time to review the Product Backlog Items before attending Planning
• Lack of engagement from team members, whether in person or remotely​
• Wrong people are in the room​ - some team members are missing​ or some stakeholders are present​

Delivery Pressure

• Pressure from management to go faster
• Pressure from ourselves to go faster for the sake of going faster (we don’t even need management to apply pressure, we do it ourselves)
• Stakeholders trying to override Product Owner priorities
• Commitment based on past velocity without understanding the Product Backlog Items
• Outcome of the Planning session is treated as a hard and fast commitment, not the best forecast we can make at the start of the Sprint

Ironically, going faster is rarely the answer. If we go faster building the wrong thing, we’ve wasted our time and effort. Focus on Outcomes (did we solve a real problem?), not Output (story points).

Technical Debt

• Not taking into account the Drag Effect of Technical Debt. When a team accumulates enough debt, they pay a tax in the form of reduced velocity, meaning, they will get less done then they expect. Worse, the increase in technical debt reduces predictability and increases the risk of bugs.

Why does this all matter?

If we don’t have a good Sprint Planning session, we will have a difficult Sprint. Poor planning leads to mid-Sprint scope changes, reduced throughput (aka velocity), decreased quality, loss of stakeholder confidence, and more. But the good news is that, by now, some of the patterns should start to become clear. Resolving the problems isn’t magic but it does require hard work.