Jory MacKay on December 14, 2018 5 Steps to Master Sprint Planning: Template, Checklist and Guide
Sprints are the backbone of any good Agile development team. And the better prepared you are before a sprint, the more likely you are to hit your goals. Spring planning helps to refocus attention, minimize surprises, and (hopefully) guarantee better code gets shippied.
But maybe more than that, sprint planning aligns the development team with the product owner. Like any relationship, the one between you and your team requires communication and clarity. And taking the time to sit down and make sure that your expectations are understood and can be done by your team is key to keeping everyone motivated and productive.
So how do you make sure you’re doing as much as possible before your sprint to ensure success?
Sprint planning comes down to a few key steps, from making sure your product backlog is properly groomed to framing the sprint, and running an effective sprint planning meeting. In this guide, we’ll run you through everything you need to know (plus give you a few additional resources to help you through your own sprint planning session).
Before we dive in, here's the outline of this article:
Step 1: Review your product roadmap
The goal of an agile sprint is to ship better software. But that’s easier said than done. It’s easy to lose sight of the bigger picture when you’re knee-deep in code fixes and updates. So how do you know what you’re focusing on is the right thing?
As the product owner, it’s your responsibility to keep the high-level product view always in sight. Before you meet or do any sort of sprint planning, you need to get back into your product roadmap and ask some serious question.
Are you building features that move your product vision forward? Do you even have a product vision or are you just reacting to loud customers? The first step in sprint planning is to know where you want to be not just at the end of this sprint but in 6 months, a year, or more. As scrum master and agile coach Robbin Schuurman writes:
“There are always too many features that would add value, therefore creating a lack of focus on the vision and goals. By focusing on the features too much, the roadmap will turn into an overloaded product backlog, instead of a high-level, strategic plan for the products' future development.”
This isn’t a post on how to properly make a product roadmap. But simply a reminder to ground yourself in your long-term vision before getting swept away by sprint planning. Sprints shouldn’t just tick off boxes. They should always get you closer to the ultimate vision of your software.
Step 2: Groom your product backlog and update user stories
With your mind primed with your product vision, it’s time to dive into your backlog and start pulling out user stories to tackle in the next two sprints. Your product backlog is all of the bugs, issues, and user stories (informal, natural language descriptions of one or more desired features, often written from the perspective of your actual users).
Why two? The short answer is context. Rather than just focus on what’s immediately in front of you, it’s important to know what this sprint is building towards. How will your choices now on what to build impact your next sprint or the one after? Any planning session will benefit from a big of foresight.
Now, unless you’ve stayed on top of your product backlog, these stories will most likely need a bit of grooming (or, cleaning up). Sprints are all about optimizing your team’s time. So why bring them stories that are dated, disorganized, or unclear?
A 30-minute product backlog grooming sessions helps fill in the blacks on user stories that are lacking detail or context from you, the product owner. This means making sure each story:
- Is prioritized with the most important work listed at the top
- Is clear and fully-formed so the team can start working on right away
- Is up-to-date in context (to the larger product roadmap) and estimate (of complexity)
It’s important to groom these stories before meeting with the rest of the team so you’re not wasting their time going over small details or asking for clarification. Planio—our project management software—offers a few unique features that can help speed up your grooming process.
First, you can create categories for issues, which will allow your team to quickly see the kind of work each task involves. You can also use sub-issues to break up larger user stories into the individual technical tasks needed to see them to completion and connect relevant tasks and stories together.
Next, we’ve provided enough space so that each issue in your backlog can include all relevant information. This including a proper description, priority, status, estimated time, and even acceptance criteria. One tip from the team at Software AG is to use checklists for acceptance criteria. This way, during a sprint review meeting, the customer or product owner themselves can tick off the criteria.
Lastly, you can start planning a new sprint with one click using the Sprint planning button in the sidebar. Simply name your new sprint, set the start date, and drag freshly groomed backlog issues into it.
Pro Tip: Use “Story points” to properly estimate tasks
One of the most difficult parts of proper sprint planning is being able to estimate how long tasks will take and just how much can get done during your sprint.
Agile coach Mike Cohn uses the example of two runners talking about how long a 5km race would take to run. One says 25 minutes, while the other says 45. Regardless, they can both agree that 5km is shorter than a marathon.
One way to make things clearer is to use “Story points”—values you agree on as a team that allow you to talk about the relative investment of a task. For example, some teams use the Fibonacci sequence of 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, etc… This way, instead of arguing whether a task is a 12 or a 13 in effort, you can quickly agree it’s more of a 13 than an 8, but not a 21-pointer.
You can switch to estimating in story points in Planio by going to Administration → Agile ** and selecting **Story Points as the estimate units. Story points will show up on your Agile board and can even be automatically applied to only tasks associated with sprints (by selecting a specific “tracker” to use story points).
Step 3: Propose a sprint goal and backlog before the sprint planning meeting
With a properly groomed product backlog it’s time to actually start planning your next sprint. Let’s start with the basics. Before a sprint gets underway, you need to know what you’re trying to accomplish and how you’re going to get there.
The what is your Sprint goal: Simply put, what you want to have delivered by the end of the sprint. Sprint goals are a great “why” for your team—keeping them motivated. But they’re also great for communicating what’s being worked on to people outside of your team. For example, if you’re running an ecommerce site, it might be something like: “Develop the checkout process: Pay, choose shipping, include discounts.” or “Update shopping cart functionality to include remove and update quantities.”
Above all, your sprint goal needs to be realistic based on the scope of work and the size of your team. As ultimately, it will be what the success of the sprint is judged against during your sprint review. Not the individual tasks and stories completed.
To figure out what “realistic” means for your team, you use what’s called your team’s “average velocity”. This is the amount of work that typically gets done in a sprint of the same length as well as any factors that might influence it, like vacations, public holidays, or other interruptions.
If a team is new and you don’t have an average velocity then the product owner shouldn’t create a draft like this. Instead, the team should come together to discuss what can be done so everyone has buy-in. Trial and error isn’t always the best strategy. But it is a good way to make everyone on the team feel like they’re working together.
Next, the how is your Sprint backlog: the list of user stories that will need to be completed in order to achieve your sprint goal.
It’s entirely possible that you’ll have separate sprint planning meetings to go over your goal and your backlog. However, whether you do it all at once or on separate days, it’s important that your team has time to look over what you’re proposing beforehand so they can form a good understanding of what needs to be done and what tasks are most important.
Step 4: Use data and experience to supercharge your Sprint planning meeting
What’s going on? We’re already at step 4 and we haven’t even had the sprint planning meeting yet! Trust me, I know. The thing is, your sprint planning meeting(s) sets the stage for the next few weeks or month of work. And as such, the more prep you can do beforehand, the better.
But just because it’s an important meeting doesn’t mean you should let it go on and on and on. There’s nothing worse than long, ineffective meetings (I’m talking about you, “weekly-status-update-to-satisfy-the-micromanaging-CEO”). And when you’re talking about the future of your product, it’s easy for those meetings to go off the rails.
That’s why the Scrum Guide suggests timeboxing your sprint planning meeting to just 8-hours for a month-long sprint (not all at once, of course). For shorter sprints, your meetings should be adjusted accordingly. Your scrum master is responsible for making sure these meetings happen and stick to their agenda.
Now, let’s get into the specifics of what happens during an effective sprint planning meeting.
Who should be at your sprint planning meeting?
This meeting is important for everyone on the team, and whenever possible, the entire team should be there. Each person has specific responsibilities and needs that they want met, and hearing from everyone is the only way to make sure you come to a consensus.
- Product owner: Sets the goals, priorities, and explains context around the choices for this sprint. They’ve ensured backlog items are properly groomed and also that the team’s skills, capabilities, and resources are aligned with the needs of the sprint.
- Scrum master: Facilitates the meeting by preparing and sharing the agenda, setting up the location, and making sure everyone’s there. For remote development teams, this means having video conferencing software like Zoom ready and tested.
- Agile team members: Ask questions and propose concerns about the sprint backlog. The development team can also bring in outsiders with domain or technical advice to help plan.
What happens during the sprint planning meeting?
The meeting starts by setting the stage and providing context. If you’ve already had a review and retrospective of your last sprint (which we highly recommend), the scrum master can go over any action items or lingering issues.
Next, the product owner updates everyone on product and market changes before sharing the sprint goal. This helps align everyone and gives context behind this current sprint.
Finally, it’s time to agree upon the sprint backlog. By now, everyone on the team has had a chance to look at the user stories proposed by the product owner and can start to give feedback. If you’ve provided enough stories for two sprints (as we suggested earlier), this will mean breaking down what can be done by the team in the given timeframe.
There’s a few steps in doing this:
- Break down user stories into technical tasks: Because user stories are informal descriptions of features, the development team needs to break them down into the actual tasks needed to make that feature work. In Planio, you can create tasks as sub-issues and keep them associated with the respective (parent) user story.
- Revisit your definition of “done”: This is the snapshot of what your software will look like at the end of the sprint. It’s important that the people doing the work (the developers) and those inspecting it (the product owner/other stakeholders) are both on the same page here.
- Clarify the acceptance criteria: Just like you need to know what “done” looks like on a sprint-level. You need to know what is acceptable on a task-level to call it complete. This is usually up to the product owner to decide, however, it’s good to have a conversation around it as a team.
- Development team agrees on their capacity for the sprint: While the product owner can help clarify the selected items in this sprint, an important part of Agile development is that it’s the responsibility of the development team to decide what can get done in a sprint. The development team agrees on their capacity and designs a system of how they’re going to get the work done—self-organizing and breaking the work planned for the first day down into small units.
How many (and which) tasks should be in a sprint backlog?
While what specific tasks and user stories you include in your sprint will be up to the development team, there are a few tips here that can help you avoid headaches.
First, understand your team’s capacity. How many total work hours do you have during this sprint? For simple math’s sake, let’s say you’ve got a team of 10 working 8 hour days for 2 weeks. That’s 10 * 8 * 10 = 800 hours. Right? Not quite.
Most teams deduct 20-40% to give a more realistic number that represents downtime, overhead, and planning mistakes (like missing a crucial dependency between tasks). Whenever possible, be more realistic on what can get done rather than what should get done.
Second, don’t forget to include bug fixes and reducing technical debt. As scrum master and Agile coach, Stefan Wolpers, explains:
The rule of thumb is that 25% of resources are allocated every sprint to fix bugs and refactor the code base. If the product owner ignores this practice, and the development team accepts this violation the scrum team will find itself in a downward spiral. Its future product delivery capability will decrease.
Lastly, use data from a tool like Planio to help estimate tasks and effort. You can look at your Velocity chart to see the output of your team during a sprint. This is a powerful tool for helping estimate how much can get done.
Then there’s the Lead time chart, which shows the time between an issue being opened and closed. Many teams using a Kanban approach will try to optimize for lead time over velocity.
Once you’re actually working through your sprints, the Burndown chart shows you how a project is progressing (and how adding new feature requests will impact your plan).
Lastly, the cumulative flow chart shows how issues are flowing through different statuses and can help answer some key questions, such as:
- Are issues being completed?
- Is there any particular status that is holding things up?
- How long does it take to go from new project to value created?
- Is the scope of the project changing over time?
Step 5: Walk through each user story and describe what tasks need to be done
There’s a desire to rush through this next part of the exercise and just get to it. But the more detailed planning you can do as a team, the less likely you’re going to hit roadblocks a week or two into your sprint.
Go through each task as a team and capture the key points, rationale, and concerns on the relevant Planio issue. Think about questions like:
- What’s changed since this story was written?
- Is the estimated time still valid given recent work?
- Are there are dependencies we should be aware of?
- What about testing? Can we automate it?
- Do we have the skills to complete this task? Are specialists required and if so, how can you optimize their time so they don’t become a blocker?
- What implications will this story have on the rest of the product? Are there other teams that need to be involved with this story or give sign-off on the design or code?
A good scrum master will help facilitate these questions and make sure that every angle is covered before you get to work. It might seem like a pain at this point, but the work upfront will pay dividends later on.
In Planio, you get tons of flexibility with task management and can add everything from in-depth descriptions to status, priority, category, sprint, estimate time, percent done, due date, files, and “watchers” (people who will be notified when updates are added to the issue).
Finally, get verbal commitments from everyone in the room
At the end of the sprint planning meeting the development team should be able to explain to the product owner and scrum master just how it’s going to work to hit the sprint goal. It might seem a little unnecessary, but it’s good to get verbal commitments from everyone in the room, explaining what they’re doing, why, and the goal.
Communication is key to any team. And this final check is key for making sure everyone is pointed in the right direction before they take off on their sprint.
Ready, set, sprint!
As French writer and pioneering aviator, Antoine de Saint-Exupéry, famously wrote:
“A goal without a plan is just a wish.”
Proper sprint planning does a lot of things well. But most of all, it turns your goals from a wish into a step-by-step guide. If you’ve followed this guide, at the end of your sprint planning session you and your entire team should walk away with:
- An agreed-upon Sprint Goal and a clear definition of “done”
- Commitment to a realistic sprint backlog
- Understanding of the bug fixes and support work included in the backlog
- Detailed tasks for each user story with an estimation and acceptance criteria
- Due dates and scheduled scrum meetings
Now, all you have to do is the work.
