Editor’s note: This article is an excerpt from our newly revamped eBook: Project Management for Teams in GitHub. For the full guide to building a high-performing, agile software team, pick up your free copy!
You’ve set up the perfect task board, customized your labels, refined your backlog, and conquered time estimations. Go you!
But important questions must be answered before you start sprinting. How much work can you actually tackle? What issues should you choose?
Accept that, especially if this is your first foray into an Agile-ish process, you won’t have all the answers. Time, budget, and quality are fixed, and now it’s time to predict the scope of work your team can accomplish. The only way to answer these questions is to talk to your team.
With this in mind, here’s how we approach a sprint.
What should be included in a sprint?
To figure out what issues should be added to a sprint, you need to have a healthy product backlog.
“Having a prioritized list of your high-level requirements or your product backlog is a key input going into the first Agile sprint,” says Agile consultant Yvette Francino.
In other words, your issues should have:
- Estimates that you and your team decide on together
- A user story that addresses the who and why of a task. Don’t worry about adding much detail yet – you’ll discover more when you start your sprint
- Priority according to the issue’s value to the user
Once an issue is attached to a sprint, 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.
To assign issues quickly, you can select several at once by holding Shift and clicking on the issues you’d like to select. In addition to assigning, you can select multiple issues to apply batch changes like adding them to an Epic, applying a label, or moving them into a new pipeline.
So how do you decide what issues belong in your sprint?
How much work should go into each sprint?
A “sprint goal” is the amount of work your team agrees can be completed within a sprint. The goal should be a collective effort; everyone should have a say.
As we discussed in the previous chapter, the unpredictable nature of time estimates is the reason why we prefer to use story points instead. Using story points, we are able to estimate relatively. Since your tasks aren't tied to real hours, you're able to reduce complexity and account for sick days or vacations.
There's no perfect answer for the amount of work to include in your first sprint. You're almost definitely going to get it wrong the first time. If the number of story points in your first sprint feels about right, then stop worrying and start sprinting. After a couple weeks, you'll have enough historical information (like Velocity Charts) to inform your next sprint. Don't stress about it!
However, if your team is standing firm on time estimates, you can use some simple math to put together your first sprint. First, add your estimated issues up until they fill your sprint’s time allocation. For example – in an ideal world, each team member is capable of completing 70 hours of work during a two-week sprint. With five team members, that adds up to around 350 hours of work.
Because you don’t know what your average sprint velocity is, it’s easy to overcommit in the early stages. (Don't worry too much if that happens. If necessary, you can always adjust scope).
To accommodate for variables like inaccurate estimates, unexpected requirements, and real-world realities, one-third of the sprint time is left unassigned. For a five-person team, this means you'd assign roughly 230 hours per sprint – not the 350 hours quoted in the “ideal world” scenario.
Remember: your primary goal during a sprint is to make sure each assigned issue is fully delivered.
Download our free eBook to continue on and learn about your first sprint planning meeting, sprint velocity, and more!
