How to do Agile Capacity Planning in Agile Scrum

Many organizations have widely employed Agile Methodology in the past few years. As many companies may assume that Agile Methods do not plan and acts spontaneously, much planning is involved to develop and deliver the desired product. Project Planning and Project Management focus on understanding the product requirements and creating schedules and deadlines to achieve the product features. However, leaders of the organization have to understand that setting schedules and deadlines are not the only things they have to take care of while planning the Sprint or while developing the product. They have to realize that people do work and how they execute it is what matters during product development. 

If there are a set of people in an Agile team, the Agile leader has to know how much one can contribute during a particular iteration. This helps them estimate the scope of delivery in a given schedule. A common method of scheduling plan-driven projects includes defining the tasks, identifying each person’s availability, and leveling the resources, which helps formulate a customized schedule. Agile focuses on developing the schedule for the entire team rather than orienting towards individuals. Agile believes that a team is a persistent group that consists of all the skills to perform the project work. The Agile team self-organizes, identifies tasks and assigns the team members to do their work as soon as possible. Agile emphasizes how much the entire team can achieve rather than how much an individual can do. 

What is Agile Capacity Planning?

Agile capacity-based planning, also known as commitment-based sprint planning, is a method of sprint planning based on the team’s availability (in hours). This method involves calculating the team member’s capacity in hours and adding them to give a total capacity. This method aims to prevent overburdening or under-committing the team members. There are three main reasons why Agile capacity-based Sprint Planning is considered the best way. They are:

1. Agile Capacity-based Sprint Planning takes into account the team's holidays, leaves, and other commitments, so the capacity of each Sprint is different. Hence, every Sprint cannot be considered an average Sprint. 
2. Story points and velocity are two important measures in velocity-based Sprint Planning. But Story Points are coarse-grained for planning the details for a two-week Sprint. Hence, the accuracy of using them during the planning could be reduced. However, in an Agile capacity-based Sprint, the team considers hours, which are fine-grained and are much useful for estimating concrete tasks. 
3. Lastly, in capacity-based Sprint Planning, the User Stories help the Product Owner and Developers understand each story in detail, enabling them to develop a shared understanding of the end product. 

Hence, in capacity-based Sprint planning, one particular Product Backlog is chosen and all the time involved in completing the tasks involved in that Product Backlog is estimated. While planning the Agile capacity-based Sprint, it is important to know that the team’s commitment is not taken as a guarantee. You should allow some space for the team to make mistakes or not expect that all the tasks selected for the Sprint would 100% be completed. Teams can perform at their highest level 80% of the time. Therefore, teams should be assured that they have to complete 80% of the Sprint so that they do not feel constantly pressured while they are working. This way, businesses gain confidence about what in-time delivery they can expect and how they can deliver the promised products. 

How to do Agile Capacity Planning in Agile?

The Product Owner, the Scrum Master, and the Developers do a capacity-based Sprint planning. The highest-priority products features are selected from the Product Backlog and presented to the team. The basic unit to estimate the capacity of the team is the person-hour which is one hour’s work by one person. It is not directly related to the duration, for instance, if two people spend three hours doing a specific task, then the total person effort would be six hours. It does not matter whether they have done this work in one day or several increments across many days. In Agile capacity-based Sprint Planning, we assume that even though Agile teams have different types of work, their working hours are estimated equivalently to estimate the team’s total capacity. Agile projects are complex where one product requires several features which have to be iterated throughout time based on the feedback given by the users. The work of implementing and validating requirements is broken down into tasks associated with each requirement specification called the User Story. Agile Capacity Planning aims to estimate how many person-hours of work a team can perform in a given period, such as Sprint. 

How to do Agile Capacity Planning in Scrum?

We have to find out which hours in the workday each person will be working on the implementation and validation of requirements, throughout interest, and later add up those hours for all the people on the team. We have to consider these factors in this capacity based model:

1. The number of workdays in the given period. (five days per week)
2. Number of team members
3. The duration of meetings and activities is pre-planned, where no team members do any hands-on work on the project. 
4. Any planned time off for each person in the period. 
5. Fractional availability of each person for work when not attending meetings. 

Use a spreadsheet to calculate the Agile capacity in the following method:

1. Multiply the number of workdays in the given period by the number of working hours per day (usually 8 hours per day)
2. Subtract all the work hours used for whole team meetings from the total working hours. This makes the networking hours smaller than the total work hours. 
3. Collect data on each person's availability and time off. Subtract the time off from the network hours and multiply the result by his availability time to get his capacity. 
4. Add the individual capacities and get the Team’s capacity in person-hours. This total team’s capacity has to be divided by eight to get the capacity in person days. 
5. The team’s capacity hours should be divided by the work hours to get the Net team resources, which is the effective number of full-time people on the team. 

Example of calculating the Agile Capacity

Suppose a team consists of 6 members working 7 hours for a 4-week Sprint ( 20 days). This implies that the team’s capacity would be:

Team’s capacity= time in hours* Number of team members* days

= 7*6*20

= 840 hours

840 hours would be the team’s total capacity. 

Nevertheless, planning the Sprint in this method may be possible, but using all of the 840 hours is impossible. There may be many meetings in between and other events. Few team members may be on vacation or can take leave between the Sprint. This could also make the team feel burned out on tasks they could not complete. This method can also diminish the quality of the designed product as it creates a rush to complete the work within the deadline. It could also lower their morale and enthusiasm to work on the project. Then the question arises, how do we decide the total capacity of the team that the team can actually commit and complete? One effective method is to use the ‘ focus factor’ to get the real-time capacity. 

Also, Check:How to do Agile Capacity Planning Effectively

Focus Factor

Executing a project generally takes 6-6.5 hours per day as per many project managers. The focus factor is the amount of time the team members can stay focused or concentrate on a particular task without any distractions or impediments. The range of the focus factor is 0.6-0.8. You could get the real capacity of the team by multiplying the focus factor to the total team capacity. For instance, the team’s actual capacity for the above example would be 840*0.6=504 hours. Hence, the team could use this number to plan for their present Sprint. The Scrum team chooses the product backlog item that has the most priority and divides them into smaller stories and tasks. They estimate the hours taken for each task in hours so that the team can pick up stories and tasks to complete the time length of 504 hours as per this example. 

Always use a lesser focus factor, such that if the team has completed their tasks in their current Sprint, they can estimate the time remaining and add on more tasks accordingly. However, if the focus factor is high, it would lead to similar problems of burnout, increased pressure, and lower team morale. Teams can discuss the focus factor in their Sprint Retrospective meetings and can unanimously agree on the definite focus factor to achieve their Sprint goals. Focus factors above 0.8 are risky and generally make the team less productive.

In new organizations, where projects are new and the team is implementing Scrum for the first time, it is better to have a lower focus factor of 0.6 or below so that they can understand how it works and not get pressured initially. Also, if the organization is chaotic, the focus factor remains to the absolute left such as 0.5 as these types of organizations show no proper flow or working and have unplanned meetings, pre-sales emergence, not having definite working hours, and less specific on Sprint Backlog items. 

Other factors to consider while deciding the team’s total capacity

1. Team holidays: Subtract all the team holidays such as national holidays, etc. while calculating the individual capacity before adding up the team’s capacity. 
2. Calculate the individual working off days if any member has already planned to take leave on particular days.  

Conclusion
Agile team capacity could give an estimated and real-time picture of how much time the team has to work on a particular Sprint. This would help them take the items on the Product Backlog with the highest priority and work on it effectively. A proper estimation of work during Sprint Planning would give a proper picture of product features that would be delivered at the end of the Sprint. Hence, the stakeholders could visualize what they would expect at the end of the Sprint. In Agile methodologies training, teams learn to maintain realistic work schedules, preserving morale. Agile capacity planning involves using real-time data for calculations, unlike velocity-based planning, which relies on potentially risky assumptions