How to do effective Sprint Planning as a Product Owner?
Doing Sprint Planning in 5 easy steps
How to do effective Sprint Planning as a Product Owner?
Doing Sprint Planning in 5 easy steps
I recently wrote an article called ‘ 6 common mistakes when doing Sprint Planning’. Instead of pointing out all the things that can go wrong, I will explain how you actually should do Sprint Planning.
The two articles together should paint a pretty complete picture about how to do effective Sprint Planning with your Scrum team. If I missed something important, let me know in a response!
I will now share the 5 basic steps I follow during Sprint Planning.
1. Wrap up the previous Sprint
A new Sprint should start by wrapping up the previous Sprint. The three main topics you should cover are:
Are there any Sprint Backlog Items that have not been finished?
Were there action points raised during the Sprint Retrospective?
Did you receive feedback from Stakeholders during the Sprint Review that needs to be included in the product?
Handling unfinished work
If work did not start on an unfinished Sprint Backlog Item, then move it to the appropriate position in the Product Backlog. If work was started already, you should probably carry it over to the next Sprint.
As a general rule, you should never drop items your team has worked on if you still want to have them in the product later.
There can be exceptions to this rule. Picking up unfinished work many Sprints later results in a lot of waste and inefficiency. So it is better to prevent this from happening, but sometimes there is a good reason to accept incurring the cost.
My preferred approach for handling carry-overs is to just count them in full for the next Sprint, because the last 20% may take 80% of the time. But if you have a different way of handling it, that’s fine as well.
The important thing is that your Scrum Team has a way of handling it.
Re-estimating is a waste of time. All estimates are made before you start working on something. When you re-estimate something you break this rule.
We all know estimates can be off, that’s why it’s an estimate. Fixing them afterwards won’t change the fact they were wrong.
If a Product Backlog Item turns out to be exceptionally bigger than expected then try to manage the scope. An approach could be to split off one or more of the complicated parts.
By doing this you capture the unforeseen complexity in new Product Backlog items that can be estimated. If it is not possible to split parts off, just accept your estimate was off and do the work.
Add action points from Retrospective to the Sprint Backlog
Check if all action points from the Retrospective have been added to the Sprint Backlog. Make sure the team not only spends time delivering things. It is important to spend time improving the way of working.
It’s easy to focus on churning out features and forgetting to spend time to improve your way of working. Picking up all these action points pays off in the long run. It helps the Scrum Team to discover better ways of working.
Include feedback from the Sprint Review
The Sprint Review may result in valuable feedback to improve your product. The following topics should be addressed in the Sprint Review according to Scrum Guide:
The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning;
Review of how the marketplace or potential use of the product might have changed what is the most valuable thing to do next; and,
Review of the timeline, budget, potential capabilities, and marketplace for the next anticipated releases of functionality or capability of the product.
Make sure the feedback from the Sprint Review is included in the appropriate position in your Product Backlog.
2. Make sure the Product Backlog is ordered and create a draft Sprint Goal
The Product Backlog, a list of items your Scrum Team(s) may work on, should be ordered to best achieve your business goals. Items at the top will be picked up sooner than items at the bottom of the backlog.
Before Sprint Planning the Product Owner should come up with a draft Sprint Goal that can be met by pulling in items from the Product Backlog. Sometimes this may not be possible, in case the Product Backlog Items have not yet been created. In this case you should still start with a draft Sprint Goal.
Make sure you have one or two back-up Sprint Goals ready, if for whatever reason your team is not able to start working on that Sprint Goal you had in mind. This just helps to make the meeting more efficient in case the meeting takes a different direction than expected.
3. Stress that the Sprint Backlog is flexible during whole Sprint.
Each Sprint the following variables come into play:
Time
Budget
Quality
Scope
Time is fixed, because the Sprint ends when the timebox expires, no exceptions. Budget is fixed, because the cost of your team per Sprint does not change. Quality is fixed, because everything the team delivers must meet the Definition of Done.
Therefore, Scope must be flexible during the Sprint. What isn’t flexible is the Sprint Goal. The team commits to delivering a product increment during the Sprint that will meet the Sprint Goal.
If the team needs to add or remove things from the Sprint to meet the Sprint Goal, then work together with your team to make sure this happens.
4. Make your team feel safe to fail
There is no need to come up with a perfect plan during Sprint Planning. You can add detail as more as learned. So don’t waste time sitting in a room for hours to pretend you can figure out all the details before you even started.
Your Sprint Plan will never be perfect. Make your team feel safe to fail by creating a safe environment. As a result they will feel comfortable adding detail as more is learned. The only thing that really matters is a clear and overarching Sprint Goal.
I even have started Sprints with just a Sprint Goal and two or three Sprint Backlog items. The team was cool with it, because they trusted me to accept failure. I trusted them to do their best to meet the Sprint Goal while facing massive uncertainty.
If you don’t make your team feel safe, then don’t expect flexibility from your team.
5. Finalize the Sprint Goal and let the Development Team make a Sprint Plan
Before Sprint Planning, the Development Team should figure out their capacity to pull in work. Then based on the capacity they provided, you should together pull Product Backlog Items in the Sprint that will meet your draft Sprint Goal.
If there is sufficient capacity to meet your draft Sprint Goal, then the whole Scrum Team together discusses whether you agree to make it the final Sprint Goal.
If you need to create new Sprint Backlog items to meet the Sprint Goal, then create them and estimate them on the spot. If capacity does not permit to pull-in sufficient Backlog Items to meet the Sprint Goal, then you rework the Sprint Goal until it can be met with the current capacity. Or you select another Sprint Goal and repeat the same process.
The Development Team creates a plan for meeting the Sprint Goal during the Sprint. There is no need to make it perfect. You can update it as more as learned.
The Sprint Plan aids in inspecting progress toward the Sprint Goal during the Daily Scrum. By having a plan you can check whether you are on track to meet the Sprint Goal or not. It also makes it possible to adapt your course if necessary.
Planning a Sprint in just 5 easy steps
So these are the 5 simple steps you can do to plan a Sprint:
Wrap-up the previous Sprint.
Make sure the Product Backlog is ordered and create a draft Sprint Goal.
Stress that the Sprint Backlog is flexible during the whole Sprint.
Make your team feel safe to fail.
Finalize the Sprint Goal and let the Development Team make a Sprint Plan.
I would say after the 5th point now you are ready to start the Sprint, but it starts automatically after the previous one ends :-).
Let me know if you have any additions or remarks, and I will gladly update this post!