Nailing your Sprint Planning Agenda
There are only two things you need to worry about with planning:
- Are you planning to do the right things?
- Are you planning to do the things right?
Doing this effectively is one of the most important things a PM does. An amazing agenda will help.
Give me six hours to chop down a tree and I will spend the first four sharpening the axe.
-Lincoln (but not really)
Getting ready for your planning meeting will often take longer than the actual planning meeting itself. And that’s not a bad thing. Spend time working out where your team is at on their roadmap, reviewing your dependancies and tracking your results to date. You’re aiming to get a rough idea of what your sprint goal should be for the upcoming sprint.
Hopefully it’s not a surprise, you’ve built out a roadmap, but it might need refinement. Maybe you need to be more explicit because last time there was confusion, maybe you need to really stick to the outcome because the team felt too constrained last time or maybe you need to accelerate timelines for some reason. As you refine your goal, share it with peers, your lead and your team in casual settings. If there’s another team you’re working closely with, grab a coffee and discuss your respective goals.
Your aim is to be confident that this is the right goal and that you should be able to achieve it (even if you don’t know how exactly).
Set the Agenda
Next up, make sure you get your agenda together and share it with the development team. If possible, you want to walk them through the agenda 1-1 before hand. This will help defuse any potential difficult areas and get them thinking about how they can meet the goal.
Personally I discourage public commentary on the agenda before hand, but I know that this works well for others. By limiting discussion to 1-1’s I can timebox it and avoid distracting from the current sprint, whilst also ensuring people actually read it. It’s a time investment, but well worth it. Especially with teams that aren’t fully aligned (yet).
As for the Agenda itself, here’s what I use.
- Dates – be explicit about when the sprint starts/ends (especially if you’ve got remote team members).
- Status – call out whether your sprint is in planning, pre-planning or review.
- Summary – when you’re planning this will call out your objectives, after your review this becomes a summary of what got done.
- Progress and Results – reference the bigger picture. Whether it’s explicit OKRs or just your position on the roadmap. This is also great for bringing in company wide results.
- Retro actions – what did you decide to change last sprint? Did you do it.
- Upcoming events – look at who’s going to be in the office and company wide events you should consider.
- Notes – always have a catchall space for those extra notes!
- Sprint Goal – what is the main business outcome you’re gunning for?
Whilst the above might seem like a lot, every element plays a part.