My Top 3 Sprint Planning Mistakes
The top 3 mistakes I have observed in Sprint Planning events.

The expected outcome of Sprint Planning is that the developers are highly confident that they can successfully deliver in a single sprint the functionality they select to populate their Sprint Backlog. In my experience I have observed many reasons why Sprint Planning fails to realize this expected outcome. The three Sprint Planning mistakes I discuss below are the ones I have found most common. The Remedies I suggest are not as common.
Sprint Planning Becomes a Marathon
I have observed many Scrum teams in which Sprint Planning required an entire day or more. This is frustrating for everyone, and for these teams the proper outcomes of Sprint Planning became blurred and were lost in their marathon sessions.
Remedies
First, accept that lengthy Sprint Planning is a symptom of diminished discipline and focus. Are you, as a Scrum Master, allowing the team and Product Owner to ignore the rules of engagement for Sprint Planning? Has the Product Owner failed to provide adequate, or any, story acceptance criteria or other scope and quality criteria? Was the Product Owner totally unprepared for Sprint Planning? Is the team spending hours in the session discussing minute details of how they will design and implement the stories? Are the stories they are reviewing not properly defined? Are the acceptance criteria of the stories unclear or missing?
Second, is the marathon a result of the Scrum team skipping regular Product Backlog Refinement? Refinement is the best therapy to yield shorter Sprint Planning sessions. If you are not holding Refinement sessions, start now. If you have only one Refinement session per sprint and you are having marathon Sprint Planning sessions, consider holding a Refinement session every week so the team can take multiple, smaller cuts at understanding the stories in the Product Backlog.
Story Will Take the Entire Sprint
Stories should be completed within a single sprint. Quite often a team will know that a story will span an entire sprint, but they want to pull it into their Sprint Backlog. This raises the risk that they may not complete that story, and this means their commitment to the Product Owner will be unrealized.
Remedies
To minimize the risk associated with a full-sprint story, I have gravitated over time to a new 'guardrail' in story sizing. I guide the developers so they are confident that every story can be completed and accepted by the Product Owner in half a sprint—five days for a ten day sprint. Of course, I sanity check their conclusion with my cycle time metrics on prior sprints. When a story size correlates with this half-sprint duration it provides a risk buffer. If difficulties arise in implementation this buffer offers the team a reasonable hope of still delivering the story by the end of the sprint. This also reduces risk of non-completion when new stories are pulled into the Sprint Backlog while the sprint is already in-flight.
Story Will Not Fit Within a Single Sprint
Some teams need guidance on how to “think small” about their stories. It is not uncommon for an inexperienced agile team to accept into their Sprint Backlog stories—that is, work items that really are features or epics—that will require multiple sprints to deliver.
Remedies
Proper Backlog Refinement sessions should identify very large stories, especially if story sizing is occurring in Refinement. But incorrect sizes may still occur. For any story that you suspect might be too large for a single sprint, you should ask the developers during Sprint Planning to reduce your concern by enumerating the development and testing tasks they will need to complete in order to deliver the story. Assign ideal-hours to each task, and determine the actual time using a conversion factor such as eight ideal-hours equals ten clock hours. Use this capacity metric to determine the feasibility of completing the story within the sprint. Let the team resize the story using this new capacity information. If the size is still too large for a single sprint, then the story should be sliced into smaller sub-stories.
I love working with teams and executives to find effective solutions. Email me at gary@effectivescrummaster.com and let's explore how we might partner on your challenges.
