The Scrum Guide says:
Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.
A lot of teams I know of are on two-week sprints, and give themselves a time box of two hours for Sprint Planning.
What if I told you that you could knock out Sprint Planning in 15 minutes, or 20 max? Would you mind having that 90 to 105 minutes of your life back?
First you have to understand the purpose of the Sprint Planning meeting. It’s a MUCH simpler meeting than how I see a lot of people doing it.
The purpose of Sprint Planning is to generate a shared agreement on the goal and the forecasted work for the sprint, and an initial plan for how to tackle it. That’s it. It’s that simple.
Long, drawn-out, marathon Sprint Planning meetings, with a lot of administrative prep work that has to get done, is a drag for everyone involved. When the Sprint Planning Meeting is tight and efficient, it launches the Development Team into their first day of the Sprint with high energy and enthusiasm.
Setting a goal of a super-short Planning Meeting does come with some significant risk, especially on teams that aren’t very mature. If shortness becomes more important than getting the value of the meeting achieved, that would be a big mistake. My point isn’t to do it as quickly as possible, but rather that good preparation can make it an engaging, inspiring, short Scrum Event.
In order to do that, two things need to be in place. You need to come into Sprint Planning with your backlog refined and prioritized.
The Guide doesn’t guide us much on Refinement. It says:
Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done.
Doing refinement inside Sprint Planning is an option, but it’s a recipe for drawn-out Planning meetings.
The first critical thing that needs to happen in order to tighten up your Sprint Planning Meeting is to walk in refined. I see many teams adding regular occasions to do Backlog Refinement to their cadence. Either representatives of Product, Development, and Testing put their heads together (a practice known as “Three Amigos”), or a full-team meeting is held for refinement.
This separate Refinement Meeting is where approaches and solutions are discussed. A Backlog Item should come into Refinement with a well-explained “what” of the work, often in the form of Acceptance Criteria. The Team should spend this meeting filling in the “how” and the “how hard”, often in the form of description narrative or technical notes, and an Estimate.
So to come clean, much of the spare 90 to 105 minutes I promised you earlier will get spend here. But moving that work to a meeting that’s deliberately about Refinement makes a huge difference. And coming into Sprint Planning with your refinement and estimation done is a crucial step in having Planning go smoothly and quickly.
A Product Owner should spend a fair amount of their time considering and reconsidering the prioritization of the work they want done on the product. Priority is expressed in the ordering of the Product Backlog. It’s a living, dynamic thing, subject to constant change based on input from Stakeholders and the market, changes in developer availability, etc.
One critical thing that’s overlooked, though, is that Sprint Review Meeting is a key occasion to prioritize. One of the elements that the Scrum Guide says is part of Review is:
The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning
A Product Owner should walk into Review with a clear sense of their next priorities, but should also be open to collaboration with the other people in the Sprint Review. A transparent conversation among the team members and Stakeholders can result in a complete prioritization of the next few Sprint’s worth of work, to the extent such a thing can be forecast at the time of that meeting.
The team all agreeing that the Product Backlog’s ordering looks good is a fantastic note to end a Sprint Review on.
What a 15–minute Sprint Planning Meeting looks like
The team comes together on time, and spends a minute or two on greetings and how-was-your-weekend chit chat. (Don’t skip or rush that, that’s part of it, and it’s important.)
The Product Owner brings up the Product Backlog. It should look familiar to the Team because they all agreed on its prioritization in the just-completed Sprint Review.
The Scrum Master or Product Owner shows the team their completed point score from the latest few Sprints, or however the team figures its velocity. The team uses that to eyeball an amount of work to pull into the Sprint Backlog. They consider anything that might cause a velocity variance — things like holidays and team member vacation days, or any upcoming production matters they’ll need to support.
When they have a Sprint Backlog assembled, they sit back and look at it, and ask themselves what specific value they’re delivering with work they’ve just pulled in. They write a Sprint Goal that summarizes that value, something they can all get behind and push for.
Then the team goes through the selected work, discusses optimal work order, and team members claim their initial tasks.
When this is complete, the Scrum Master says, “Okay. Anything else for anyone?”. The team looks around and shrugs, somebody (invariably) says, “Let’s get to work!” and the meeting breaks up.
This is quite possible to get done in fifteen minutes, and easily done in twenty.
It’s all about preparation
As a Product Owner, I’m always thinking out ahead of my team. Some people use the analogy of a Product Owner as the architect of a building, designing and detailing what is to be built. I like that analogy, but I also see my work on the Product Backlog as being like a surveyor, with my boots on the ground, mapping out and understanding the terrain that my development team is going to be building on.
You wouldn’t want the construction crew for a new building to be the first ones to set foot on the lot, right? Even beyond a well-drawn blueprint, it takes a lot of understanding of the “lay of the land” before the first foundation footings can be dug and poured.
If you can come into the meetings where the Development Team encounters the Product Backlog with as much preparation and care as possible, their engagement with the Backlog during Sprint Planning becomes extremely efficient, and a joy for them to participate in — a launchpad for a fun, successful, and productive Sprint!
Counterpoint, or is it?
About a year ago, my fellow Serious Scrum blogger Willem-Jan Ageling wrote, in the “Are you serious?”series, “We do Scrum, but… 15 minutes will do to finish the Sprint Planning”, which offers a great perspective on the anti-patterns that can arise around a concern for tight and focused Sprint Planning meetings.
I leave as an exercise to the reader to determine exactly how and why Willem-Jan and I are saying exactly the same thing while appearing to say opposite things!