Sprint retro. Sprint review. Sprint planning. Just what do these all mean? In this quick guide, we take a deep dive into everything you need to know about sprint planning.
What is a Sprint Planning Meeting?
As the name suggests, this is the Scrum planning session that is conducted to plan the upcoming sprint.
Using your collective knowledge of what happened in the past sprint (during the sprint review and sprint retrospective process, which are two separate meetings that are also a part of the Scrum cycle). The goal of the sprint planning meeting is to define a set of outcomes, which is never a bad thing (in sprints, but in life too!).
The Hows, Whats, Whos and More
Sprint planning does not have to be a complicated thing! Here’s a quick breakdown of who does what, when, where and how:
The product owner will share their objective for the sprint - for example, to develop a new feature. They'll then sort the backlog items related to that objective. The scrum team will have to decide how to make the objective happen.
The Dev team works together to plan out what they need to make the objective happen on their end. It’s worth mentioning here that the sprint planning meeting is often a sort of negotiation between the outcomes set by the Product Owner, and what the Dev team can realistically deliver.
The Product Owner, Dev team and any other relevant stakeholders will be present at the sprint planning meeting. It's incredibly important that all stakeholders are relevant, to say their piece and offer realistic goals… or someone could end up with more work (and unattainable goals!) than they'd bargained for.
Perhaps the most important aspect of the whole agile sprint planning meeting are the outcomes that are set and agreed on. Anything agreed upon will be broken down into stories and added to the sprint backlog, ready for everyone to start working once the sprint commences!
Sprint Planning Meeting Agenda
Unlike other areas of the Scrum process, sprint planning meetings require a solid structure, patience and collaboration.
You can expect a mix of:
- A refined product backlog, ready to go with the Product Owner’s needs.
- Outcomes and action items from the last sprint review, for reference.
- Calculations of commitments - both past and present.
- Determining the velocity and capacity of the team during the upcoming sprint, according to stories and overall goals.
In general, the sprint planning meeting will follow this structure (but you may do it differently, depending on your team’s needs):
- Overview and big picture sharing.
- New information for the upcoming sprint.
- Capacity and velocity discussion.
- Known issues discussion (according to sprint review outcomes).
- New backlog items to add to the sprint.
- Set estimates for work .
- Discussion of the overall plan and confirmation of stakeholders.
Sprint Burndown Chart
This is an integral part of the agile sprint planning meeting. It's a graphic of how quickly the backlog of a sprint is completed, which should (if all goes according to plan) slope downwards, and come to an end by the time point of the sprint’s completion.
As stories are completed, the graph curves downward more sharply. It confirms how much work remains, NOT how long it takes to do it!
In the best case scenario, the sprint burndown chart has a very sharp slope downward; in the worst case scenario, the burndown chart remains pretty flat.
User Stories, Estimations, Splitting and Mapping
There’s a lot of estimation (based on experience and past sprint reviews) during the agile planning meeting.
The team obviously needs to estimate what they can legitimately do during the sprints, according to their capacity and planned velocity of completed items.
But - and it's a big ‘but’ - estimation is NOT the same as ‘commitment’. Here’s why:
- The product backlog will be split into user stories. This will likely be sorted according to the product owner, not the actual Devs who will be working on them.
- These stories will need to have an overestimation assigned to them, regarding the time they will take to complete.
- These user stories will likely need to be split down into smaller chunks of manageable user stories.
- Once these have been split, they need to be mapped out according to time, assigned owner, and overall priority.
Only once all stakeholders have signed off on these, do they become a commitment.
Sprint planning meetings best practices really run the gamut of anything and everything, and depend on the way your team does things. To read more about it, check out our guide to sprint planning best practices.
Solid agile sprint planning relies on certain rules, whether spoken or unspoken:
- Always have a sprint goal - defined, out loud, and (if possible) written down for all to see and keep at the forefront of all discussions.
- All stakeholders need to agree and be happy with the outcomes.
- The sprint planning meeting needs to remain focused on the upcoming sprint - it's not the place to point fingers or discuss past sprints other than in a truly constructive, or highly related manner to the upcoming sprint, and even then, only if it directly relates to it).
- It's always better to overestimate than underestimate when it comes to capacity and velocity.
Using a sprint planning template will help the entire team to align in sprint goal setting, capacity estimations and make each sprint as effective as it can be.
Using a sprint planning template will allow you to:
- Close the previous sprint decisively, and with learning outcomes
- Get your team aligned with the upcoming sprint’s goals
- Plan the team’s capacity
- Share the team’s projected velocity
The sprint planning meeting activities relate around dissecting the product catalog, and assigning user stories:
- Discussing and setting the overall sprint goal.
- Reviewing the highest priority stories and the product catalog.
- Determining what the Dev team can and can't do (estimating) according to their capacity and velocity.
The sprint planning meeting is a precursor to the sprint. If it’s not up to scratch, the outcome of the sprint will suffer. The planning session should leave each team member with two outcomes: detailed information and focus. Firstly, make sure the team is aligned on all aspects of the sprint - ownership of tasks, the sprint backlog and the sprint goal should be known by each team member otherwise the team faces the problem of being disconnected. Secondly, each team member should be aware of their own exact tasks and what it takes to complete them - this will ensure that team members don’t stray from the path of the sprint. Remember that planning is also just that, planning. Almost always unplanned events come into the sprint but a good sprint plan should allow these events to not derail the whole sprint - so allow room for unexpected items that might pop up.