Resource allocation is a critical process on both Agile and traditional projects. Even the best-planned projects can’t be carried out if there are not enough people to do the project activities, or if they are too busy. Agile values teams delivering working software at the end of each sprint, collaborating closely with the customer, and managing their own output. To accomplish these goals, the team needs must be able to accurately assess its own capability based on reality rather than best guesses. The sprint capacity planning sheet is a powerful tool for teams to discover their capacity and deliver more realistic assessments of their ability to execute what is needed to finish a sprint.

What is the sprint capacity planning sheet?

The sprint capacity planning sheet is a sum of the total hours the team has available to them in a given sprint. It is usually created before the sprint planning meeting and is a key input. The Scrum Master uses the total to guide the team through selecting the highest-priority tasks to finish stories. Once the team has reached capacity, they will decide whether they feel capable to take on the tasks that are in the sprint. Without the capacity planning sheet as a guide, it would be easier for teams to commit too many, or too few, resources.

Teams can use a variety of tools to create a sprint capacity planning sheet. They can use a simple spreadsheet, such as Excel, and keep it on SharePoint or stored on a network folder along with the use of sharepoint site audit software to keep shared folders and documents well organized, as well as being able to enforce SharePoint governance and permissions across separate users. They can also use a bug reporting or Web-based Agile tool, such as JIRA or VersionOne, both of which have sprint capacity planning features.

Best Practices

1. Assessing skillsets of team members.

Team members may have different types of skills, which makes it hard sometimes to balance their effort during a sprint. Generalists have diverse skillsets and can work on a variety of tasks, where specialists play a specific role and may possess knowledge and skills that no one else on the team has.

Identifying the mix of generalists and specialists on the team is important for several reasons. First, a team with too many specialists may have more sprint capacity bottlenecks due to the amount of specialized work flowing through those specific people. If a specialist has planned or unplanned absences, that work may not get done until he or she returns. Second, in a large organization or any matrix- or functional-style organization, there is a good chance that a specialist, such as a subject-matter expert, is assigned to multiple projects. If this is the case, his or her capacity is already lower than other team members due to task switching.

One possible solution is to identify an alternate for some of a specialist’s work in the event of absences. Others on the team can also take some of the specialist’s work, perhaps under the guidance of the specialist, to gain knowledge and key skills and be able to perform these tasks in future sprints. This approach promotes learning among the whole team and better prepares them to handle a variety of tasks.

2. Using a focus factor.

A focus factor is a multiplier that accounts for time consumed by other activities, such as checking e-mails, attending meetings, or fulfilling other functional duties. This multiplier applies to the ideal capacity reported by team members. Realistically, few teams, if any, can keep all of its members working on a project for 8 hours a day, 5 days a week, across the length of a sprint.

The following is an example of how to apply the focus factor. Alice estimates 20 hours per week available over a two-week sprint, resulting in 40 hours for the entire sprint. She is new to the team and to Agile, so her focus factor will be 0.6. This focus factor is appropriate because she needs more time to acclimate to the team and to Agile processes. Multiplying 40 by 0.6 gives Alice a capacity of 24 hours this sprint, or 12 hours per week, to devote to specific tasks in the sprint. As Alice develops her skills and comfort level, her focus factor will go up.

Focus factors can vary based on individual team members’ experiences. For example, if a team takes on a new developer midway through the project, it makes sense to give that team member a lower focus factor to get him or her acclimated to the team and to the process. Subject matter experts and anyone with planned absences are good candidates for a lower focus factor.

In our Sprint Capacity Planning Sheet template, which you can download at the bottom of this post, you can adjust capacity based on specific reasons for absences, such as vacations. This is one way to achieve a similar effect to a focus factor. It is important to remember to apply constraints on team members’ time to the ideal capacity in order to arrive at the more realistic capability.

Pitfalls

1. Overallocating capacity.

80 percent is a good rule of thumb for resource allocation. It is not a good idea to assign someone to a project 100 percent, especially in a matrix or functional organization. Agile teams that are overallocated will more than likely struggle to meet sprint goals.

If team members are new to Agile, they need more time to get used to it, so they should take on less capacity until they “learn the ropes.” Another way is to practice resource allocation using a tool such as a spreadsheet or Microsoft Project. Practicing resource allocation, or at least taking other steps to avoid overallocation, will help keep stakeholders satisfied and keep the team happy and able to deliver on its sprints.

2. Planning capacity based on poor estimates.

The key to strong capacity planning is having sound estimates to draw from. If the estimates are lacking, the capacity planning will be ineffective. Estimates might be poor based on several factors. First, if there are a lot of large stories or large tasks in the backlog, the team might have missed opportunities to break these down into more manageable tasks of 4-8 hours. Second, if the team consistently misses their sprint goal, they may need to re-examine their estimating processes. If the team misses more than one sprint goal in a row, a good practice might be to have them take on less capacity in the next sprint to help ensure that they can deliver. This lessened delivery would be a victory for the team, increasing their morale, and can also help give them a more realistic idea of their capacity.

Conclusion

The sprint backlog and the sprint capacity planning sheet are where the “rubber meets the road” on Agile projects. Up to this point, the work has been primarily high-level development of vision and requirements. Now, teams are choosing tasks and estimating their ability to deliver on their sprint commitments. Sound planning is necessary to make sure the Agile journey remains a smooth ride.

What are your experiences with capacity planning? Please let us know in the comments.

If you are looking for further assistance, or have a specific roadblock you need to get around, we’re happy to help. Download our Sprint Capacity Planning Sheet Template and get in touch with us about your Agile challenges.