You’ve done your initial research and scoping. How do you develop a capacity plan for your agile project?
Agile frameworks are great because of their flexibility, reducing the need for upfront planning. But we live in the real world and still need to align our scope with the team’s capacity.
In this article, we’ll walk you through the practical steps to capacity planning in a Scrum-driven environment. We’ve also included tips and insights from agile project managers that you may find useful.
Where we’re starting from
By now, the key groundwork should be done:
- We have a clear understanding of the project goal
- The project has been thoroughly researched and the scope has been defined.
- We know who’s going to contribute
- User stories have been documented and estimated
These need to be completed before we can start capacity planning.
Step 1: Convert Estimates into Hours
One of the challenges in agile teams—whether you’re working with Scrum or another flavor of it—is that you’re planning against capacity. To align your scope with team involvement, you need to convert your estimations into a common unit, typically hours.
Agile estimation methods, like story points or t-shirt sizes, are useful for measuring effort or complexity, but they don’t directly translate to time. To create a practical plan, you have to make this conversion.
What you do is simply:
- Take the user stories or tasks with their existing estimates (story points, t-shirt sizes, etc.).
- Convert those units into hours.
For example, if a user story is estimated as 3 story points or a “Medium” t-shirt size, you assign it a defined number of hours based on your team’s experience. This conversion gives you the hours you need to estimate time, plan capacity, and allocate your team members’ involvement.
It’s a good idea to factor in past performance and adjust your estimates based on actual results. For example, if tasks are taking longer than planned and the project starts to fall off track, revising your estimates based on actuals can help you stay on course.
This means reviewing your initial estimates, checking them against actual time spent, and adjusting your conversion baseline. It’s an ongoing process to keep your plans as accurate as possible.
Another interesting thing we’ve noticed:
The accuracy of estimates depends on the role.
In our experience, technical people tend to be better at estimating their tasks. Non-technical people, however, often need more guidance. You need to check in with them more frequently to ensure their estimates are accurate and make adjustments when needed.
Step 2: Distribute Work Based on Team Capacity
Once you’ve converted the units into hours, the next step is to look at each person’s available time and distribute the work accordingly over the two weeks. Take into account the following factors:
- Their role
- Planned time off
- Type of tasks handled
- Time lost from switching between tasks
How does a team member’s role impact their available time? For managers, their responsibilities take up a significant portion of their day. These include tasks like meetings, team oversight, and strategic planning. Because of this, they have less time available for project work. Typically, you allocate a smaller percentage of their hours—around 60%, for example.
For non-managers, we estimate that about 80% of their time can be allocated to project tasks. This leaves some flexibility for other responsibilities. For a 40-hour workweek, this would mean 32 hours dedicated to project work. Breaking it down this way helps ensure the workload is realistic and balanced for each team member.
When considering available time, make sure to subtract any planned time off for those two weeks, like vacations, personal days, or even recurring commitments like team-wide meetings. This information is usually available in a central team calendar or the system where time-off requests are tracked.
For example, if someone has a full day off during the sprint, their availability immediately drops by 8 hours, which might mean redistributing part of their workload to another team member or adjusting deadlines for their tasks.
For longer-term planning, it’s helpful to account for time off by using a general rate.
For example, you might assume that 20% of the total working days in a year will be unavailable due to a combination of holidays, vacation, sick leave, and other personal or company-specific time off. If there are 250 working days in a year, this means approximately 50 days would be allocated for these reasons, leaving about 200 days available for project work.
In the U.S., this might include federal holidays (around 10 days), vacation days (commonly 10–15 days), sick leave, and occasional personal days. On a monthly basis, this translates to around 16-17 available workdays out of 21 on average. For other countries, the numbers will be different.
Another point to factor in in your planning is context switching. If someone is splitting their time between different types of tasks—like coding and QA, or performing design work and design QA —it’s not as simple as jumping into the next thing.
Shifting focus takes time, if you don’t have a dedicated QA resource and your developer or designer has to handle testing too.
In these cases, going back and forth between coding and testing does add up. It’s easy to assume people can just move from one task to another without losing time, but the reality is that switching mindsets takes effort.
When you’re figuring out capacity, make sure to leave some room for these transitions so you’re not unintentionally overloading your team.
It’ll make your plan more realistic and help avoid unnecessary stress. Based on our observations, teams will already start moving slower when operating at a 50% utilization rate. That’s exactly because of time lost from switching between tasks.
Step 3: Check Capacity with Stakeholders
Once you’ve calculated the team’s capacity, make sure to run those numbers by your manager and other area leads who manage the relevant areas.
Weekly project meetings are the right place to discuss capacity.
The thing is, capacity planning always involves grey areas—things you might not be tracking or context you may not know.
In the meeting, you present what you’ve calculated for capacity, breaking it down for each team member. Explain how you’ve accounted for things like time off or role-based availability and highlight any assumptions you’ve made.
This is when managers step in to validate or correct the numbers. They’ll often say things like, “That looks about right,” or, “Keep in mind that this person will also be working on something else next week.”
This feedback is critical because it gives you the context you need to refine the plan. Whether it’s adjusting someone’s workload or redistributing tasks, these conversations ensure your resource plan is as realistic as possible.
And then, at the end of the week, do a pool of all the tasks you have under status. Start estimating how many tickets or tasks are still open, how many have closed, and which ones are in work. This helps you understand if you’re hitting your capacity max as a group. Make adjustments if needed.
Step 4: Perform a mid-sprint review
Make sure to review progress at the end of the first week of a two-week sprint.
This provides an early inspection point to check if your capacities are accurate and to assess whether the team is approaching its capacity limit.
This is not based on a calculation, but more on observations. Also, priorities usually change multiple times a week, so a weekly inspection point is necessary.
Read this interesting discussion on the benefits of doing mid sprint reviews.
Summary
Capacity planning ensures your sprint scope matches your team’s actual capacity. Begin by converting story points into hours to better distribute work and align tasks with your team’s availability. Be sure to factor in roles, time off, and the effects of switching between tasks.
Distribute work based on each person’s role and availability. Consider factors like time off and context switching, which can impact productivity. Check in with stakeholders regularly to validate your plan and fill in any gaps.
Good capacity planning takes practice, but with each sprint, you’ll get better at balancing workloads and staying on track.
Other helpful resources
If you are new to agile methods, check out these resources:
- What Is Story Point Estimation: This article from the ScrumAlliance explains in clear language what story points are and what factors should be taken into account for story point estimation.
- Planning Poker: Planning Poker is a popular estimation technique used by agile teams. The idea is to get not just one estimate from the developer, but have the group estimate each story or task, and find a concensus that is closer to reality.
