← All articles

Capacity Planning for a Sprint: A Beginner's Guide That Keeps It Honest

By XNM Technologies · April 24, 2021 · 3 min read
Capacity Planning for a Sprint: A Beginner's Guide That Keeps It Honest

New Scrum teams often confuse two different questions. One is 'how much have we historically delivered?' — that is velocity, a trend. The other is 'how much can we realistically take on in the Sprint that starts now?' — that is capacity, a forecast for the specific weeks ahead. Capacity planning answers the second question, and in early 2021, with people juggling remote work, school-from-home and uneven availability, getting it honest mattered more than ever.

The Scrum Guide does not prescribe a capacity formula, and that is deliberate. Sprint Planning asks the Developers to forecast what they can do, and capacity planning is simply the homework that makes that forecast credible rather than hopeful.

Start with real available time, not the calendar

The most common beginner error is planning as if everyone works every working hour on Sprint goals. They do not, and pretending otherwise builds a plan that fails in week one. Build your capacity from the bottom up.

  1. Count actual working days. For this specific Sprint, subtract holidays, planned time off, training and any known commitments outside the Sprint. Use real names and real calendars, not an average.

  2. Apply a focus factor. No one spends 100% of the day on Sprint work. Meetings, support, email and context-switching are real. A focus factor of roughly 60–80% of nominal time is a sane starting point until you have your own data.

  3. Reserve room for the unplanned. Production issues and interruptions happen. Hold back a slice of capacity rather than booking the team to the last minute, especially with the uneven availability remote work created in 2021.

  4. Forecast against that number, not velocity alone. Use past velocity as a sanity check, but let the actual capacity of these specific people in these specific weeks set the ceiling for what the team commits to in the Sprint Backlog.

Make it a team conversation, not a spreadsheet handed down

Capacity planning belongs to the Developers who do the work, not to a manager filling cells. During Sprint Planning, the team looks at the Product Goal, the highest-priority items, and its own honest availability, then decides together what it believes it can finish to the Definition of Done. A forecast the team owns is one the team will defend.

  • Watch for the silent overload of part-time members split across teams — their real capacity for your Sprint is a fraction, not a full seat.

  • Treat the Definition of Done as part of the cost; 'almost done' is not done, and it quietly inflates what you think you can fit.

  • Revisit your focus factor every few Sprints against what actually happened, so the number reflects this team rather than a textbook.

Honest capacity planning is not pessimism; it is respect for the forecast. A Sprint plan built on real available hours, a sober focus factor and a buffer for surprises gives the team a goal it can actually meet — and a meeting-it builds the trust that makes the next forecast easier.

If your teams are over-committing Sprint after Sprint and want to plan in a way that holds up, XNM's program & project delivery advisory can help you put a realistic cadence in place.