8 hour sprint planning?

If you've worked on a life-critical system you may, because the Definition of Done could be quite rigorous, although if a team finishes planning earlier they can leave earlier.

The quality of what they are planning should not be unpredictable. Scope might be, and a team should understand that the Sprint Backlog is a forecast of the work needed to meet their Sprint Goal.

Have I experienced it? No, not yet.



Could it be needed? Let's explore two scenarios...

Scenario 1:

Imagine that your stakeholders have just shared a once in a lifetime opportunity at Sprint Review. The opportunity is time sensitive, meaning if you are not first to market in the next few weeks, the opportunity may slip through your fingers. The opportunity aligns to your Product Vision and the Developers believe it is feasible, but... you don't have any Product Backlog items in the backlog for it and this is the first time it is being discussed.

The Product Owner and Scrum Team want to pursue this opportunity so Sprint Planning now includes creation and refinement of Product Backlog items in support of achieving their Sprint Goal (aligned to this opportunity). In this scenario, the Scrum Team may find themselves in need of most if not all of the 8 hour time box to discuss, create, refine and plan...just enough to get started. The rest they can discover once they learn empirically through the Sprint.

Scenario 2:

It is a Scrum Team's very first Sprint. Rather than falling into an anti-pattern of a "Sprint 0" or a lengthy pre-game initiation/planning period, they use the 8 hour time box to sort out their first Sprint so they can get started.

Thoughts?

I've never had a Sprint Planning last 8 hours, but let's work through this.

8 hours is the maximum timebox for the Sprint Planning event. Regardless of your Sprint length, it should not (or even cannot) exceed 8 hours. However, this timebox is based on planning a Sprint with a length of 1 month. Most teams that I've worked with settle on a 2-week Sprint, which is less than half the Sprint duration than the 8 hour maximum timebox is designed for. Since "the event is usually shorter" for shorter Sprint lengths and most teams (in the surveys that I've seen) are using shorter Sprint lengths, I'd expect most teams would be able to complete their Sprint Planning in less time than the maximum timebox.

Although not specified in Scrum, my heuristic is to proportionally scale the events. For a team that has a Sprint length of 2 weeks, I would start with setting aside 4 hours for Sprint Planning. Although 2 weeks is a little less than 1/2 a month, 4 hours is also half a work day in the US, where I and most of the teams I work with are based. Putting a 4 hour block on a calendar every 2 weeks reduces the burden of scheduling. But again, this is a maximum - we don't want to use all 4 hours just because we have 4 hours set aside.

Another factor in how well the team uses the time set aside for Sprint Planning is how prepared the team is to address the three topics. When the Product Owner can start the Sprint Planning with a clear vision for a Sprint Goal and that Sprint Goal is achievable within the Sprint timebox, that can reduce the time needed for the team to craft and align on a Sprint Goal. When the Product Owner has a well-ordered Product Backlog that supports the Product Goal and the intended Sprint Goal and the work at the top of that Product Backlog is well-refined so the team can quickly pull work that they can likely complete within the timebox and get them to satisfying the Sprint Goal, the team can quickly say what they can get to Done in the Sprint timebox. If the first two topics can be done quickly, the team can focus on planning how to get the work to support the Sprint Goal to Done, and this is also made easier by investing the right amount of time in refinement and developing a shared understanding. A good Product Owner and an investment in refinement throughout the previous Sprints can reduce the time spent in Sprint Planning significantly.

The amount of time spent in planning also depends on the organization's appetite for risk. An organization that needs more certainty or predictability will probably spend more time planning and thinking through risks, potential issues, and adverse outcomes and how to detect and mitigate them. This requires the team to spent more time determining how to get the selected work done. However, an organization that can handle uncertainty and unpredictability well may opt to spend less time in planning the work, perhaps only planning a day or two and using the Daily Scrums to continually refine the plan.

Is 8 hours a long time? Absolutely. Is it excessively long? It depends on your context. I would suspect that very few teams need 8 hours of planning. But there are cases where it could make sense, even if it is just the team setting aside a full day for planning activities. The team doesn't need to use the full timebox every Sprint.

I have experienced a couple of 8 hour Sprint Planning sessions.  And @Ryan's second scenario was the reason.  Organization moving to Scrum for the very first time from less than agile practices.  We took the opportunity to spend an entire business day putting together a Product Backlog, refining some items to the point that we thought they could be done in a single Sprint, putting together a Sprint Backlog and then forming a plan to get started.  Did this with a total of 5 teams over the period of a week.  They never took that long again and I have never experienced it anywhere else.  

Do I think I could experience it again?  In the world of software development I never know what to expect.  And in the world of complex problem solving, again there is no way of knowing. 

In addition to everyone's excellent points, I could see the Scrum Team also needing to create a Definition of Done if it's their first Sprint Planning session (rather than do this in the infamous Sprint 0).

Ok, thanks for all your detailed answers. That helps!

As people mentioned before it is the Maximum of 8 hours for a four week sprint. 



I think a full day of planning is actually something scrum teams could experience and benefit from. The planning day could be used to refine tickets, take the appropriate time to formulate a sprint goal, and fully focus together on the product vision and what the this sprint will mean for it. 



I think it all boils down to how well as a Scrum Master you can facilitate this day. Yes it may seem daunting when thinking about a day of planning, but it can be a great experience. 

You don't have to stretch the timeboxed events to the maximum.

8 hours is Maximum time duration for a month-long Sprint, just like 4 hours for a review, 15 min. for daily Scrum and 3 hours for retrospective.

It is perfectly fine for a Scrum team to complete the meetings in less time, eventually increasing actual cycle time for work.