Agile Capacity Planning: What It Is and How to Do It

As the Agile methodology takes center stage across most software development companies, there is always the inevitable need to ensure that Agile actually delivers and fulfills the expectations of the customer. One key way to ensure this is through Agile Capacity Planning.

This is a key part of Agile success, without which the teams may never be able to realize the full potential of the now famous Agile approach. 

What is Capacity Planning in Agile?

Agile capacity planning is the process of forecasting and then accommodating the capacity needs of a project, specifically the amount of work, time and other resources needed to complete a sprint. This is an important part of Agile software development methodology, because you need to make sure you have enough resources in place for every stage, to meet the needs of stakeholders.

The team's velocity can change from sprint to sprint. This means that you need to constantly be reassessing your resources and making sure you have enough to hit the targets for each sprint.

There are a few key things to consider when forecasting capacity needs:

• The number of features you plan to implement
• How complex those features are
• The number of team members you have
• The amount of time required to complete each task

It's also important to note that capacity planning is an ongoing process. As your project progresses, you'll need to adjust your resources accordingly. 

When is the right time to do Agile capacity planning

The best time to conduct capacity planning is at the beginning of a sprint, just before the actual sprint planning. This will help you to accurately estimate how much work you can realistically accomplish in the coming weeks, and the resources.

If you wait until the end of an iteration to assess your team's capacity, you may find yourself struggling to meet your deadlines. So it's always a good idea to take a step back and evaluate how much work your team can realistically handle.

Note that by this time you should already have a good idea of what the final product is going to look like at the end of the sprint. This is the only way to have a good understanding of the scope of the project and what your team is capable of delivering. 

How to do Agile Capacity Planning 

The larger part of capacity planning happens around the time resource, which is the greatest of all resources that you will always need to not only plan but do it meticulously. Lost time is never recoverable, anything else can. 

Let’s make a note here that some teams, especially the highly experienced ones in Agile, prefer to determine the capacity by using the previous sprints to make an estimation. This can also work but it’s not so accurate- what if it’s your first time in Agile? 

Follow these steps:

Step 1: Determine the total sprint period

Sprint Duration is the amount of time allotted for each sprint. This should be calculated based on the total number of days available, from the start date to the end date. 

In order to calculate the duration in hours, you need to know how many hours the team will be working per day. Multiply that number by the number of days in the sprint. This will give the total number of hours in the entire sprint. 

Step 2: Determine the number of team members needed

The most important members in the context of capacity planning are the developers and testers. These are the people who will be dealing with the actual coding and testing, and so most of the capacity will be measured around this team. 

Of course the team leader (e.g. Scrum Master in Scrum) and the Product Owner plus all other stakeholders are equally crucial. But their capacity as individuals is largely driven by the pace and resource requirements of the developers. 

Step 3: Determine the percentage allocation of resources

The resources here refer to the developers/testers. So if any of these members is also playing a role in another team, then their input to one team will be 50%. If he or she is playing a role on 3 other teams, then their resource allocation to one team comes down to 25%.

Remember that capacity is calculated per team, so this kind of resource sharing breakdown will apply when you have multiple, cross-functional teams. But if you just have one team, then you’ll allocate 100% per member. 

Step 4: Determine the total working hours

This is basically the total number of hours the team will have to work from the start to the end of the sprint. If we assume a two week sprint with 5 working days of 8 hours per day, then the total number of hours is arrived at by multiplying the total number of days (10) by the number of working hours per day (8) by the total number of the developer team members (X). 

In case some members' time resource is shared, then you will use the percentage sharing to find their total hours per day, which will obviously be less than 8. So if for example you have 4 teams sharing one key developer, then  their total input per team per day will be 2 hours and not 8 hours.

It's important to set a realistic duration for your sprints, because if they're too short, you won't have enough time to accomplish all tasks, and if they're too long, you'll lose momentum.

The standard period for a sprint is usually 1-4 weeks so you certainly have some room to maneuver but not so much as to go beyond this recommended sprint limit.

Step 5: Determine inactive time

This refers to the time that has been allocated for working but some members of the team, or all members sometimes, will not be working. It includes holidays, team breaks, off days, ad hoc meetings (unplanned), agile events etc. Take this down to the individual level.  The goal here is to estimate and get rid of all the time that will not actually be spent on doing the actual work throughout the sprint.

Step 6: Determine the percentage actual working time

This is the most important resource, a central part of the capacity that we are after. It is the time that the team REALLY gets down to work, the time they concentrate on working up the features. No distraction, no meetings, no offs, no holidays, no breaks — we have taken all these out in step 5. 

Start with the total number of hours in step 2, subtract the total number of inactive hours in step 5, and use the difference to find the percentage of actual working time.

So let's say you have one team of 8 developers including testers, no shared resources since the team is just one in this example. This is how you will go about the calculations:

Sprint period = 10 days

Gross working hours per day per member = 8

Total gross working hours per day for the entire team (8x8) = 64

Total sprint hours (64x10) = 640

Less inactive hours throughout the sprint (let’s assume ≈ 100 hours)

Total number of actual working hours (640-100) = 540

Capacity = (540/640) x 100 ≈ 84%

Please use this purely as a guide, an ideal example to help you put your team’s situation in perspective. The cornerstone items are the total number of working days in a sprint and the number of working hours per day. The rest will shift depending on team size and other factors like holidays, off days, and even unforeseen circumstances which will all the same count as inactive time. 

Step 7: Consider other factors besides time

Time is not the absolute measure of capacity. There are more items that need planning, and they include:

• Infrastructural facilities including collaboration tools, hardware and software.
• Finances.
• Social support structure.
• Audit capacity.
• Meals and refreshments throughout the sprint.
• Logistics including transportation where needed.
• Team experience and skills.

Also on Agile: Team Roles and Structures

Best practices for effective Agile capacity planning

Apply these best practices to get the most out of your capacity planning: 

1. Define the scope

Before you even start planning for capacity, you need to define the scope of the project. 

Once you have a good understanding of the project's goals, then you can start figuring out what kind of resources you'll need to achieve them. And this is where capacity planning comes in.

2. Use story points to estimate capacity

You can use story points to help you estimate the amount of work that can be completed in a given time period. Story points are a unit of measure that's used to estimate the size of user stories. 

They're relative, and they help you compare one story to another. So, if you have a story that's worth three story points, you can assume that it will take three times as long to complete as a story that's worth one point. This will help you ensure that you're not overloading the team.

3. Add buffer time for unexpected events

Be realistic about what's possible. It’s impossible to plan for every contingency, because there will always be unexpected events that come up. That's where buffer time comes in handy. 

Think about it this way: if you have a one-week buffer, and an unexpected event pops up that takes an extra day to resolve, you're still going to be within your original timeframe. But if you don't have any buffer time, that unexpected event can throw your whole project off track.

4. Use historical data to estimate capacity needs

By looking at past trends, you can get a good sense of how much work your team can take on in the upcoming sprints. 

This way, you're not overcommitting or under-committing, which can seriously impact your team's productivity and morale.

5. Plan for capacity at the team and individual level

You can't just look at things at a high level and expect everything to work out. That's why it's so important to plan for capacity at the team and individual level.

You'll be able to ensure that everyone has enough work to do and that they're not overworked or underutilized. And you'll also be able to avoid the dreaded 'crunch time' where everyone is working overtime and morale is low.

6. Use multiple planning tools

You may find that using multiple planning tools is helpful when you're trying to optimize your resources. For example, you might want to use a spreadsheet to track your capacity for a certain week, and then use aKanban board to visualize your progress. 

This will help you get a clear picture of where you are in terms of capacity and how much work you can actually take on. Another great tool for capacity planning is a forecasting tool. This will help you predict future demand and make sure you're not overbooking the team.

7. Review and adjust the plan regularly

It's important to review and adjust your plan regularly, especially as your team's agile workflow changes and evolves — after all this is Agile and flexibility is one of its key strengths.  

Your capacity plan needs to reflect the reality of your current situation, not some imaginary perfect scenario. Your team's velocity is always going to fluctuate, so you need to be able to adapt as needed. The key is to always be open to change and be ready to roll with the punches.

8. Communicate the plan to all stakeholders

Make sure that everyone who needs to know about the plan and allocation of resources is looped in, from upper management to the team members who will be executing the project. This includes explaining how the plan is going to help them meet their goals.

Keep in mind that teams are more likely to buy into a plan if they understand how it's going to benefit them. So take the time to explain things in detail, and answer any questions they have. The more everyone understands about the plan, the smoother things will go when it's time to put it into action.

Also on Agile: Best Practices for Agile Implementation

Conclusion

Clearly, capacity planning is a critical phase in Agile. It’s the easiest way to ensure that Agile teams have the resources they need to be successful in meeting the demands of the project.

The planning can be as elaborate or as light, depending on the scope of each sprint. Once again the main goal is to ensure that the resources are planned out and allocated accordingly, bearing in mind that the plan can change as the project advances.