How to deal with sprint planning running far too long?

Question

I took over 5 hours in sprint planning for a week long sprint. That seems like too much.

We discuss things in detail in sprint planning, as most of team members are not senior. If we don't it will lead to mistakes during implementation and redesign during sprint.

How do we deal with this?

How much detail should I discuss during planning to fit it to just 2 hours long per a week sprint?

Answer 1

You're right - 5 hours in Sprint Planning for a 1 week Sprint does seem like a long time. The Scrum Guide time-boxes Sprint Planning to 8 hours for 1 month Sprints and says that "for shorter Sprints, the event is usually shorter". If you consider the ratio, a good target may be 2 hours of Sprint Planning for a 1 week Sprint, but there's no fixed timebox.

So, how can you address a long Sprint Planning?

As a Scrum Master, I would take these following steps:

First, I'd work with the Product Owner to make sure that the Product Backlog is properly ordered. It is essential to effective Backlog Refinement and Sprint Planning to make sure that the most important work and their dependencies are at the top of the Product Backlog so that way the Scrum Team can focus their energies on defining, refining, and preparing the right work.

Second, I'd make sure that the team is spending sufficient time on Backlog Refinement. The Scrum Guide indicates that refinement activities generally take no more than 10% of a Development Team's capacity. As an example, a Development Team of 4 working a standard 40 hour week should plan on about 16 hours of Backlog Refinement. This may be done individually, in small groups, or as a team. I've found that having a planned Backlog Refinement session for the team and then breaking out to do any research or investigation or planning tends to work the best.

Third, make sure that the team realizes that they don't need to get every detail right in Sprint Planning. The goal of Sprint Planning is to produce a plan to completing the Sprint Goals. Don't try to do big design up front at a Sprint Planning session. Understand how different work fits in, dependencies, and objectives and use time outside of the Sprint Planning sessions with the right people to do the design, implementation, and testing required to deliver the work.

More steps may fall out of these, but this would be a good starting point.

Answer 2

I hear you. That's too long to spend! Hopefully, your team is discussing this in your retrospectives. We tried several experiments with mixed results:

1. Everyone does a high-level design on a single ticket and passes it left or right around the table for revision followed by a group review of the plan for each ticket. Not everyone liked this, but it did force our juniors to give it a try. Some individuals on teams are quite happy just letting others do the thinking and they just follow the instructions. So, on the plus side, our experiment forced everyone to confront their knowledge gaps, it provided a growth-challenge for juniors. On the negative side, not everyone likes being put on the spot and it doesn't necessarily reduce the time in the meeting. Next!

2. Paired designs were attempted. Groups of two or three would break down a ticket into tasks. The entire team would review the resulting plans. It went a lot faster, but some mini-pods had the same issue of one person riding along while the other did the work on the design.

3. Skip the task breakdown. We decided that our story points averaged out, so we were just wasting time trying to involve the whole team in everything. We had much shorter planning meetings as a result, but the design work was something our pairs had to do for themselves when they started a ticket. If juniors are working a ticket, expect that they'll need help to get past this step. If you try this, accepted fewer stories in the sprint until you get comfortable with it. Also, make sure it is "safe" for your team mates to ask for help when they don't know something.

In the end, it comes down to team maturity. People need to understand each other's abilities and preferences and have confidence that teammates will ask for input when they need it. Fix those first, if you don't have them. Then solving the problem of inefficient meetings gets easier.

Answer 3

I like the answer you received from @Thomas-Owens but I will also add one more item. Have you considered doing pair programming as part of your Agile implementation?

Pair programming would help with (1) teaching some of your junior programmers how to write better code and (2) in pair programming, you don't always have to have every single design feature laid out for you in sprint planning. With the pair working together, some of those design decisions can be made "spontaneously" with the added pair programming benefits.

If you can help your junior programmers learn faster and you know that design items that you didn't address in Sprint Planning will be decided by two people, there is no reason why you wouldn't be able to cut down the time you spend in future Sprint Planning

Answer 4

I am no scrum aficionado and only have roughly a year of practical experience. So the following is to be read with a grain of salt.

I see several red flags in what you write:

5 hours sprint planning

This is way too long for a one week sprint.

The goal of the sprint planning is AFAIR to

• enable the team knowing what the current priorities are and
• to develop a battle plan for the upcoming sprint.

In order to do do this effectively, each side has to understand the Product Backlog items.

In order to understand the Product Backlog items the backlog has to be in good shape.

In the concrete planning phase, the Product Backlog items are transformed into Sprint Backlog items.

One possible cause is, that these items are not clarified / refined enough.

Another possible cause is, that the items are way too complex and leave room for too much interpretation.

Discuss very detailed in sprint planning

As said above, the discussion phase will be shorter, when the items are more concrete.

On the other hand: Sprint planning expects professional behaviour from every participant. This includes avoiding bikeshedding discussions.

Perhaps things are clear, but somebody starts a bikeshedding discussion.

More: Avoid discussions about implementation details. Although every idea ends up in code at some point in time, it is not the point of the sprint planning discussing, whether a simple array will do the trick, or it will be better using a linked list.

As most of team members are not senior

In scrum there is no distinction between senior and junior. Both are just developers. And this is a good starting point, which helps you keeping your discussion focussed on a viable solution backed by the better arguments and not the paycheck.

Mistakes of implementation and redesign during sprint

There seems to be a fundamental problem in requirements gathering, followed by a very vague product backlog.

As I said above: As long as the Product Backlog is in a good shape, it should be hard to miss the point.

I can not imagine a situation like:

»As a user I want to see a handful of customers!«

»Oh, you didn't mean every of our 2 million customers?«

OTOH: What does in this context redesign mean? If a developer chose a slow performing algorithm, then there is the next goal clear: choose a better performing one. But that is no "redesign", this is an optimization.

---

To your main questions:

How to deal with this?

It is trivial to mention, but I do it anyways: Do not forget, that you are dealing with humans.

It is very hard to have a group of different minds, which are able to share common concepts (like in Rashomon). In order to deal effectively with this, use as much redundancy in your communication as possible: e.g. explain the context of the item extensive, even if everybody "should know" what to do. Ask questions, whether everybody gets what the topic of a given item is.

If you are playing planning poker a good indicator, whether the understanding is good enough, is, that tasks are rated low. Low means low complexity means easy to understand and hard to miss.

One side-effect of iterating is, that the numbers for certain tasks will go up (because the team has an understanding of its capabilities and the hidden complexities). Then there is chance to break down the item into several less complex items with lower complexity.

How much detail should I discuss during planning to fit 2 hours long per a week sprint?

Salomonic answer: As less as possible and as much as necessary, but not more.

tl;dr

• Choose an easy language (if it helps, use simple english or ELI5) to avoid misunderstandings

• Improve requirements gathering

• Improve Backlog

• Increase confidence of team members in their individual capabilities as well as their capabilities as a team

• Avoid bikeshedding

• Improve personal discipline

• Perhaps use fixed timeboxes for every item to discuss

• Strengthen the position of the scrum master to moderate effectively.

Answer 5

We have succeeded in reducing planning meeting time much by doing grooming of total three hours in 2 weeks sprints. We divide the grooming in to four sessions. we do 30 min grooming in Monday and 1 hour grooming in Wednesday every week. Our sprints starts on Monday and ends on Friday. As a result we have good information from grooming meetings that contributes as input to the planning which makes it shorter. Our best record was a planning meeting of length 30 min in one of our sprints. Most of the time it does not take more than one hour to one hour and 30 minuts. It is still time boxed anyways, but the planning was done very early.