Sprint Capacity
In the context of Scrum and Agile methodologies, “sprint capacity” refers to the amount of work a team believes it can complete during a sprint, which is typically a fixed period (often two to four weeks). It’s an essential concept in sprint planning, helping teams to make realistic commitments and avoid overextending themselves.
Sprint capacity is usually measured in the same units that the team uses to estimate work, such as story points, ideal days, or hours. The capacity is determined based on several factors:
- Team Availability: Not every team member is available full-time. Vacations, holidays, training, and other commitments can reduce a team member’s available time.
- Historical Velocity: This is the average amount of work the team has completed in previous sprints. If a team has consistently completed an average of 40 story points per sprint, that figure might be used as a baseline for future sprint capacity.
- Known Changes or Variabilities: If the team is aware of upcoming disruptions, like system downtimes, company-wide meetings, or other events that might impact their productivity, they can adjust their capacity accordingly.
- Other Commitments: Sometimes, team members might be partially allocated to other non-project-related activities. This needs to be factored into capacity planning.
Example of Sprint Capacity
Let’s illustrate the concept of sprint capacity with a more narrative-driven example.
Scenario:
Suppose you’re part of a software development team named “AlphaSquad” that follows the Scrum framework. Your team operates in two-week sprints. As the next sprint planning meeting approaches, the team needs to determine its capacity for the upcoming sprint to decide how many and which user stories to commit to.
Step 1: Determine total available hours
The AlphaSquad team consists of:
- 2 Developers
- 1 Tester
- 1 UI/UX Designer
- 1 Scrum Master (who also contributes to development)
Everyone works 8 hours a day. So, for a two-week sprint (10 workdays):
Total available hours = 5 members × 10 days × 8 hours/day = 400 hours
Step 2: Adjust for non-available hours
- One of the developers will be attending a two-day workshop, so she won’t be available for 16 hours.
- The entire team is expected to attend a half-day team-building activity, so that’s 4 hours each, totaling 20 hours for the entire team.
- On average, each member spends around 1 hour a day on meetings, emails, and other non-development activities. Over 10 days, that amounts to 10 hours per person or 50 hours for the whole team.
Total non-available hours = 16 + 20 + 50 = 86 hours
Step 3: Calculate Sprint Capacity
Sprint Capacity = Total available hours – Non-available hours
= 400 − 86 = 314 hours
Step 4: Sprint Planning
With the calculated sprint capacity, AlphaSquad can now look at their product backlog and start selecting user stories. They estimate the work in hours. For example:
- Feature A: 100 hours
- Feature B: 60 hours
- Bugfix C: 30 hours
- UI Enhancement D: 80 hours
- Testing and documentation: 40 hours
Total estimated work = 310 hours
Given the sprint capacity of 314 hours and the total estimated work of 310 hours, the team feels confident committing to these items for the upcoming sprint. If they finish early, they can always pull in additional items from the backlog.
This example provides a tangible walkthrough of how a team might approach determining their sprint capacity and using it to guide their commitments in a sprint planning session.
