A Scrum Master is a servant-leader and coach for an Agile team, responsible for facilitating Scrum processes, removing impediments, and guiding the team toward self-management—not a project manager, not a secretary, and not the person who “manages” the team. This article explains the real responsibilities of the role and debunks five common myths that persist even in organizations that claim to be Agile.
Formula
The calculator above estimates the total capacity of a Scrum team for one Sprint, which is a common planning tool. The formula is:
Capacity = Sprint Length (days) × Team Size (people) × Focused Hours per Person per Day (hours)
Where:
- Sprint length (t) – the number of calendar days in the Sprint (typically 10–30, with 14 being common).
- Team size (m) – the number of people on the Scrum team (developers, testers, etc., not including the Scrum Master or Product Owner unless they do hands-on work).
- Focused hours per person per day (h) – the realistic number of hours each person can spend on Sprint work, after meetings, emails, and other overhead (often 4–6 hours).
The result is a rough estimate of the team’s available person-hours for the Sprint. It does not account for holidays, time off, or complexity of tasks.
Worked Example
Using the default values from the calculator: a 14-day Sprint, a 7-person team, and 5 focused hours per person per day.
- First, multiply the Sprint length by the team size: 14 × 7 = 98 person-days.
- Then multiply by the focused hours per day: 98 × 5 = 490 person-hours.
So the team capacity is 490 person-hours. This means the team can plan to complete roughly 490 hours’ worth of work during that Sprint, assuming everyone works at a sustainable pace.
Why Capacity Planning Matters
Capacity planning helps a Scrum team avoid overcommitting. Many teams look at a Sprint backlog and guess, but a simple calculation like this gives a reality check. For example, if the team’s estimates for the selected backlog items total 600 hours, they know they are likely overcommitting and need to reduce scope. This is a basic tool—it doesn’t replace the team’s judgment, but it provides a starting point for discussion.
Common Mistakes in Capacity Planning
- Using 8 hours per day: People don’t work 8 focused hours a day. Meetings, breaks, and admin tasks eat into that. 5–6 hours is more realistic.
- Ignoring time off: If someone is on vacation for 2 days, subtract those person-days from the total.
- Including the Scrum Master and Product Owner: They are not typically doing Sprint backlog work, so they shouldn’t be counted in the team size.
- Treating the result as a promise: Capacity is an estimate, not a guarantee. It helps with planning but doesn’t account for unexpected issues.
Limits of the Formula
This formula assumes a linear relationship between time and output, which is rarely true. Task complexity, dependencies, and the team’s velocity (how much work they actually complete in a Sprint) all affect what can be delivered. The formula also doesn’t account for the fact that some tasks can’t be split—a 10-hour task takes 10 hours regardless of how many people you have. Use this as a rough guide, not a precise measurement.
How to Use the Result
Once you have the capacity in person-hours, compare it with the sum of the estimates for the items the team wants to include in the Sprint. If the total is close to or above the capacity, trim the backlog. If it’s well below, the team might be able to take on more. The goal is to commit to a realistic amount of work that the team can complete without burnout.
Frequently Asked Questions
What is a good capacity utilization percentage?
Many teams aim for 60–80% of the raw capacity. The remaining time is for meetings, code reviews, and unexpected issues. If you plan for 100%, you’ll likely fail.
Should I use this for a 2-week Sprint?
Yes, for a 14-day Sprint, the default, it works well. Just adjust the Sprint length field to match your actual Sprint duration.
What if my team works part-time?
Adjust the “focused hours per day” field to reflect the average hours per person per day. For a part-time team, that might be 3 or 4 hours.
How does this relate to velocity?
Velocity is a measure of how many story points or hours the team actually completed in past Sprints. Capacity is a forward-looking estimate. You can use both: capacity to plan, velocity to check if you’re being realistic.
Does this formula work for Kanban?
Kanban doesn’t use Sprints, but you can still use a similar calculation for a week or a month. Just set the Sprint length to the number of days in your planning period.