When Team Feels Sprint Planning Is Too Long

Last post 02:46 pm December 30, 2016
by Markus Pfundstein
11 replies
Author
Messages
08:21 pm December 8, 2016

I'm a Scrum Master on a Team that's maturing. We've come a long way in our Scrum practice.

I feel the Team is ready for a solid 4 - 6 hr Sprint Planning session (covering 3 wk sprint). When I mentioned it, the immediate response was opposition. They are wondering why the Planning is so long, and why all the Developers need to be present.

As Scrum Master, I've trying to sell them on the benefits of having a thorough meeting, with all the Developers.

Any tips?

10:02 pm December 8, 2016

Which do you think is *more* important to focus on at this stage: that Sprint Planning should take 4-6 hours, or that each member of the team should be there?

10:05 pm December 8, 2016

We have a large team, nearly 15 between dev, bus. analysts, and testers. Four hours sounds right.

11:12 pm December 8, 2016

> We have a large team, nearly 15 between dev, bus. analysts, and testers

That doesn't sound like a Scrum Development Team. It sounds more like a big group with lots of specialists.

Is a grouping like this really suited to hold Scrum events in the first place? Could it be better organized, perhaps along the lines of teams in the Scrum and Nexus Guides?

01:42 am December 9, 2016

I've thought about breaking the group apart, but not confident I've thought about all the angles. Would Scrum suggest that every group has their own separate Scrum ceremonies?

03:28 am December 9, 2016

They can keep the first part of Sprint Planning and can do a common Sprint Review. However I would recommend doing separate (per team) the Daily Scrum, Sprint Retrospective and the 2nd part of Sprint Planning meeting.

03:31 pm December 9, 2016

I'm a Scrum Master on a Team that's maturing. We've come a long way in our Scrum practice.

I feel the Team is ready for a solid 4 - 6 hr Sprint Planning session (covering 3 wk sprint).

What is your current Sprint Planning length?

What leads you to feel that your current Sprint Planning process is an issue?

What feedback have you received from your team regarding their current pain points?

03:37 pm December 12, 2016

15 members is very large for a SCRUM team - five or six is ideal. I've never understood the why's of it, but from bitter experience can tell you it's true!

Have you discussed why the team thinks the meetings are too long? If not, you might get some very valuable feedback.

05:31 am December 15, 2016

So we have not had the 4 hour Sprint Planning yet. Currently we conduct 3 or 4 in 30 min increments in sub-teams (dev, testers, business analysts)

The push back is the concern that why have Team member suffer a long meeting if they only come out with one or two User Stories to tackle?

To counter that, one of my selling points was the value of having all the Team present so everyone understands the bigger picture of the product we're building.

01:48 pm December 15, 2016

Hi Sanjar,

"we conduct 3 or 4 in 30 min increments in sub-teams (dev, testers, business analysts)" <-- Scrum recognizes no sub-teams in the Development Team, regardless of particular domains that need to be addressed like testing or business analysis; there are no exceptions to this rule;

"if they only come out with one or two User Stories to tackle" <-- in SCRUM the team members won't take over the ownership over an user story

If I read this two poins, then I guess the problem is much bigger than just "When Team Feels Sprint Planning Is Too Long", I can't see the understanding of SCRUM and self-organizing.

02:18 pm December 15, 2016

Sanjar,

To Peter's point, why do your team members continue to embrace their own silo-ed specialization, and not the idea that any story accepted by the team may be worked on by any team member? The focus needs to be on team member capacity and availability, and not allocating forecasted work based on what is in each team member's wheelhouse.

With this dynamic in place, it is perfectly understandable why there is little interest on the team's part to participate in an extended Sprint Planning session where stories may be discussed that they feel they will not work on. Until there is progress made around team ownership of sprint stories, this impediment will remain.

02:46 pm December 30, 2016

Sanjar,
no offense, but I think you might really profit from studying the Scrum Guide into detail. As others pointed out there are obvious errors in your application of Scrum.
I wouldn't stress this so harshly if I wouldn't have had to suffer through bad implementations myself as a developers. A lot of developers are cynical about Scrum because they didn't get the real thing. Scrum only works if its implemented 100%. 200% on new teams with no agile experience.

There are a couple of steps you should take. My advice would be:
- learn the scrum guide by heart.
- remove all titles. Everyone from now on is a developer. There are no testers, B.A.s etc anymore
- let the 15 developers split into 2 scrum teams. don't decide for them. tell them to form cross-functional teams, who can - without any (!) help - deliver an increment every 1-4 weeks.
- start doing all(!) Scrum events with no exceptions.
- don't evaluate too quickly, let the team time to grow. Until a team is in performing mode it takes a while (read Tuckman).
- produce a valuable increment every sprint. no exceptions.