Sprint planning is often the longest meetings scrum teams have each sprint, so it's important to do it well.
But many teams struggle with sprint planning.
In this video, I want to share the top three signs that your team is struggling with sprint planing.
Number one, the meetings are long and painful.
I hear you.
Some of you are telling me that all meetings Perhaps, but while you may not enjoy being in a meeting, team members should at least find sprint planning
meetings valuable.
I don't enjoy going to the dentist twice a year to have her scrape the barnacles off my teeth, But I do acknowledge it's valuable Number two,
the team fails to finish most of the work and achieve the sprint goal in most sprints.
Teams don't need to achieve the sprint goal and finish everything every sprint, but they should finish every thing most of the time.
And too many teams miss every Sprint.
If people think of planning meetings as long and painful, those feelings are going to be compounded when the meetings don' t lead to successfully completing sprints.
And a third sign your team is struggling with sprint planning is that team members fail to leave the meeting enthused and energized about the work of the
coming sprint.
When sprint planting is done well, team member should be fired up, excited about doing the works they just spent time talking about.
If you and your teammates finish a planning meeting and aren't excited to do that work, it's a sign that sprint planning could be better.
Let's talk about how to stop struggling with sprint planting and do it better, by the way, I'm Mike Cohn, a co-founder of both the Scrum Alliance and the
Agile Alliance.
I help teams succeed with Agil and I want to help you too, especially with Sprint Planning.
To do, that I am going to share three tips.
First, keep your sprint planning meetings fairly short.
You don't want to rush through a planning meeting.
If you do that, you're almost guaranteed to overlook too much work and then not finish all the backlog items needed to achieve the sprint goal.
The advice be quick but don' hurry applies here.
the meeting should be fast paced but with no feeling that discussions are being rushed or cut off.
I like to target about 90 minutes to plan a two-week sprint.
If you're planning a 2-Week Sprint in 30 minutes, you are almost certainly not thinking through the work in sufficient detail.
On the other hand, when a Two-Wheek sprint requires a three-hour planning meeting, that's when people complain that the meetings are long and painful,
which was danger sign number one.
A second tip if you're struggling with sprint planning is to create a sprint backlog that includes a list of tasks and a rough estimate for each task.
A software team working on a relatively simple feature may, for example, have one or two coding tasks, a testing task, design task and maybe run a short
meeting to get the user's opinions on the design.
The estimates can be rough, little more than quick guesses.
The team should use them solely to gauge if they're bringing the right amount of work into the sprint.
Not too much and not too little.
Keep the estimates under a day of effort.
If something will take longer than a days, encourage team members to turn that into more than one task instead, each with its own estimate under day.
And the estimate should include time for everyone involved in the task.
The design review here has a three hour estimate, not because it's going to be a 3 hour meeting.
No, it is probably going be 1 hour and 3 team members will participate.
Coming up with these estimates shouldn't take much time.
Certainly not so much that your sprint planning meeting crosses over into that long and painful category.
Remember, they're really just quick guesses.
Plus, you won't need to do this forever.
Once your team has gotten good at planning sprints, try skipping the estimates.
Just create a list of tasks and see if team members can decide if a sprint seems appropriately full using just the list.
Here's a third and final tip, and this one will really save you time in planning meetings.
Don't try to think of everything.
I know, I just told you to make a list of tasks.
For each product backlog item, have team members yell out what needs to be done.
Code this, test that, decide how we'll handle such and such.
And very quickly, people will run out of ideas.
When that happens, give this silence perhaps five or 10 seconds to see if anyone thinks of any additional tasks, But after that,
move on and start talking about the next product backlog item and then creating its list of tasks and estimates.
When you do this, I can guarantee that some tasks will be overlooked.
If you'd given the team five more minutes to think about each product back log item, maybe played some Mozart music to help their brains think,
they would have come up with a few more items.
But it's not worth it.
Quickly identify the tasks the team can immediately name and then move on.
For this to be successful, make sure you don't fill the sprint too full.
The team will identify new tasks during the Sprint, so make you've left time for that.
For example, suppose you have a six-person team doing a two-week or 10-day sprint and you think team members can productively work for five or six hours
per day.
The rest of their time goes to meetings, discussions, corporate overhead, and so on.
A six-person team with a 10-day sprint and five to six hours per day will complete 300 to 360 hours in a sprint.
So perhaps this team should target identifying 250 hours of work during the planning meeting.
Team members will work the full 300-360 hours productive time during two weeks.
The 250 is just the amount that can be identified upfront at the start of the sprint, and the rest will be discovered as the team gets into the work.
Sprint planning is challenging, but it is vital for teams to get it right.
How is your team doing at sprint planning?
Let me know.
Are your meetings long and painful?
Do team members leave planning energized and excited about the works they're about to do?
And if your time is doing well at spring planning and achieving their sprint goals most of the time, please share your secrets in the comment section.
I read and appreciate every comment.
If this video has been useful, click the Like button.
And if you're new to this channel, Click Subscribe so you don't miss out on future tips to help you succeed with Agile.
Thank you for watching, and I'll see you next time.