At its heart, agile capacity planning is similar to more traditional capacity planning methods. It aims to determine how much work can be completed with a certain amount of people in any given timeframe.
However, unlike waterfall capacity planning—which is done on a more long-term basis—agile capacity planning has to happen more frequently (preferably bi-weekly). Such is the nature of agile after all; short feedback cycles and iterative loops.
Let’s take a look at how to plan capacity for agile projects (and when).
➡️ Learn more about the differences between scrum and waterfall methodologies
Why do you need capacity planning?
Capacity planning is an essential practice you can’t skip. It may be easy to assign work without looking at utilization or availability of skills and time, but that can be disastrous for projects.
Project managers need to plan capacity before starting a project to ensure that plans can actually be delivered. Especially if the team is working on multiple projects during the same sprint periods, then resource constraints become harder to manage.
Consider the simple example of building a house. Say the owners hire a construction company expecting to complete the project within three months. The project manager doesn’t plan capacity in order to secure the business, but after it becomes apparent the house won’t finish on time, the owners will have questions.
But if the project manager did plan capacity at the beginning, they would have important knowledge about the feasible project timeline.
For example, if the project manager has a crew of ten people, they would divide all house-building activities among these ten folks and estimate how long the house would take to complete if they worked on the project full-time.
If the owners were not happy with this timeline, the project manager could try to change some variables. They could modify the new timeframe if more people were added to the project. Or, they could discuss the scope of the building with the owners and speak to suppliers to see if materials could be delivered sooner.
All of these solutions would be possible through effective capacity planning and capacity management.
What is capacity planning in Agile?
Capacity planning in Agile is the process of determining a team’s ability to take on and complete work within a specified timeframe, considering factors like team member availability, skills, and historical data to ensure realistic and achievable commitments.
When we talk about the house build scenario, we say that it resembles a more traditional, waterfall view of capacity planning—you try to estimate a project from beginning to end and determine how many people would be needed to complete it by a specific timeframe.
The agile project, on the other hand, doesn’t have a complete timeline to begin with. Instead, teams of people work in iterative (often two-week) sprint cycles, aiming to deliver the most value they can to customers in those two weeks.
What does this mean for capacity planning?
Agile capacity planning still aims to analyze how long work will take and how many people you need to do it. But, you need to take a different view of the planning process and shift towards a more frequent routine.
This adds overhead when compared to the waterfall capacity planning approach, but it has the added benefit of being more flexible and responsive to change. Rather than reviewing an end-to-end project in its entirety and trying to predict outcomes over a long time period, teams working in an agile way can react to changes with each sprint if necessary.
This flexibility is universally seen as one of key advantages of the agile methodology over waterfall.
When should you do capacity planning in an agile environment?
As each sprint is planned, the project manager or scrum master must determine a team’s capacity for the upcoming sprint, based on the sprint backlog and story points that need to be assigned.
Those running sprint teams should have a good idea of a team’s general weekly capacity, to begin with. A known baseline figure should be the starting point for sprint-by-sprint capacity planning in an agile environment.
The best time to determine this is just before sprint planning begins. If you try to determine capacity too soon, several variables could change before the sprint planning starts and throw off all timelines.
How to do capacity planning for agile teams
First, you need to establish a full working week in terms of the number of hours for an agile or scrum team.
Let’s say your sprint team has eight people who will work on user stories. Each is a full-time employee working eight hours per day (forty hours per week). Well, it’s simple then, right?
1 person working 8 hours x 5 working days = 40 hours per week per person
So, for eight people, total capacity can be calculated like this:
8 people x 40 hours per week = weekly team capacity of 320 hours = 640 hours per two-week sprint
Are we done? 😮💨
Well, no, not quite. You should never assume that team members will be 100% productive on sprint work every second of the day from 9 a.m. until 5 p.m. That’s just not realistic, because we need to consider that:
- There are daily lunch breaks for each person, which immediately reduces an eight-hour day to seven hours.
- There are activities that will take people away from sprint work on a daily and weekly basis, like meetings or training.
- Humans cannot be 100% focused on their work 100% of the time. There will be flux in how productive each person will be during the course of a day. A good rule of thumb is to factor in 80% resource utilization.
Let’s look at our capacity planning calculations with these factors built in.
1 person working 7 hours daily minus 1 hour for meetings and non-sprint based activities = 6 hours per day.
Multiply that by 80% (as mentioned above) = 4.8 hours per day.
Multiply 4.8 hours by 5 working days = 24 hours per week per person.
So, for eight people, we can now calculate the total capacity:
8 people x 24 hours per week = Weekly team capacity of 192 hours = 384 hours per two-week sprint.
As you can see, this is a big difference from the original 640 hours sprint capacity per team that we calculated.
It’s scarily common for people, especially senior leaders, to make this mistake when creating top-down capacity plans. You need to always consider the actual capacity of your team as opposed to the assumed capacity you’d have if people could work 100% of the time.
<tip>
Pro tip
If you’re using resource planning software, you can schedule your team’s time in detail making capacity planning easier and more accurate. You can easily add and approve time off, as well as set public holidays specific to each person’s location and team holidays that apply to everyone.
<tip-button>Learn more</tip-button>
</tip>
Don’t forget the time off!
Yes, time off is another big consideration. Always factor in any team member’s planned holiday days off during the sprint or national holidays.
It’s also possible that some team members may spend more than one hour a day in meetings for a specific period (e.g. strategy or tactical plans). Be sure to consider any reasons that an 80% utilization rate is not appropriate for the team or some teammates.
To someone not used to the weeds of project planning, this may all seem incredibly detailed and pedantic. But, as with all forms of planning, overlooking these details can lead to poor delivery results after it’s too late to fix anything.
Also, poor capacity planning has a direct impact on your teams! If you get capacity planning wrong and over-commit or underutilize people, deadlines may put additional pressure on your team, leading people to become demotivated and burned out.
Ready to plan capacity?
Capacity planning in agile aims to determine the amount of time each sprint team can dedicate toward completing sprint-based work. It is done on a sprint-by-sprint basis and you must consider many variables about the realities of any given sprint team’s working week and utilization rate.
Getting this right will result in more predictable outcomes for the delivery of work, but also ensure you’re looking after your team’s well-being by not committing them to unrealistic timelines.
Resource management software like Float ensures that you can always see your team’s capacity in real-time, track resource utilization, and spot any changes in workload that could derail your project.
<sme-box>
<sme-color=”pink”>
<sme-quotes>
📚 Want to learn more about capacity planning?
This was just the beginning! We have a bunch of additional resources for you 👇
- A (very) comprehensive overview of all things capacity planning
- Our top 7 picks for the best capacity planning software out there
- A how-to guide for capacity management done the right way
- An overview of the biggest capacity management challenges (and tactical advice to overcome them)
- Tools and tactics to create an actionable capacity planning report your entire team benefits from
</sme-quotes>
</sme-box>
<hr>
Some FAQs about Agile capacity planning
What are the key elements of Agile capacity planning?
Key elements include understanding team capacity, estimating the amount of work, prioritizing tasks, considering team velocity, and adjusting plans based on feedback and changes in workflow.
How do you handle changes in capacity during a sprint?
Agile development teams regularly reassess capacity during sprint planning meetings and throughout the sprint. If capacity changes due to unforeseen circumstances or changes in priorities, the team may need to adjust the sprint backlog items accordingly.
What are the common challenges in Agile capacity planning?
Common challenges include inaccurate project estimations, fluctuating team velocity, unexpected disruptions, dependencies on external factors, and balancing workload across the number of team members. Effective communication and regular sprint retrospective meetings can help address these capacity management challenges to meet sprint goals.
<cta-box><image-color="yellow">
Plan capacity easily with Float
Float manages your team’s capacity on autopilot. Get a high-level view of your team’s workload, availability, and project pipeline to plan resources with confidence.
<cta-button>Try Float for free</cta-button>
</cta-box>
