Is Your Team’s Sprint Planning Broken?

Scrum is a framework that operates in a rhythmic cadence called “sprints,” which are fixed length increments of time. While the length of Sprints may vary from one team to team, every Scrum team repeats the same pattern of events in the same order. First a sprint planning meeting. Then short daily Scrum meetings. And finally ending with a sprint review and a retrospective.

The first of these, sprint planning, is a significant discussion involving the whole team where members decide what increment of value they intend to deliver over the course the sprint. Then, they decide how they plan to do it. But when a team misunderstands the goals or basic mechanics of this meeting, it’s unlikely that they’ll realize the potential of the Scrum framework.

Are Your Sprint Planning Meetings Working?

If any of these signals sound familiar, then something is likely broken:

1) It takes too long. A Scrum team should be able to complete planning in a total of 8 hours if they’re doing month-long sprints. It should take less time for shorter sprints. For example, it should take no more than 4 hours for a team doing 2-week increments. If your sprint planning meetings feel like they’re taking too long, that’s usually a clue that the team is also trying to cram in discussions that should’ve already happened.

2) The wrong people are there. The team’s Product Owner, Scrum Master, and Developers should all be present and participating. Any non-team members invited are there primarily as listeners. If only one person is representing and making choices for the rest of the team, we’re often missing important views and experiences. That goes double for cases where those choices are being driven by folks outside of the team.

3) It’s mostly about whether individual Developers have enough tasks. The goal of the meeting is to decide, as a team, an objective for the next Sprint that will deliver value and ensure we have a feasible plan for meeting that goal. If instead the focus is on, “Does each Developer have 40 hours of tasks to do each week?” and the team is swapping out backlog items to based on utilization instead of product value, that’s a sign that the team is focused on output instead of outcomes.

4) You’re trying to figure out what backlog items mean. Conversations about product backlog items in sprint planning are mostly confirmatory (making sure we still have the same understanding of what the item is and ‘done’ means), rather than exploratory. If sprint planning is generally the first time the team discusses the fundamentals of a backlog item, that generally means the team doesn’t have effective backlog refinement happening prior.

5) It’s not a conversation. Sprint planning is a series of three negotiations among the team about a short-term goal and their plan to meet that goal. But what if your planning meetings are less collaborative and more about taking direction from a manager or the team’s Product Owner? That may mean that the people with the technical expertise to do the work aren’t being allowed to own how the work will be done.

So, what does a healthy sprint planning meeting feel like? While we call it a ‘meeting,’ it’s really three separate conversations, each with a specific purpose that informs the next: why, what, and how. In these conversations, each of the three responsibilities on the team represent a specific point of view.

“Why?”

Sprint planning starts with the “why” conversation. This is a negotiation between the team’s Product Owner and Developers where they decide their Sprint Goal. The Sprint Goal is an overarching, pass/fail objective that helps the team focus on the single most important thing to achieve during the sprint. This conversation is a negotiation between the team because the Product Owner can’t dictate a goal that the Developers don’t feel is possible. Likewise the Developers can’t dictate a goal that doesn’t result in some form of value. The Scrum Master coaches this conversation to be rooted in practicality and shared understanding by all members of the team.

“What?”

Once the team has agreed on a sprint goal, they then move into the “what” conversation. This is a negotiation of which product backlog Items will be completed in order to meet the sprint goal. In this conversation, the Product Owner owns questions of priority and value. The Developers own questions of backlog item size (the effort, complexity, and risk to complete an item) and likely the (how many backlog items might be reasonable). The Scrum Master coaches this conversation to be rooted in a practical understanding of sprint capacity, backlog item estimation, and a shared understanding of what ‘done’ will mean for each item.

“How?”

And once the ‘what’ has been agreed to, the team shifts in the third and final negotiation: the “how” conversation. This is typically just between the Developers, wherein they discuss each product backlog item they’ve agreed to complete during the sprint. Then, they break each item down into tasks. Tasks are small (not more than a day in duration, though typically much smaller), finite efforts that will contribute to a completed product backlog item. Product Owners don’t typically have much input during this last conversation, though they should still be available to Developers in case a question about a backlog item comes up.

Developers may also discover that one of the intended product backlog items is significantly bigger or smaller than originally thought. If so, they may need to revisit the “what” conversation with their Product Owner. The Scrum Master coaches the “how” conversation to make sure that every Developer’s voice is being heard during the task breakdown. At the completion of this conversation, the team has produced their “sprint backlog” for the next iteration. This consists of the sprint goal, the product backlog items they’ve agreed to complete, and the tasks the Developers feel are necessary to achieve them.

What Can You Do if Your Meetings Aren’t Working?

Don’t despair. There’s a couple of immediate steps organizations and leaders can take to get out of these anti-patterns.

Up Your ScrumMaster’s game.

Scrum is often described as ‘e asy to learn, hard to master.” That’s absolutely true! Many of the problems discussed here are easy traps to fall into as a new and inexperienced ScrumMaster. Getting them more high-quality training like an Advanced-Certified ScrumMaster (A-CSM) or Certified Scrum Professional – ScrumMaster (CSP-SM) course is a great way to expand their skillset.

Bring in an Agile Coach.

One of the most valuable services provided by a seasoned Agile Coach is mentoring Scrum Masters and creating a path for organizations to grow and develop ScrumMastering as a career. Great Agile Coaches can model key behaviors and teach core skills without undermining the position of your ScrumMasters.

Grow Agile Leaders

Sometimes these behaviors are the result of outside pressure. Nurturing Agile leadership can create an environment where managers and executives understand the best way to support Agile teams and Agile-based value delivery. Certified Agile Leadership training is a great place to start. Individual or cohort-based leadership coaching can also cement the practices and mindsets needed to get the most out of your Agile teams.