3 Warning Signs That Your Sprint Planning Is Failing, and 3 Ideas to Fix It

If your Scrum team is struggling to consistently meet it’s Sprint Goals, there could be a number of potential causes for this symptom. One of the common issues is poor planning, but how do you know if this is the source of subpar performance? There are a few basic signs that you may wish to watch for in order to determine if the team has been effectively planning their work. I would like to share a few of these seemingly benign situations because they may seem harmless, yet secretly creating havoc for your team. Take a quick look and see if your team is engaging in these behaviors, then you can decide how to address them.

Warning sign #1 – Tasks are assigned to individual team members before the meeting

Many teams try to avoid spending “too much time” in meetings, largely because they prefer to be doing “real work”. They feel that they can save time during Sprint Planning by getting a “head start” and pre-assign work to team members before the meeting. While this may sound logical, this is actually counterproductive behavior that erodes self-management. Within a Scrum team, we would like to encourage self-organization and collective ownership of the work, which means the team as a whole should work together to decide the best approach to finish the work while meeting the Sprint Goal. If someone, likely the Product Owner or the Scrum Master, chooses tasks or work items for specific people, this process reduces accountability and potentially stifles learning.

A better approach is to collectively discuss all of the work at the Sprint Planning event so that the team can determine who might be the best equipped to work on a specific deliverable; note that we should not assume that this may always be the person with the most knowledge of the task, or involve only a single team member.

Warning sign #2 – Product Owner is consistently absent

Is your Product Owner a very busy person who rarely attends most of your team’s collaboration events? If so, your team is not unique. Most teams struggle to gain sufficient level of support from their Product Owners because he/she has a “day job”; this is one of the biggest risks that a Scrum team must manage. If your Product Owner is consistently absent from your Sprint Planning, this means that more than likely, your team is making assumptions on what they feel are the most important work items to focus on, which drives the formulation of the Sprint Goal. In addition, this may also mean that Acceptance Criteria and boundary conditions for specific work items will be left to the team members to figure out, which can add significant risk without direct guidance from the Product Owner.

What can you do about this? While the Scrum Guide does not support this technique, many teams in this situation tend to rely on a proxy to carry out the vision of the Product Owner. I must caution you against this approach because in my experience, this usually does not lead to a high degree of success. A better approach would be to establish a team norm with the Product Owner to ensure he/she understands the role clearly and is able to support it adequately.

Warning sign #3 – Capacity for individual team members is computed in units of Story Points

Recently, I have encountered a few Scrum teams that choose to manage individual capacity using Story Points as part of their Sprint Planning process. While this technique is based on good intentions, it creates a number of issues for the team that has rippling effects that will likely hamper the overall performance of the team. Misusing the concept of Story Points will typically lead to individualization of work (instead of collective ownership). Also, it is often inaccurate at best which eliminates the initial purpose of capacity planning. Lastly, this will likely result in a lack of accurate velocity metrics which makes future planning and forecasting even more challenging.

The approach I recommend is to use Story Points at the team level for tracking team productivity and establish capacity limits for individual team members using ideal hours. For example, if Joe is only available during a given Sprint at 50% capacity due to other commitments or vacation, etc., his capacity would be 40 hours for a 2-week Sprint; you may also apply other adjustments for administrative overhead if desired. Then, you would decompose all stories that have been planned for the Sprint into subtasks, each estimated using ideal hours and mapped to individuals who are expected to do the work. By aggregating the total work hours at the subtask level, you can determine if any team member is either overloaded or underloaded for the Sprint.

In closing, the Sprint Planning meeting is the official launch of a new Sprint, which means it will set the tone for that entire Sprint. If done properly, the team can put itself on the path towards success. Watching out for the common mistakes will help the team become more mindful of its current techniques and also help them incrementally improve over time.

Eugene Lai