Last month I talked about a team backlog and how to organize it. But for me, Sprint Planning is one of the most important aspects of Agile. If repeatedly done well by the team, it can create strong alignment and engagement to deliver amazing solutions.
But, when it is badly executed, it can destroy the team's performance and motivation. As it is usually said: Garbage in, garbage out.
The Product Manager (or Owner) has a key role in the Sprint Planning. I believe that it is the role that has the main responsibility to drive it.
With that said, those are my recommendations for Product Managers to have a bigger chance of making Sprint Plannings successful and in the process the Sprints itself.
1. Learn Continuously
First of all, even with the tips below, each team has its own work style, needs, and challenges. So keep learning and discussing improvements with a positive mindset.
A retrospective, at least once a month, is a must for creating a continuous improvement mindset. If things fail, discuss the reasons and potential improvements. If things were great, try to keep the principles around it for the next Sprint.
2. Define a Sprint Goal
Each Sprint should have a Sprint Goal that creates a sense of Milestone to pursue for the team. The goal has to be agreed upon before starting the Sprint by all team members. They are the ones responsible to achieve it.
To make things easier, remember to align the Sprint Goal to the bigger picture, such as the Product Vision, an Initiative that the team is responsible for, or a KPI that the team is trying to improve.
3. Involve stakeholders
Not involving Stakeholders diminishes the team’s credibility. Involve them as much as possible in your Sprint Goals. Most important is to create transparency and avoid surprises.
Also, make sure that you do something with their requests, even if it is just a big ‘No’. Stakeholders should know if you are not going to work on their request or when their request might be prioritized. Remember, no surprises are always better!
4. Align an estimation technique
Make sure to align with the team on how the Sprint commitment is going to be made. Usually, there are many estimation techniques to try to nail down how much work can be done. Check my article about Estimations here.
5. Prioritize the work inside the Sprint Backlog
The Sprint Backlog will most likely have more than 1 ticket, right? If so, organize the tickets so the team can understand the priority. An easy way to do that is to simply have the top ticket as the highest priority and the bottom ticket as the lowest one.
We all know that many Sprints are not 100% done due to many factors, so you, as a Product Manager, need to guarantee that what is more important is what the team focuses on.
6. Limit the amount of context switch
Tech workers know that unfortunately, switching contexts is part of the game. As a Product Manager, you should try to protect the team as much as possible from it. Apart from the Sprint Goal, the team will surely work on other activities, such as:
Resolving bugs
Doing small quick wins/tweaks
Supporting other teams
or even the usual critical ad-hod requests.
So yeah, there is already enough context switch. If the Product Manager on top adds additional context switch, it is a receipt for failure. So always keep this issue in mind.
One effective way to help is to limit the number of different Epics in each Sprint. I would say two Epics per Sprint sounds like an ideal number. Make sure to align with the team.
7. Leave room for flexibility and unplanned work
As said in the section before, ad-hoc work will happen, so leave room for it. Don’t fill your sprint completely. If the team finishes the Sprint work, they can always grab the top tickets from the Backlog (if they are already groomed)
8. Groom tickets
To have a focused Sprint Planning. The team should get two things done prior to it:
Most tickets that are going to be part of the Sprint are already aligned between all team members.
These Tickets have enough information so the team members feel comfortable to start working on it from the start of the Sprint.
Those are the tips that helped me make Sprint Plannings easier. In my experience, applying them usually make it a breeze of fresh air for the team.
What is your take on it? Do you agree? Any additional tips?
Comments