When Team Feels Sprint Planning Is Too Long

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?

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

> 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?

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?

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.

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?

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.

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.

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.

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.

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.