The Secrets of Effective Sprint Planning

“Plans are worthless, but planning is everything.”      — Dwight D. Eisenhower

 Have you experienced any of these challenges in your Agile teams?

• The team regularly takes on more work than they can complete in a Sprint
• Work is removed from the Sprint because it could not be completed
• Quality of the final work is low, with many issues found after the Sprint
• Stories grow in size during the Sprint as more work is discovered
• Arguments erupt on the right approach to getting work done
• Sprints appear to be successful but  the product fails to meet business needs

All of these challenges and more can be traced back to poor Sprint Planning. 

The Basics of Sprint Planning

The moment the team walks into Sprint Planning, the Sprint has started. It is the first thing that happens every Sprint and sets the overall tone. The quality of planning has a direct correlation to the quality of the work to be created. 

Let’s start with a quick primer on the anatomy of Sprint Planning:

Now we’ll unpack some of these to gain better understanding and understand how not doing them could impact your Sprint…

The Most Common Challenges in Sprint Planning

What is it?

The Scrum Guide (2020 edition) explains the Why, What, and How of Sprint Planning as:

• Why is it valuable? (Creating the Sprint Goal.)
• What can be done in the Sprint? (Populating the Sprint Backlog.)
• How will the chosen work get done? (Tasking out the work.)

If any of these go unaddressed in Sprint Planning, this is the first place you might see a breakdown. But there are plenty of other places to look… 

Problem 1: Too much focus on just moving the “tickets”

Here is the most common anti-pattern I see, in poor Sprint Planning:

The team gets together and looks at their Agile tool. They know they can probably do 10 items in the Sprint, so they look at the top 10 “tickets” in the tool and say “Okay, that’s the Sprint. Great job everyone, see you at Daily Scrum tomorrow.” They are done in 30 minutes and are patting themselves on the back for being so efficient.

And then they wonder why they run into many of the issues we opened this article with. 

Problem 2: No Sprint Goal

The term “feature factory” is often heard of with Scrum Teams. They are constantly pulling in work and churning out work without any seeming purpose or focus. Not having a Sprint Goal, a clear “Why does this work matter and how does it fit together” can lead to aimless Sprints that provide little business value.

Problem 3: There is no How

We do Sprint Planning to create alignment which increases the chances of a successful Sprint. This is not just alignment between the Product Owner and the Developers. It is also to create alignment between the Developers. How will we tackle this particular piece of development? How does this story interact with this story? How do we know we are done? How will we test this? How will we demonstrate this? If the team is not asking, and answering these questions in Sprint Planning you are headed for rocky waters.

Who attends?

Many Agile teams treat their events like they are secret Star Chamber meetings requiring a password to enter. The only event that is just for the team is the Sprint Retrospective. Sprint Planning, and every other activity, should follow the first pillar of Scrum: Transparency. 

With Sprint Planning, this is important as it is the last chance to refine and understand the work the team will be doing in the Sprint. Inviting the business stakeholder, to provide greater context, or the Architect, to work through some design questions, can be the difference between a Sprint Review where everyone says “That was awesome!” and one where you hear “That’s not what I wanted” or “You realize that’s not security compliant and you need to redo it?”

How long?

The Scrum Guide says: 

“Sprint Planning is timeboxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.”

Eight hours? That’s an entire day, are you serious?

Let’s do a little math here. A one month Sprint is, on average, 20 days or 160 hours. Eight hours is just five percent of the total time of the Sprint. Five percent…

Now let’s go look at a typical waterfall project. Twenty years ago, the projects I managed were typically 12 months long. The first three months of that project were back and forth between product management and development on exactly what was going to be built with no code being written (for this release) for at least two months. Plus the product managers had been writing requirements documents for at least two months previously.

Twelve months, with two months spent in “planning.” That’s 16 percent of the release spent on planning. And let’s be honest, that’s probably on the low side by a generous margin.

So, yes, eight hours for a one month Sprint. And four hours for a two-week Sprint. This connects back to the “What is it” section above and all the activities that are commonly skipped in Sprint Planning today.

Remember, it’s a maximum time box. If the team gets done early, then the meeting is over. Having four hours blocked out means you have the time if you need it. It is always easier to end early.

Agenda for an Effective Sprint Planning Event

1. Set the Stage: Good Agile Retrospectives bookend the event with a conscious Start and Close. This pattern is also effective in Sprint Planning.

 2. Establish a Sprint Goal: The Product Owner should come to Sprint Planning with an idea for what they want the Sprint Goal to be. Often this is a direct output of the previous Sprint Review. They then work with the team to clarify it and even change it based on feedback from the rest of the team. Read our 5 Steps to creating a Sprint Goal for more on creating an effective Sprint Goal.

 3. Final Refinement and Estimation: While we recommend that your team is regularly conducting backlog refinement, Sprint Planning offers an opportunity for further refinement.

For example, the Developers may have discovered something new with items at the top of the backlog. There may be open questions or there may be a realization that the current estimate is not an accurate reflection of the work to be done. 

Next, remember that the Product Backlog is dynamic and emergent. New items can shoot to the top of the backlog overnight. The Product Owner may bring a brand new item to the team and ask them “can we refine this and include it in this Sprint?” While this should be uncommon, it should also be possible.

You may wish to read a recent  Scrum Alliance article on effective backlog refinement I wrote for more guidance.

4. Determine Sprint Capacity: How much work can the team do on average? Is there anything that will impact the team’s ability to work this Sprint? A great example is what to do when a major holiday falls in the Sprint. Instead of the team shortening the Sprint, they simply account for how this will impact them. If the entire office is shut down for a week, then the team’s capacity is 50% of what their velocity says they can do.

You can learn more about this in our  Agile Metrics and  Team Velocity articles.

5. Determine what work will be pulled into the Sprint Backlog: Once you have a capacity guide for the Sprint, the Sprint Backlog can be filled. There are many ways to do this. Just remember that the Developers pull work into the Sprint. They determine how much is pulled in.

6. The Developers plan how they will complete the items in the Sprint Backlog: This is the most frequently forgotten — and therefore problematic — part of Sprint Planning.

 Here’s how I explain this to  students:

 “When Sprint Planning starts, you are coding! Not all coding is hands-on keyboard typing. There is whiteboarding, design conversations, coordination and more.”

If the developers need to look at the code to determine how they are going to build something, then look at the code. Scrum Masters, this is one of the places you are needed. Ask questions, seek clarity. Does the team really understand what they are going to do or are they planning to “just figure it out as we go?” That’s not Agile, that’s lazy. 

Here are some things Developers can do in Sprint Planning:

• Task breakdown (UI, DB, code, code review, analysis of field mapping, etc.)
  • Why? So we don’t forget the plan!
• Whiteboarding conversations
• List of tests
• Sketch UI, review design
• Anything required to plan how to complete the work

7. Close: Closing can be an under-appreciated part of a good Sprint Planning. One of the key things to do here is to collect a confidence vote. Now that the Developers have planned out the work, how confident are they that they can complete it all in the Sprint?

A good way to check on confidence is to use the  Fist to Five consensus framework.

Want Quality? Plan Well!

The concept of “Starting off on the right foot” is not just a trite saying. If you want to improve the quality of your work, improve the quality of your Sprint Planning.

Recommended Reading

• Sprint Cadence: A Pragmatic Guide
• 5 Steps to Creating a Sprint Goal
• Agile Estimation Techniques
• How to Run an Effective Sprint Review
• Agile Retrospectives in 5 Steps
• Two Fast Retrospective Techniques