Sprint planning is the scrum event that kicks off the sprint. The purpose of sprint planning is to define what can be delivered in the sprint and how this work will be achieved. Sprint planning is done in collaboration with the entire scrum team.
Many years ago, a friend of mine once said to me, “Sometimes the best way to find out what works for your team is to avoid making basic mistakes”. I didn’t think much of it at the time because I was at a point in my life where I lived in the moment and didn’t think about the long-term consequences of my decisions. Now that I’m older and hopefully wiser, I realise that whenever we learn something new, avoiding mistakes can often be an effective method of adapting and gaining a true understanding of the new skill, provided of course you learn from those mistakes.
Scrum is one of those skills that requires a lot of experimentation and thought because it offers teams a lot of freedom – probably too much freedom
apply this framework. From my experience working with teams trying to learn Scrum for the first time, there are a few basic, common mistakes to avoid; while not making these mistakes doesn’t necessarily guarantee success, I feel like it will certainly improve your chances in a meaningful way.
Let’s take a look at perhaps the most important Scrum event, sprint planning, and explore a few common mistakes. Sprint planning as the first event for the sprint sets the tone for the entire team, so it’s important to get the team off to a good start.
Sprint Planning During sprint planning, you should NEVER…
“Volunteer” team members for specific work items
Scrum encourages teams to self-organize, meaning the team should avoid the temptation to assign work to team members. The team should collectively own the backlog, although specific individuals may take the lead on some tasks with which they are more familiar. To avoid this, encourage pair work and collaboration to help the team develop generalizing specialists who can take on different tasks.
Show up without a ready backlog
If the team hasn’t invested time in improving the backlog in preparation for the planning event, this can often lead to an extended planning session that often leaves the team frustrated. To avoid this situation, the team should be considerate and consistent in conducting Backlog refinement sessions before the start of the next sprint so that the work items are ready for planning.
Say, “Let’s try to make more points in this sprint!” –
Pushing for higher productivity from the Scrum team, unless driven internally by the team and based on a logical rationale, is a risky proposition that will often lead to unintended behaviour and consequences. If the team is able to deploy efficiency-enhancing changes (such as automation), then it is fair to expect higher performance. If not, the pressure on the team to produce more work is likely to lead to low morale and/or story point inflation, which does no good.
Set “points per person” capacity limits for the sprint –
Story points are designed to be used by the entire team to estimate work, not to set individual capacity limits. Doing so will not only break the entire concept of Story Points, but create illogical limitations and silo team members. Avoid it at all costs!
Say, “We don’t need to estimate work in hours because we already estimate in points”
– Many new Scrum teams I’ve coached choose to only estimate work in Story Points, limiting their ability to adequately assess their team’s capacity. Once the team has created an initial Sprint Backlog with a collection of work items the team would like to focus on in the Sprint, the team will benefit greatly from breaking the work items into sub tasks and then assigning ideal work time to each subtask. This technique allows the team to verify that specific team members have the bandwidth to complete these work items with a given sprint. Without an estimate at this level, teams will not be able to gain confidence in their plan, as the amount of work may well exceed the team’s capacity.
In conclusion, there are many ways to plan a sprint, which means there are many ways to fail. Consider the tips I’ve shared and see if your team can avoid creating one or two of them. Over time, your team will learn how to best approach sprint planning and achieve long-term, sustainable success.