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?

  • 2
    What exactly are you doing in Sprint Planning? Are you breaking down stories, refining requirements, doing design, estimating? – Liath Aug 10 at 16:22
  • 1
    Thanks I forgot to tell. We spend most of time doing design. – b.ben Aug 10 at 18:24
  • 1
    Are you doing backlog grooming in a separate meeting? We typically timebox backlog grooming to 1 hour per sprint and sprint planning to 1 hour per sprint. That's been working well for our 2 week sprints. – Berin Loritsch Aug 10 at 20:03
  • 4
    @b.ben but "design" is not part of the sprint planning. – Thomas Junk Aug 10 at 20:11
  • 2
    er wait, why are you talking about implementation during sprint planning? Sprint planning is about what not how. – candied_orange Aug 11 at 1:32

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.

  • 2
    Basically the team will still spend the same number of hours in meetings. We just call them different meetings. :) It takes what it takes to break things down enough for the team to feel comfortable estimating the work, and to be independent when it comes time to do the work. – Greg Burghardt Aug 10 at 19:54
  • 4
    @GregBurghardt: OP writes that they spend most of the time doing design. So the entire team works on the design of every single story. If you break that up so that only part of the team works on each respective story, you reduce the overall time spent in meetings. – Michael Borgwardt Aug 10 at 20:38
  • Re: "make sure that the team realizes that they don't need to get every detail right in Sprint Planning": And, more importantly, make sure that it's actually true that they don't need to get every detail right in sprint panning. – ruakh Aug 10 at 21:00
  • @GregBurghardt Perhaps. But there's a difference between the entire team being in a room for 5 hours and different combinations of people being off doing design work for 3 hours after a 2 hour planning session. – Thomas Owens Aug 10 at 22:26

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.

  • 4
    Option #3 breeds teams that rely on a single person, or small group of people. If that person or people are not around, team velocity goes right down the toilet. I used to do that with our team, and any time that person went on vacation chaos ensued. Nothing got done. Then the team lead spent 3 weeks trying to calm project management down. If you are working on a team with juniors or non experts, I definitely would not recommend #3. If you've got all experts (and they are actually experts) #3 can be a time saver. – Greg Burghardt Aug 10 at 19:52
  • If that person is just doing the task of design for everyone, sure, I agree. But what if that person were helping people at getting better at doing it themselves? – Jason Zinschlag Aug 10 at 19:58
  • 2
    It's been my experience that they don't get better with someone guiding them through things. It turns into the experienced people doing it for the less experienced, because the less experienced took orders of magnitude longer. We had better luck with sitting everyone in the room and doing dev tasks. Even going through code - but not during sprint planning. We call it "writing dev tasks" because that's what our team needed. Then they started becoming independent, and they started becoming better and faster at writing dev tasks. – Greg Burghardt Aug 10 at 20:01
  • Glad your team found a way. Do you think your experienced teammates were taking the easy way out? Teaching people is a headache, I know. But it pays big dividends. Most people do not have the patience for it, and I see exactly what you are describing --experienced people can easily lose patience with the process and "do it themselves". Plus the juniors need to be good learners. – Jason Zinschlag Aug 10 at 20:07
  • @GregBurghardt I tough we've done something like "writing dev tasks" during sprint planning. And I'm not sure if it's ok? – b.ben Aug 10 at 20:27

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

  • Yes, That's what I wanted to. But our team don't have enough senior to do that. I come up with an idea that will let all teams member write the abstractions and interfaces their own, before start implement let make a meeting to agree between all developers. What do you think? – b.ben Aug 11 at 3:54
  • 1
    @b.ben But your team will never have enough seniors until you do this. That's part of the power of pair programming. You must commit to this. – Unknown Coder Aug 13 at 15:43

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.

Your Answer

 
discard

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.