3 Things to Stop Doing During Sprint Planning

Share on facebook
Share on twitter
Share on linkedin
Share on email

In Scrum, sprint planning lays the groundwork for how successful—or unsuccessful—an upcoming sprint will be.

When done correctly, sprint planning should give Scrum teams a clear vision of the sprint goal and what needs to be done to achieve it. The problem is, many Scrum teams waste a lot of time during sprint planning; and, worse yet, they often invest time in activities that won’t lead them to a successful product increment delivery.

To make your sprint planning more effective, here are three things you need to stop doing:

Resizing Carry-Over Product Backlog Items (PBIs)

When work is carried over from one sprint to the next, teams often spend a lot of time trying to resize the PBI(s) to accommodate remaining work—but they shouldn’t.

Your team’s velocity, or the sum of story points completed each sprint, is an average. When accurate, velocity helps inform how much of the product backlog a team might expect to deliver during a sprint. But if you resize incomplete work, velocity becomes distorted and less predictable; specifically, your prior sprint’s velocity will be increased by however many story points you take “credit” for. This makes it look like more of the product backlog was included in the product increment than was actually built.

Velocity should be a measure of the rate of delivery—not a measure of how much effort you put into the sprint. When you finish the story, count it toward the velocity of the sprint in which it was completed. And, rather than resize incomplete work, focus on improving your delivery of PBIs to increase consistency. Build trust with your stakeholders by regularly delivering a product increment consistent with the sprint goal. Limit incomplete work so that your velocity becomes an accurate reflection of the quantity of product backlog the team delivers.

Assigning Tasks

The word “assigning” should be a red flag in sprint planning. Scrum teams are designed to be self-organizing, so stop assigning and start seeking volunteers. This protects the team members who already have a heavy workload while ensuring other team members have enough to work on during the sprint.

Keep in mind that you will never know exactly when someone will complete their work; otherwise, waterfall methods would be more successful. At the end of sprint planning, your team should have a plan that is “good enough” to get them started, but still adjustable. Save the micro-planning for the daily scrum, which gives team members the chance to be transparent about impediments and prioritize their work based on how it aligns with the sprint goal.

Lastly, and most importantly, assigning work strips team members of their autonomy. And, as popularized by Daniel Pink, autonomy is one of the three keys to high performance. Allow your team members to actively participate in deciding how they will contribute to the sprint goal.

Filling Up the Entire Capacity of the Team

By nature, humans are bad at estimating future events and how much time is actually needed to accomplish a goal. You can blame the Planning Fallacy, which explains our innate, overly optimistic prediction of how quickly we can complete a task.

Occasionally, you’ll see the Planning Fallacy in action during sprint planning. Some Scrum teams will feel the need to fill the entire capacity of the team with work, with expectations that it will all get done. However, this is a recipe for disaster if unforeseen problems arise: What if a task takes longer to complete than estimated? What if critical operational issues or bugs come up? How likely is it that a team member will get interrupted by a request that you can’t yet anticipate? Will somebody’s child get ill? Will there be additional meetings that people cannot avoid? The chances of each of these specific scenarios might be small, but aggregate these possible issues with other possible slow-downs, and planning your full capacity will result in an unworkable plan.

We don’t live in a perfect world, so Scrum teams shouldn’t plan as if we do. Instead, plan with a moderate margin of safety; give your teams a set percentage of time to adapt to these changes without sacrificing the completion of their work.

The moral of the story is this: Though you may want precision, you should get used to embracing ambiguity during sprint planning. It’s acceptable to move forward with a “good enough” plan, versus a precise plan that’s wrong. After all, this is the very core of agile—planning, acting and then iterating.

Looking for more ways to cultivate a successful Scrum team? Get advice and insights on all things agile by visiting our blog.

Stay Up-To-Date