How to Estimate Capacity for Work in Agile Teams
by Kevin Thompson, Ph.D.
Discussions about project planning and project management tend to focus mostly on understanding requirements and creating schedules. These things are important, but it is also important to understand that the work of a project is done by people. If we have a fixed set of people available for the project (often, if not always, the case), we need to understand how much work they can do, in order to understand the scope that can be delivered in a schedule, or to estimate a schedule derived from the scope.
A common approach to scheduling for plan-driven projects defines tasks and their dependencies, estimates the effort per task, assigns individuals to tasks, specifies each person’s availability, performs resource leveling, and produces a schedule for the project. This process can be laborious and require many iterations to get an adequate result.
The Agile perspective on resources is oriented towards Teams, rather than individuals. It assumes that a Team is a persistent group, which has the combination of skills required to do the project work, and which self-organizes to identify tasks, assign owners, and do the work as quickly as possible. Because of the Team orientation, resource calculations focus on determining how much work the Team can do, rather than on how much work each individual can do. As a result, the effort involved in performing this analysis is much smaller for an Agile project than for a typical plan-driven project.
The basic unit of effort is the person-hour, which represents one hour’s work by one person. This unit is not related directly to duration: Two people who spend a total of four hours each doing some kind of work (say, shoveling sand) expend eight person-hours of effort, whether they do all of this work on one day, or in increments across several days.
Our starting assumption for Agile Teams is that different types of work, involving different skills, can be treated as equivalent for the purposes of estimating the team’s total capacity to get work done in a specific period of time. This assumption is almost never literally true, but the resulting estimate often turns out to be surprisingly effective in practical terms, for reasons we will consider later.
Agile projects typically break the work of implementing and validating requirements into a set of tasks (the task breakdown) associated with each requirement specification (the User Story). Most Agile projects estimate tasks in units of person-hours, so our goal is to determine how many person hours of work a Team can perform in a particular period of time, such as a Sprint or Release. (The Scrum process uses the term Velocity for the amount of work a Team can do in a Sprint.)
Ideally, we would find out which hours in the workday each person will be working on implementation and validation of requirements, over the period of interest, and add up those hours for all people on the Team. Unfortunately, this information is not likely to be available, so we will fall back by building a resource model for the Team.
Our resource model will consider these factors:
- Number of workdays in the period (at five days per week)
- Number of Team members
- Known meetings or activities which involve the whole team, during which no one is doing the hands-on work of the project
- Planned time off for each person in the period
- Fractional availability of each person for work when not in known meetings
The approach is straightforward for anyone who knows how to use a spreadsheet.
- Multiply the number of workdays in the period by eight (hours per day) to get the total number of “Work Hours” hours in the period.
- Subtract the total time allocated for whole-team meetings. This result is the “Net Work Hours,” and is smaller than the total “Work Hours.”
- Get the availability and time off for each person. For each person, subtract time off from Net Work Hours, and multiply the result by his availability to get his individual capacity.
- Add up the individual capacities to get the Team capacity in person hours, and divide by eight to get the capacity in person-days.
- Divide the Team capacity in hours by the Work Hours to get the Net Team Resources, which is the effective number of full-time people on the Team.
For example, let’s consider a one-week period, with five working days. We’ll assume that the complete Team has several meetings, which add up to 8 hours, yielding a Net Work Hours of 32.
Next, let the team members have availability and time-off values from the table:
The hours for each person are shown, and sum to 124.16 person-hours (or 15.5 person-days) of capacity for the whole team.
An interesting byproduct of this analysis is the discovery of how severely meetings and other distractions reduce the Team’s ability to do work. The example shows results for a Team of seven people, but the effective number of full-time people is less than half the actual Team membership.
Now, what about the problem of specialization? Doesn’t the fact that some tasks require specialized skills, which only one or two people on the Team may possess, make this result meaninglessly optimistic? Strangely enough, the answer is, “No,” at least much of the time.
Task breakdowns typically consist of a mix of specialized tasks and general tasks, where general tasks can be done by more than one person. As long as the effort of the specialized tasks does not dominate over the remainder, the above approach is effective. (Of course, if the degree of specialization is great enough, more sophisticated analysis is required.)
In conclusion, the agile approach to estimating how much work can be accomplished in a particular period of time is team-oriented, rather than individual-oriented. The team-oriented analysis is effective as long as specialized work does not dominate over general work.
Try our free template for estimating capacity of Agile Scrum Teams!
Other templates you may be interested in:
Agile Starter Pack
Burn Down Chart Template
Cumulative Flow Diagram
