5 Things You Should Never Say (or Do) During Sprint Planning

Many years ago, a friend of mine once told me: “Sometimes the best way to find what works for your team is to avoid making basic mistakes”. At the time, I didn’t think much about it, because I was at a point in my life where I lived in the moment and did not think about long-term ramifications of my decisions. Now that I’m older and hopefully wiser, I realize that whenever we learn something new, avoiding making mistakes can often be an effective method of adapting and gaining true understanding of a new skill, assuming you are learning from those mistakes of course.

Scrum is one of those skills that require a lot of experimentation and reflection, because it offers a lot of freedom – arguably too much freedom – for teams
to apply this framework. From my experience working with teams trying to learn Scrum for the first time, there are a few basic, common errors that should be avoided; although not making these mistakes does not necessarily guarantee success, I feel that it will certainly improve your odds in a meaningful way.
Let’s take a look at possibly the most important Scrum event, Sprint Planning, and explore a few common mistakes. As the first event for the Sprint, the Sprint Planning sets the tone for the entire team, which is why it is critical for the team to start on the right track.

Sprint Planning During your Sprint Planning, you should NEVER…

1. “Volunteer” team members for specific work items – Scrum encourages teams to self-organize which means the team should avoid the temptation of assigning work to team members. The team should collectively own the backlog, even if specific individuals may take lead on some tasks for which they have more familiarity. To avoid this, encourage pair-work and collaboration, which will help the team develop generalizing specialists who can take on a variety of tasks.
2. Show up with no backlog items prepared – If the team has not invested time to refine the backlog in preparation for the Planning event, this can often lead to an extended planning session which often creates frustration for the team. To prevent this situation, the team should be mindful and consistent about executing Backlog Refinement sessions prior to the start of the next Sprint so that there are work items which are ready to be planned.
3. Say “Let’s try to do more points this Sprint!” – Pushing for more productivity from a Scrum team., unless it is driven internally by the team and based on logical reason, is a risky proposition that will often lead to unintended behavior and consequences. If the team is able to deploy efficiency-improvement changes (such as automation), then it is fair to expect higher output. If this is not the case, pushing the team to produce more work will likely lead to low morale and/or story-point inflation which adds no benefit whatsoever.
4. Establish “points per person” capacity limits for the sprint – Story points are designed to be used for the entire team to estimate work, and not intended to establish individual capacity limits. Doing so will not only break down the entire concept of Story Points, but create illogical constraints and silo team members. Avoid doing this at all cost!
5. Say “We don’t need to estimate work in hours since we are already doing estimation in points” – Many new Scrum teams that I have coached choose to only estimate work in Story Points, which limits their ability to adequately assess their team capacity. Once the team has formed the initial Sprint Backlog with a collection of work items that the team would like to focus on for the Sprint, the team will benefit greatly by breaking down the work items into subtasks then assigning ideal work hours to each subtask. This technique enables the team to verify that specific team members have the bandwidth to accomplish these work items with the given Sprint. Without estimating at this level, teams will not be able to gain confidence in their plan because the amount of work may significantly exceed the team’s capacity.

In closing, there are many ways to plan a Sprint, which means there are many ways to fail. Consider the tips I have shared and see if your team can avoid making one or two of these. Over time, your team will learn how best to approach Sprint Planning and achieve long-term, sustainable success.

Eugene Lai