Is it really necessary to have a four hour meeting in Sprint planning?

Question

According to Wikipedia, it is recommended that there should be a four hour meeting in a two-week sprint planning (pro-rata for other sprint durations).

Is it necessary? Why?

Answer 1

I'm going to slightly disagree with Bogdan's answer.

The Scrum Guide does say that:

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

We normally think in weeks, so I translate "one-month Sprint" to "four-week Sprint". However, it goes on to say that if the Sprint is shorter than 4 weeks, "the event is usually shorter". The Scrum Guide does not give a suggestion on how to scale the timebox for an event for shorter Sprints, nor does it even say that the timebox needs to be scaled for shorter Sprints.

Common advice is to scale linearly. That is, if a Sprint with a timebox of 4 weeks has a timebox of 8 hours for Sprint Planning, a Sprint of 2 weeks would have a timebox of 4 hours for Sprint Planning. In my experiences, this works out well for scheduling purposes. It is important to keep in mind that a timebox is a constraint, not a mandatory duration - the event ends when its intention has been fulfilled and the maximum time should be the timebox.

I've found that if you spend sufficient time on Product Backlog refinement activities before Sprint Planning, then Sprint Planning will be much more efficient. The Scrum Guide recommends that approximately 10% of the Development Team's capacity be allocated to refinement, but note that this isn't a timebox - it may be more, it may be less, but it's a good guideline to keep in mind. If you go into Sprint Planning and the bulk of the work at the top of the Product Backlog is well refined and understood by the Development Team, identifying which Product Backlog Items can be done within the Sprint becomes much easier and the team can focus on developing a plan for getting that subset of items to Done.

Answer 2

The Scrum Guide mentions that:

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

If you keep the same train of thought, that translates to a maximum of four hours for a two week sprint.

Events are time boxed in Scrum so that people stay focused on the activity. Imagine if the Daily Standup wasn't time boxed, people will just talk and talk and talk. Same with the Sprint Planning, people need to stay focused to plan the Sprint. If you spend a lot of time planning and go beyond the four hours then that's a sign of possible issues (maybe someone hijacks the meeting, maybe stories aren't properly refined, maybe people are day dreaming, etc) so in normal conditions the Sprint Plannings will take less than four hours.

The four hour per two week Sprint is a maximum. It does not mandate that you spend exactly that much amount of time on the activity. If you plan properly and you finish your planning sooner, then that's no problem at all.

Answer 3

A four hour long meeting is harmful

Four hours is way too long for a productive meeting [1]. Here's an excerpt from an article by FastCompany:

What’s your record for longest meeting?

Can anyone beat my four-hour marathon? (I bet many of you can!)

When it comes to meeting pain points, length often tops the list. How is it that meetings tend to go on so long, sometimes (OK, many times) unnecessarily? Here’s an old project management adage that might explain it:

Work expands to the time you schedule for it.

For this reason, you may want to keep meetings to 15 minutes or shorter, whenever possible. Yahoo’s Marissa Mayer will schedule 10-minute meetings, out of necessity for her busy schedule. The team at Percolate sets 15 minutes as the default length for all meetings, adjusting up or down as needed. Percolate values the 15-minute default so highly, they framed it in their set of six meeting rules.

Why might it seem like 15 minutes is an ideal starting point for meeting length? For one, it’s easy to schedule in an Outlook calendar or Google calendar. Though the default in most calendar apps is 30 minutes, you can quite easily adjust down to 15-minute increments as that’s how most schedule grids are created.

For the science behind the 15-minute rule, you need look no further than a TED talk. Each TED talk is kept to 18 minutes or shorter, the same time as a coffee break and a helpful constraint for presenters to organize their thoughts. Scientifically, 18 minutes fits right in with the research on attention spans: 10 to 18 minutes is how long most people can pay attention before checking out.

The 18-minute max has physiological roots. Our bodies require a large amount of glucose, oxygen, and blood flow when the brain processes new information. Sooner or later, we feel physically fatigued.

It's true that some people (managers usually) like long meetings, but for many people long meetings 1) kill productivity by causing significant mental fatigue, 2) harm morale because they're seen as almost a form of torture, and 3) signal incompetence (I tend not to think my team knows where its going if they have to have 2+ hour meetings all the time to figure things out).

For the love of humanity please keep meetings short!

Seriously, unless you want your team to start hating you, keep meetings to a minimum and make them highly focused. It takes more work but it will 1) keep your team from getting as drained mentally; 2) keep your team happier; and 3) make your team think more highly of your organizational skills. I would seriously consider leaving any team that had regular mandatory four hour meetings, and I'm sure I'm not alone.

1. https://www.fastcompany.com/3033232/9-science-backed-methods-for-more-productive-meetings

Answer 4

In my opinion, no. I once took over leadership of a team that had 4-hour biweekly planning meetings, and it was miserable. No one is effective towards the end of a 4-hour meeting, and it led to plenty of bad decisions. I was eventually able to bring it down to an average of 90 minutes (in a 2-hour slot) and the resulting work was greatly improved. The key, of course, is preparation — and, if necessary, cutting off discussion within the meeting. The backlog should be in a good state before you come into planning. If a story isn't well-defined by backlog grooming the week before, then you aren't ready to take it on. If you know what you're doing but estimation becomes a discussion about how to do it, then you need to do a confidence check. Either you decide as a team that you're discussing details which can be figured out after planning without major impact on the timeline, or you decide that there's major uncertainty in the approach, and kick the story out in favor of a research spike which will let you do it with confidence. Either way, doing the research during the planning is the worst available option.

Answer 5

For a team that's done minimal pre-meeting preparation, is working on a new project, and/or who are new to working together, 4 hours for a 2-week sprint seems reasonable. It's better to waste a few minutes in a meeting than waste a few days of a developer's time during the sprint because a task wasn't clear enough or if technical blockers weren't discussed during sprint planning.

That said, it's definitely possible to reduce the time required for Sprint Planning meetings without adding risk. Here's a few basic techniques that we used to reduce our average Sprint Planning meeting to less than 30 minutes per 3-week sprint for a 15-person team:

• Ensure that the backlog, and the top tasks therein, were ready at least several days ahead of the Sprint Planning meeting. Then require that everyone read all tasks before showing up at Sprint Planning meetings.
• Have one senior developer "pre-review" proposed sprint tasks to find technical blockers, unclear requirements, and other problems. Instead of wasting everyone's time if blockers were found during the Sprint Planning meeting, this technique limited the "find and fix blockers" impact to one developer plus the task owner. This role (the team called it "crap-master") rotated between a different senior developer in each sprint. That way one person didn't always end up with extra work.
• We did task estimation before Sprint Planning, at a weekly "estimation meeting". These were generally less than an hour unless there were lots of intra-dev-team arguments. If a task didn't fit in the hour, its estimation would get delayed until the following week, which was OK because there were three of these meetings per sprint. Doing estimation ahead of time made estimates more accurate, and it also made Sprint Planning easier and faster because devs were already familiar with each task.
• About 2 weeks before each sprint started, the dev manager would calculate sprint capacity (in points), taking into account holidays, vacations, etc. This, combined with the advance estimation meetings above, meant that PMs could figure out ahead of time which tasks would fit into the sprint so we don't waste time at Sprint Planning on tasks that won't fit in a sprint.
• Product Managers would groom the backlog ahead of time. 3 days before Sprint Planning, they would send a "Draft Sprint Plan" email to the team which listed the (usually already estimated-- see above) tasks at the top of the backlog and briefly summarized (usually in one sentence) each sprint task including why (business purpose) of the task. This mail also was a good place to explain overall goals and risks for the sprint, e.g. "This is the last sprint before releasing our dark-mode feature" or "Scott will be on vacation next week, so ask any questions before he leaves".
• For tasks that were too large or unknown to estimate, instead of wasting everyone's time arguing about their scope, PMs would simply assign a specific number of points (aka "timebox") to that task. If the task couldn't fit into the timebox, devs would stop work and continue in a later sprint.
• Instead of spending everyone's time in Sprint Planning discussing code refactoring, upgrading build tools, and other "Technical Debt" tasks, the dev team had a fixed percentage of sprint capacity (e.g. 30%) that they could allocate to whatever technical-debt work they wanted. This let devs allocate these work without wasting the entire team's time in Sprint Planning.

Doing all the above wasn't easy. It required a lot of discipline from everyone on the team to each do their part. But all the prep work above made Sprint Planning meetings quick. PMs would go through the Sprint Draft email they sent several days earlier, devs would ask questions about specific tasks, and we'd wrap up. After a while of doing this, we could usually finish Sprint Planning in 20 minutes.

True, there was other planning work happening outside Sprint Planning. But crucially that other planning work didn't require big blocks of time from the entire cross-functional team. So the overall efficiency of the team was improved. More importantly (for both the business and for team morale), sprints became more predictable with fewer all-nighters, fewer missed deadlines, and fewer arguments.

Answer 6

I would say the length of a sprint planning session depends on a number of things:

1. Has the backlog been groomed/refined?
2. Do you have a Definition of Ready that stories/features must adhere to?
3. Are you sizing tickets using planning poker cards? Or just t-shirt sizes?
4. How long is the sprint?
5. What's your capacity? Is it based off your velocity?
6. How good is your product owner?
7. How testable are the stories?
8. Do you have a sprint goal?

1 - If the backlog is in a bad shape, planning will take longer as you'll need to tease out the detail.

2 - If you have strict conditions, there may be some tickets up for discussion with respect to their scope, conditions of acceptance etc...

3 - Planning poker can take longer, as there is more discussion when someone pulls a 5 vs a 20.

4 - Sprint planning is usually 2 hours per week of development, but varies depending on who you ask.

5 - Are you dev heavy? Test heavy?

6 - Are they good at writing stories and conditions of acceptance? Are they aware of stakeholder priorities?

7 - Stories which are hard to automate may require further discussion.

8 - Won't really affect the length of sprint planning, but thought I'd add it in anyway.