5 Things You Need to Stop Doing at the Sprint Planning

The Sprint Planning meeting is a critical Scrum event that establishes the team’s goal for a sprint and sets the path towards success. There are many potential issues that teams may encounter during this event. I would like to share a few of these pitfalls that should be avoided, which should improve your team’s probability for a successful outcome.

1. Ask Product Owner to decide how much work to commit – Within a Scrum team, the team is accountable for delivering value consistently, and the team is expected to collectively decide how much work they can commit to doing in a given sprint. If the Product Owner dictates the amount of work that the team should do, the autonomy is broken and the team will be unable to self-manage, which impedes innovation. With support from the Product Owner, entrust the team to choose the maximum amount of value they feel confident in delivering for the sprint.
2. Plan more work than the team can complete – Some organizations believe that teams need to be pushed to the limit in order for them to deliver the desired results. This is a counter-productive line of thinking that goes against the philosophy of Scrum, which is that we trust the team to decide how much they can do. Pushing the team to do more than they are capable of will more than likely lead to extra stress and more errors or defects, which in the long run can lead to burn-out or added cost from rework. Avoid the temptation to “challenge your team”, but rather, encourage and inspire them to do their best work where possible.
3. Assign story point capacity for each team member – The concept of Story Points is one of the most mysterious and misused techniques in Agile development. The key thing to keep in mind is that Story Points is a team-level concept instead of an individual measure. Many teams make the mistake of establishing team-based capacity using story points, which is meaningless and creates confusion. Capacity at the individual level can and should be utilized using ideal hours (see next item below for detail).
4. Use only Story Points to evaluate workload – Many teams mistakenly feel that as long as they plan the correct number of Story Points for a sprint based on historical team performance, they have a high chance of successfully completing the committed work. This is simply not true. The fact is that two 5-point stories could end up being significantly different in terms of the amount of effort required due to complexity and uncertainty. A common technique to verify that the team has an achievable plan is to take one step further – decompose stories into subtasks and apply ideal-hour estimation to each subtask. While this may seem arduous and excessive, my experience has demonstrated that this technique offers a significant return on investment due to the ability to validate the original assumptions about the story through a more detailed analysis of the specific work that must be executed to successfully complete a story.
5. Assign work to team members – Scrum values self-management which means team members should be motivated to take on tasks to which they want to contribute. Many teams follow a standard practice of having single owners for stories/tasks which erodes the team’s ability to collaborate and establish collective ownership of the outcome.

In short, the key thing to remember during Sprint Planning is to empower your team to work together and come up with the best plan, with the understanding that the team will inspect progress and make adjustments to the plan as they learn more about the problem domain as well as the solution they need to produce. The plan need not be perfect, but it should be realistic and achievable based on the team’s opinion. Launching the sprint on the right note will go a long way towards setting the right tone and positive morale for the team.

Eugene Lai