The goal of sprint planning is to understand what you’re building, why you’re building it, and how you’ll build it.

Learn how to:

• Build the right thing the first time with a solid plan.
• Deeply understand the work and evaluate potential implementations.
• Get the team and stakeholders aligned on what success looks like.
• Build trust outside within the team and outside the team in the rest of the organization.
• Prepare for sprint planning, so you’re not scrambling at the last minute.
• Develop a shared understanding of why the work in the sprint delivers value.
• Simple ways to ensure everyone understands what it means for the work to be “done done.”
• Get your team focused on delivering customer value instead of just building software.
• Think holistically about the system, why it’s changing, and the best way to improve it.
• Patterns, techniques, and tactics you can implement tomorrow and without specialized tools.

Read a sample chapter

Most sprint planning meetings are a waste of time

In an ideal world, sprint planning would be an exciting part of the iteration. The team would happily get together, instantly understand the well-written user stories, quickly decide on an implementation, and be able to tell stakeholders exactly when the work will be done.

But for most teams, sprint planning is the thing they hate the most. Not only is it YASM (yet another stupid meeting,) it’s frustrating, confusing, discouraging, and too long for what we get out of it. Of course teams dread sprint planning!

Scrum Masters looking to improve their planning meetings rely on reading theoretical literature on the topic, scouring user groups and forums for bits of advice, and reading out-of-date blog posts. If you’re lucky, you might find relevant suggestions. But good luck understanding how to effectively implement them.

Sprint planning is the hardest ceremony for Scrum Masters to facilitate. But it doesn’t have to be this way.

By understanding the reasons why we plan the work, defining the principles of effective planning, and adopting some battle-tested techniques, you can start facilitating effective planning meetings, delivering more value each sprint, and building that high-performing team you’ve read about.

What this book is not:

This isn’t theoretical advice based on an ideal organization, the full adoption of Scrum, 10x team members, and perfect user stories. It’s from the real-world and for people living in the real-world.

This isn’t an introduction to Scrum, and it doesn’t adhere to the dogma you’ve read elsewhere. But if you’ve got some experience with agile software development, you’ll find this to be a pragmatic guide.

This isn’t a list of things that might work for your team. This is a list of things that I know work because I’ve used them hundreds of times across dozens of teams. And I’m still using them after a decade of experimentation! 

About the author

Clayton Lengel-Zigich has spent the last 20 years solving problems with software. As a developer, coach, and product manager he has seen it from all sides. He is seeking continuous improvement and always looking for opportunities to inspect and adapt.