Sprint Planning is where we tie the knot. It’s where the delivery team commits to the Product Owner, “Come back at the end of the sprint and here’s what we’ll have ready for you.”
Sprint Planning is a scrum practice where the team gets together and decides what requirements/user stories they will complete in the next sprint (typically 2 weeks). The team does this by starting with the highest priority as determined by the Product Owner / Customer, discussing the User Story and giving it an estimate in Story Points. The team limits the total number of points they will take on based on how many Story Points they completed in prior sprints. They keep adding User Stories until they’ve filled their capacity.
This sounds great! What can go wrong at Sprint Planning?
Here are some Sprint Planning Pitfalls and strategies to overcome them:
Pitfall #1. The manager or Product Owner dictates what stories are in.
Team engagement is predicated on the team having control over their destiny. If someone else dictates what they must do, the team is not bought in loses ownership of the work. I hear from managers that they feel their people will under commit and not work as hard as they can. If you are a manager and your team does the minimum to get by, you have a problem with your team that can’t be solved by giving orders. If you believe that it’s human nature to do the minimum, and people won’t work unless pushed, then I suggest you turn in your manager title and find other work.
What do you do if your manager or Product Owner is dictating the stories? Power in numbers. The team has got to band together and take a stand. Practice self-organizing, organize yourselves to stand up for what’s right.
Pitfall #2. The team chronically overcommits.
The team is so ambitious that they commit to twice as many Story Points than they have ever delivered. And when they only finish half, and no one dies, they just keep doing it. These aren’t rollover minutes! Your productivity improves when you only work on what you are going to finish. Half done work is waste.
What do you do? This is a great topic for your Retrospective. You need to get to the root cause of why the team is overcommitting. Do they feel pressure from somewhere? Perhaps agree to an experiment where the team agrees to 10% more Story Points than completed last sprint. Track the actual velocity and see if it improves.
Pitfall #3. Estimates are given by each person and summed up.
I see teams do this “bottom-up estimation” and it takes them backward. Putting more work into an estimate doesn’t give it more accuracy. It makes sense to spend as little time as possible on estimates. The value of estimation is in the discussions you have that clarify the team’s thinking. If you estimate individually and then add them up, you lose the ability to have rich conversations. You want to hear things like “Whoa you think it’s a 34? I thought it was a 3! We might have a different idea of what we are building.” This shows that the team is clearing up differences.
Pitfall #4. The User Stories aren’t ready.
By “aren’t ready”, I mean they are too big, they have open questions or anything else that causes the delivery team to say “nope we can’t commit to that.”
The simple solution for this is to hold a “backlog review” meeting during the prior sprint. The backlog review is a quick meeting where the Product Owner says “hey, these are the stories I’m thinking of for next sprint. Can you work from this?” The delivery team gives them feedback such as “no I need more detail here” or “this is too big”. The Product Owner says “thank you very much. I’ll have them ready for Sprint Planning.” The Delivery team does not take an action item from this meeting! This is not a request to go research technical options and feasibility. However, the feedback might be “if you do it this way, I’ll need to research technical options and feasibility before we can build. If you do it this other way, we can start building.”
Pitfall #5. The Sprint Planning Meeting is boring.
The question is “why is it boring?” Is it because the team is working as separate individuals and much of the discussion doesn’t involve them? Is it because the team goes down rabbit holes? If everyone has a say in every story, there’s no reason for sprint planning to be boring. I see teams try to solve this problem with food, but sometimes there are problems that food alone cannot solve.
How do you make it less boring? Make sure to open the lines of communication so that everyone can participate. And by everyone, I mean even the people who are not experts in that area. The best ideas can come from the people who have the least knowledge. Thorny problems can combat boredom. Is there a thorny problem on the table? Let’s define the thorny points, without solving it now, but get everyone mulling over the challenge.
What pitfalls have you encountered during Sprint Planning? How did you overcome them? Post your tips in the comments!
