Sprint planning: a guide

Kanban, Scrum, SAFe, LeSS—regardless of the agile framework you practice or borrow from, your team has to stay in sync on goals and priorities. This is where having a sprint plan comes into play. In this guide, we’ll cover everything you need to know about planning your own sprint.

What is a sprint?

In agile, sprints are designated periods of time for completing increments of work, typically aiming to result in a “release” at the end. The purpose of the sprint is not to release a large feature set but rather to release small features and product improvements incrementally to add immediate value to the user and the business.  A typical sprint is usually 2-4 weeks, and major product releases usually take multiple sprints to complete.

What is sprint planning?

Sprint planning is one of the four agile ceremonies. It occurs at the beginning of every sprint and allows developers to come together with the product owner to review team goals and the product backlog and decide on what work is reasonably achievable in the next sprint.

When planning a sprint, you typically cover:

• Backlog review
• Work capacity and resourcing
• Proposed sprint goals to be negotiated among team members

Roles and responsibilities for planning a sprint

The product owner is responsible for leading the sprint plan meeting. However, it’s important that the whole development team is there. A major goal of the meeting is for the development team to negotiate with the product owner regarding what reasonable goals are for the sprint, which requires everyone’s technical expertise.

How to plan a sprint with your team

Set a meeting agenda and timeframe

When you send out a meeting invite to plan a sprint, outline what will be covered in what order and set a time frame for the meeting. Keep in mind that priorities may change from sprint to sprint, so there may be additional items to address that should be added or removed from the agenda each meeting.

Agree on a sprint cadence

If you haven’t yet, you will need to agree on a cadence for your sprints, which will impact your sprint schedule.

The most popular length is two weeks. However, the rule in Scrum is that the sprint should be no longer than a month. The length of the sprint will depend on a few factors that you should take into account.
The most important is that the team has to be able to ship something usable in that time period. If you can’t, then your issues are too big, and you should break them down into smaller pieces. More on how to best structure Issues, tasks, and projects here.

Backlog management

As mentioned previously, the product owner typically grooms the full product backlog before the planning meeting where the sprint backlog will be created. Two types of backlogs are important for planning a sprint are:

Development backlog: Sprint-ready work, but work that is not yet accepted and planned into the upcoming sprint.
Sprint backlog: Work that has been committed to and accepted into the upcoming sprint.

To create a sprint backlog, prioritize the development backlog from top-to-bottom by importance. Everything at the top should be spec ready, have clear acceptance criteria, and be estimated. Keeping this pipeline prioritized helps teams understand the most important issues to work on next, should everything in the sprint be finished ahead of time.

Your sprint backlog should also be prioritized. This helps the entire team know the most important work that you’ve committed to accomplishing first in the sprint. This might be a high-priority bug or a back-end issue that is blocking front-end work.

Understand the team’s capacity for the next sprint

“Capacity” refers to how much work your team can take on. The capacity for each sprint may look a little different once vacation time, available resources, team changes, and other factors are considered. If you’ve already been running a few sprints, you can use data collected from those past sprints to calculate your team’s velocity – this is the average number of story points completed per sprint (if you’re using Zenhub, this data will already be generated).

With this data, you can then decide whether it will likely be an above-average sprint due to having a lot of help available, or a below-average sprint, due to having fewer resources. This will then help you determine how much work is reasonable for your team to commit to.

If you haven’t had any sprints yet but have been working with your team in GitHub, this free tool might help you get a rough idea of your team’s average working capacity.

Outline sprint objectives and negotiate expectations

A sprint goal will help define what issues should be added to the sprint. During the meeting, it is the product owner’s job to outline the objectives of the next sprint and how it aligns with current business goals, customer needs, etc. From there, the development team can go through the development backlog to determine what issues can realistically be completed during the sprint and which ones cannot. Expect some push and pull – this is normal! Just keep in mind your team’s anticipated capacity for the upcoming sprint, the estimated size of issues, and any other anticipated challenges.

Once an issue moves from the development backlog pipeline to the sprint backlog, is estimated, and has a shared team understanding — it’s ready to be assigned to your team. If you’ve done a good job organizing your backlog, team members can assign themselves; otherwise, the product owner can do it.

Sprint planning best practices

1. Don’t worry about getting it “perfect.” Many blockers and issues will come up that no one will have the foresight to see, so don’t waste time overanalyzing whether issues can be completed or not. With that in mind, it’s not a bad idea to double-check that already estimated issues are correctly estimated.
2. Refine your backlog before any planning. Backlog refinement is time-consuming, and having it already refined allows you to spend time talking about what matters. It should be said that this is usually the product owner’s job.
3. Set a time limit for sprint meetings. Going back to the point about not overanalyzing estimates, setting a time frame will keep the meeting focused and intentional. Most sprint planning sessions last between 30 minutes and 2 hours, depending on the team size. We recommend keeping it short to prevent fatigue.
4. Set clear, measurable goals. Sprint plans are great times to discuss the specifics of what is expected and what is not. Be sure all of the actionable items are clearly defined and not vague.
5. Use automated sprint plans. Reduce the amount of time spent moving issues over from your old sprint to your new sprint by automating sprint plans. Learn more about Zenhub sprint plans here.

How to automate your sprint plans in Zenhub

Earlier, under “best practices,” we mentioned using automation to speed up planning future sprints. Planning sprints in Zenhub is super easy. Simply click the “+” button on the top right-hand corner of your board and click “Sprints.” From here, you can set a regular sprint cadence to be repeated. Then, you can enable issues to be automatically moved into the next sprint when that sprint is complete and/or have Zenhub automatically build sprints from your backlog.

Conclusion

Planning sprints with your team is a great way to keep everyone on track by examining your backlog more granularly, considering what small iterations can be delivered to meet the larger goals, and checking in on team capacity. Sprint planning meetings leverage everybody’s expertise, so grab a coffee, invite the whole dev team, and prepare for (and encourage) lively discussions. You got this!