Sprint Capacity Planning: A Realistic Approach for a 10-Member Scrum Team
"Let’s commit to 70 story points this Sprint!" said our enthusiastic Product Owner during Sprint Planning. The team exchanged glances. We had struggled to complete 55 in the last Sprint, yet here we were, feeling the pressure to commit more. By the end of the Sprint, half the work spilled over, the Review felt rushed, and our Retrospective was all about why we keep overcommitting. That was the moment we realized: Sprint capacity planning isn’t just a number—it’s the difference between success and stress.
Every Scrum team faces this challenge. So how do we strike a balance between ambition and realism? Let’s break it down with a 10-member Scrum team working in a 2-week Sprint cycle.
Understanding Available Capacity
At first glance, the math seems simple. Each developer works 7.5 hours per day over 10 working days, which gives us a total of 750 hours (10 devs × 7.5 hours × 10 days). But anyone who’s worked in an Agile team knows—not every hour is spent coding.
Between meetings, discussions, and just the natural flow of teamwork, a big chunk of time is spent outside of focused development work. That’s why planning based on "total hours" is misleading.
Where Does the Time Go?
Let’s be honest—Scrum ceremonies take time, and they should. Without them, teams lose alignment and clarity. Here’s what typically happens in a 2-week Sprint:
- Sprint Planning: 4 hours
- Daily Stand-ups: 15 minutes per day, totaling 2.5 hours per developer
- Backlog Refinement: 2 hours
- Sprint Review: 2 hours
- Sprint Retrospective: 1.5 hours
That’s roughly 12 hours per developer, leaving 63 hours of real working time per person. Multiply that by 10 developers, and the effective capacity becomes 630 hours.
Accounting for Reality: The Focus Factor
We once planned a Sprint assuming we’d use 100% of our available hours for development. Guess what? Reality had other plans. There were last-minute production issues, ad-hoc design discussions, and those spontaneous "quick syncs" that never really feel quick.
This is why experienced teams apply a focus factor—a percentage that accounts for unplanned work and real-world distractions. A realistic focus factor is around 70-80%, depending on the team’s working style and environment.
For our team, applying an 80% focus factor reduces the effective capacity to 504 hours. This is a much more realistic number to plan against.
Translating Capacity into Story Points
Now, how do we convert these hours into meaningful work? A good starting point is looking at past Sprints. If the team’s historical velocity is 50 story points per Sprint, we can cross-check this against our capacity.
Let’s assume:
- 1 story point = 10 hours of effort
- With 504 available hours, the team can commit to around 50 story points
This prevents us from overcommitting while ensuring we deliver value. And if things go smoothly? We pull in more work, rather than rushing unfinished work at the last minute.
Key Takeaways for Scrum Teams
A well-planned Sprint isn’t about squeezing in as much work as possible—it’s about delivering value sustainably. Here’s what we’ve learned over time:
- Scrum is empirical – Don’t guess. Use past velocity and real data to plan.
- Meetings and collaboration are part of the work – They enable better execution, not hinder it.
- Apply a focus factor – Context switching and interruptions happen. Plan for them.
- Undercommit and overdeliver – A sustainable pace keeps teams motivated and productive.
Sprint after Sprint, teams learn and improve. The best teams aren’t the ones that commit to the highest number of story points; they’re the ones that consistently deliver what they commit to. Capacity planning helps make that possible.
How does your team approach Sprint capacity planning? Let’s share insights and experiences!
#Agile #Scrum #SprintPlanning #SustainablePace #CapacityPlanning
Comments
Post a Comment