Capacity Planning for a Sprint: A Practical How-To Guide

Sprint capacity planning is the process of determining how much work a Scrum team can realistically commit to in a Sprint, given the team members who will be available and the work that needs to be done. It is one of the inputs to Sprint Planning, alongside the Product Backlog and the team's velocity. A team that does not plan capacity will either over-commit (taking on more work than it can complete) or under-commit (leaving capacity unused). Both are problems that good capacity planning can prevent.

Here is a practical guide to Sprint capacity planning.

Step 1: Identify Who Is Available

The first input to capacity planning is team availability. For each team member, determine how many days they will be available for Sprint work during the upcoming Sprint. Account for: planned leave and public holidays, non-Sprint activities (supporting production issues, attending organisation-level meetings, training), and any part-time allocation to the team.

Step 2: Calculate Available Hours or Points

1. Convert available days to available hours. If a team member will be available for 8 of the 10 working days in a two-week Sprint, they have 8 days of capacity. If the team uses an 8-hour working day for planning purposes, this is 64 hours of capacity for that team member.

2. Apply a focus factor. Not all available hours are Sprint work hours. Administrative tasks, code reviews, answering questions, and other non-Sprint activities consume some capacity even for team members who are formally 'available.' A focus factor of 70 to 80 percent is a reasonable starting point for most teams: 64 available hours x 0.75 = 48 productive Sprint hours for that team member.

3. Sum across the team. Add up the productive Sprint hours (or story points, if the team estimates in points) for all team members to get the total Sprint capacity.

Step 3: Use Capacity to Bound Sprint Planning

• Compare the selected Sprint Backlog items against Sprint capacity. If the estimated effort for selected items exceeds Sprint capacity, remove items from the Sprint Backlog until the plan is within capacity.

• Use historical velocity as a sanity check, not as a substitute. If the team's average velocity over the last five Sprints is 40 story points, and this Sprint's capacity calculation produces a capacity equivalent to 55 story points, something is off in the calculation -- the capacity estimate should be investigated before committing to 55 points.

• Review capacity at the Sprint midpoint. A team that is well ahead of plan at the Sprint midpoint may have underestimated capacity; a team that is significantly behind may have overestimated. The midpoint check is an opportunity to adjust the plan within the Sprint rather than waiting for the Retrospective.

XNM supports public-sector organisations in building effective Scrum team practices, including Sprint planning and capacity management. Reach out to XNM's program & project delivery advisory team to discuss Sprint capacity planning and agile delivery for your team.