6 common mistakes when doing Sprint Planning
How to do effective Sprint Planning as a Product Owner?
Sprint Planning feels like being held hostage. Nobody leaves the room until everything is figured out. The Scrum Team discusses the nitty-gritty of the upcoming Sprint, until all uncertainty and risk has been abolished.
Yawn. Can’t we just get started coding already?
As a Product Owner, I work hard to keep Sprint Planning short and effective.
My Sprint Planning takes around half an hour to an hour for a Sprint of two weeks. I see other teams in Sprint Planning for many more hours. I believe the resulting plans are only marginally better. If they even are better.
What are the 6 most common mistakes involving Sprint Planning and how do you resolve them as Product Owner?
I also included a list of valuable articles at the end, in case you are interested in learning more and digging deeper.
1. Sprint Goal as an afterthought or no Sprint Goal at all
A missing Sprint Goal or a catch-all Sprint Goal weakens the ability of your team to deliver. Without a clear goal your team will be lost when the Sprint Plan fails. It’s not a question if your plan will fail, but when.
As Product Owners we should start with the Sprint Goal to set the Sprint up for success.
The Sprint Goal is a north star empowering the team to make the right decisions. The Sprint Goal prevents following the plan to become more important than meeting the objective of the plan.
By understanding the goal of the Sprint, the Development Team enjoys the freedom to make the right decisions as more is learned. The Sprint Goal promotes teamwork, focus and flexibility.
Product Owners should kick-off Sprint Planning with the Sprint Goal and then work together with the Scrum Team to finalize it.
2. Not allowing changes during the Sprint
You may think not allowing changes during the Sprint has nothing to do with Sprint Planning, but you would be mistaken.
Imagine your team believes everything added to the Sprint is fixed and must be completed. Changes during the Sprint are discouraged and the Sprint is only a success if all Sprint Backlog items are finished. As a consequence, the team will waste more time in Sprint Planning to try and come up with an impeccable Sprint Plan.
A perfect Sprint Plan is impossible to achieve, as you lack the information to do so in an complex environment.
The Sprint Backlog is flexible, as long as you don’t endanger the Sprint Goal. I encourage my teams to be flexible and allow changes, regardless of where they are coming from. I also give my team the freedom to add things to the Sprint, if it is necessary to meet Sprint Goal. If it is necessary to remove work to meet the Sprint Goal, then I encourage this as well.
Flexibility during the Sprint allows your team to make changes as more is learned.
3. Ironing out all details of the Sprint Plan
When you start your Sprint, you lack information to make the best plan possible. So why try to aim for perfect and just waste your time? It is not possible to make a perfect plan during Sprint Planning in a complex environment.
Settle for good enough and make the Sprint Plan better as more is learned. You will spend less time planning and you will have a better plan. Just add details as you figure more details out.
4. Not planning the most valuable thing due to uncertainty or fear of failure
Teams often refuse to to work on a feature, because they are unsure how to build it. Even if that feature is the most valuable thing to work on. The team is scared to fail and unsure if they will succeed.
As a result of this valuable features get delayed. We first need to do a few Spikes to make it possible to work on the feature.
If the feature is really valuable and time-to-market is important, this may be the wrong approach. As a Product Owner I do not want to go through a spike-refinement cycle that delays time-to-market by at least 2–4 weeks (depending on Sprint length).
To prevent delaying valuable features, I try to make the team feel safe to fail. If I ask them to work on something with high technical uncertainty, then I tell them I accept responsibility for the increased risk of failure.
You need to make the team feel safe enough so they are willing to take the leap. If this really is the most valuable thing to work on, and it’s not a matter of can we build it but how do we build it, then just get the team to work on it immediately.
Counter-intuitive as it may seem, you lower risk by working on technically difficult things sooner. You will discover the risks that matter earlier. Many risks are not discovered before you actually perform the work. No matter how much time you spend analyzing and doing spikes.
So how do you pick up these technically difficult and valuable features in a responsible way?
Set a small Sprint Goal that seems attainable. Start with coding a small Proof-Of-Concept that will guide the next Sprint Backlog items that need to be created. It is essential the POC contains code, to ensure you will reduce risk and uncertainty as much as possible. Then after the POC is delivered, decide on the rest of the Sprint Backlog Items with the whole team.
It pays off to get started on the most valuable thing immediately. The increased risk of failure during the Sprint may be offset by the value of being able to deliver it sooner. If there even is an increased risk of failure, often it actually may be safest to start working on it sooner.
5. Making sure everybody is busy or focusing too much on velocity
A lot of teams feel the urge to maximize their velocity each Sprint. Did we do 50 Story Points last time? Let’s try to push ourselves to do 55 Story Points this Sprint.
Then the Sprint ends and only 10 Story Points were finished. Everybody was focused on being busy instead of making sure the work flows from left to right on the Scrum board as quickly as possible.
Under-committing during Sprint Planning is a way better approach. By doing this you leave room for learning and other unexpected events. Your team will focus more and collaborate better. Features will get delivered sooner, as developers will wait less for each other.
As the Sprint Backlog is flexible after Sprint Planning, you can always add more work later if necessary if time permits. Under-committing also decreases the chance of work carrying over to the next Sprint.
6. Not handling carry over work appropriately
It is always possible that there is unfinished work at the end of the Sprint. Teams then waste a lot of time during Sprint Planning to account for carry over backlog items. Some teams even waste time re-estimating the backlog items.
It is difficult to assess how much work remains on a carry over backlog item. Even if it is 80% finished, it may turn out the last 20% takes just as much time. The safest approach is to over-estimate rather than under-estimate the amount of work remaining
I count carry over items for their full amount of Story Points. Using this approach prevents a lot of discussion and waste. The result is good enough to plan the next Sprint.
Counting carry over items in full, means you will over-estimate the amount of work that is remaining. And as you can always add more work later during the Sprint, there is no risk to following this approach and you will save a lot of time.
Under-estimating work is risky, as it may result in all developers being busy and unfinished work at the end of Sprint. This is why I would only re-estimate stories that turn out way bigger than expected.
An example would be a big story twice bigger than expected. If a Story turns out to be half as big, I do not re-estimate. Sometimes you just get lucky and you can add more work later during the Sprint if necessary.
Of course feel free to use a different approach to handle carry over work. The important point is you have a way of handling it.
How do you make your Sprint Planning meetings short and effective?
Doing the following during Sprint Planning sets you up for success:
Start by crafting a focused Sprint Goal. It is the only thing that really matters when planning a Sprint. All other details can be figured out later.
Encourage flexibility during the Sprint. The scope of the Sprint is flexible, as long as you can still meet the Sprint Goal. By supporting changes, the team has the freedom to come up with a better plan as more is learned.
Do not iron out all details of the Sprint Backlog. Trying to nail all details produces a lot of waste. Later during the Sprint you will have more information to make a better plan in less time. Less rework of the original Sprint Backlog will also be needed.
Make it safe for your team to fail. When the whole team embraces failure you can speed up the time-to-market of valuable features.
Do not focus on keeping all team members busy. It is more important that the work you start gets finished as soon as possible. When everybody is busy all work in the Sprint will become congested, like in a traffic jam.
Do not waste too much time discussing carry-overs. Just carry the full Story Point amount over. When in doubt over-estimate the work remaining. You can always add more work later during the Sprint.