Sprints form the foundation of any high performing Agile development team (you can find out just how agile you are here). And good sprint planning is absolutely vital. It gets the product owner in sync with the development team, helps minimise surprises, focus attention to where it’s most needed, and ultimately result in higher quality project completion.
But there are secrets to doing it right.
When you understand the key steps to sprint planning and a few tips to make it even more effective, its possible to align expectations and get everyone in your team super motivated and productive.
So let’s explore the secrets of effective sprint planning.

The 4 key steps

Here are the four steps that should form the basis for your sprint planning process:

Step 1: Review the product roadmap

When reviewing the product roadmap, don’t forget to also take a step back and draw focus to the product vision. The purpose of sprints is to move your product vision forwards. It shouldn’t be simply to react to disgruntled customers. So before you do anything else, you should be thinking how the sprint fits into the product vision 6 or 12 months down the track.
Secret tip – Before you ever move beyond Step 1 in each new sprint planning meeting, refocus everyone’s attention on the higher level product view. And don’t forget to organise coffee or light refreshments, everyone involved in the sprint planning meeting will thank you for it.

Step 2: Groom the product backlog and update user stories

The product backlog grooming exercise helps add detail to user stories that are unclear or lacking context. Each user story should be fully formed and clear so the team can start working on it immediately. It needs to be up to date in the context of the product roadmap and expected level of complexity. The user stories should also be prioritised so the most important work is listed at the top.
Secret tip – One of the hardest aspects of good sprint planning is accurately estimating how long tasks will take and how much can be achieved in each sprint. So it’s beneficial to use “story points” to help you accurately estimate tasks. Rather than using standard hours and minutes, the team decides on the relative effort required for each story point value. Many teams use the Fibonacci sequence: 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, etc but you can use any values that the team agrees on. Using story points rewards team members for completing tasks based on difficulty, instead of time spent, which keeps team members focused on shipping value, not spending time.

Step 3 – Set the sprint goal and backlog

Now that you have a groomed product backlog, you can set the actual goal of the sprint. It needs to be very clearly determined, for example – create a checkout process for the e-commerce site that includes payment, shipping, and applying any discounts. The goal needs to be realistic and based on the team’s average velocity. Don’t forget to factor in any outside influences that will affect this such as public holidays, personal holidays, or other known interruptions. Finally, set your sprint backlog, which is the list of user stories that will need to be completed to reach the sprint goal.
Secret tip – the meeting to set your sprint goal and backlog doesn’t have to be part of the main sprint planning meeting. In fact, you may find its beneficial to set the goal and backlog in a separate meeting before the main meeting. That way the team has an opportunity to review the proposed goal and backlog and understand which tasks will be the most important.

Step 4 – Set the tasks

Break down the user stories into the actual technical tasks that will need to be done to make that feature work. This step also involves revisiting the definition of “done”, which forms the snapshot of what your software will look like at the end of the sprint. Make sure the product owner, other stakeholders, and the development team are all on the same page here. The development team can then agree on their capacity for the sprint. They will be the ones designing the system of how they will actually get the work done, and breaking the work down into smaller units.
Secret tip – get a verbal commitment from everyone in the team. At the end of the meeting the development team should be able to clearly explain to the product owner and scrum master what the sprint goal is, what they’ll be doing to achieve it, and why. It might seem like overkill to rehash this information but don’t underestimate the benefit of summarising and communicating to everyone in the room what the team’s direction is so that everyone is clear and on the same page.
So that’s it. All there’s left to do now is sprint! By following these steps and incorporating the tips, you should be able to take your sprint planning to the next level.
If you’re building your Agile development team please get in touch with Finite IT here.

Share this article on Facebook on LinkedIn