PremierAgile

Disclaimer: The below-added terms are not Scrum practices, but are widely used by Scrum teams for planning purposes.

Many companies adopting Agile Methods begin with Scrum as Scrum is one of the most simple frameworks in Agile Methodology. Scrum helps companies deliver valuable products with many other benefits such as maximizing the business value, increased ROI, faster time to market, and enhanced productivity of the Scrum team. Often, Scrum may have many terminologies which may sound similar but are different. Organizations that have started using Scrum may get confused with these terms which could affect their productivity. The Scrum Master has to train the new Scrum team members about these terms and make the difference clear between these terms. One of the most common terms which the Scrum team may get confused about is “Capacity” and “Velocity”. In this article, we understand the difference between these terms and know how they are implemented during the product development process. 

Velocity

Scrum velocity refers to the total number of story points a Scrum team could deliver within an iteration. It is the rate at which the Developers can deliver business value in a given iteration. The Scrum velocity could be measured in terms of days, story points, ideal days, or hours. The team has a given definition of done which they aim to achieve by the end of the Sprint. If the team can deliver 30 story points within a Sprint, the Scrum velocity of the team is 30. To make it simple, Scrum Velocity is an estimate of how much progress the team has achieved in the past. When a team uses past performance to plan their upcoming Sprint, they are using the Scrum Velocity of the team. 

How to Measure Scrum Velocity?

Generally, the last three iterations are used to calculate the average velocity of the team. Hence, you have to take the story points of the past three Sprints that the team has completed, and add them and divide them by three. The average of these three Sprints would give an estimate of the basic velocity of the team. When you add more Sprints, the velocity measurement becomes accurate. When you get the story estimate, you can decide how much work you could take for the upcoming Sprint which is acceptable and realistic such that the team could complete the goal. Unless there are extreme and unavoidable circumstances, the estimate calculated could act as a baseline for the team members and a proper goal could be formed during the Sprint Planning. However, if the team is performing their first iteration, where they do not have past data to calculate the velocity, they use the following ways. 

• Based on historical data
• By running a few iterations
• Deducing based on expert hypothesis and judgment

The basic rule to figure out a general Scrum Velocity for a team starting its first iteration is that they have to plan their initial velocity according to their preference. If you are taking an ideal programmer time then it also includes the time used for emails, meetings, designs, documentation, rework, collaboration, research, etc. Likewise, if you are using the actual time, you have to add enough time to buffer for standard project overhead and estimation inaccuracy. If you underestimate the velocity in your first iteration, more features will rise in the next iteration and if you overestimate, a few features will be removed in the next one. However, by the time of the second iteration, a baseline idea would be generated which could help the team members plan for the Sprint.

Benefits of Velocity based Planning

• The size of a User Story is a mix of uncertainty and effort and this method takes uncertainty into the picture while planning. 
• The detailed sizes of the stories help in adding value during the Release Planning as the assumptions and dependencies could be identified and their impact over the release flow could be estimated. 
• The team can identify any area where time is being spent and eliminate it such that the velocity of the Sprint could be increased. This is done with the joint effort of the team members and the Stakeholders. 
• It encourages the team to complete their commitment and gives them a sense of achievement. This also helps them enhance their performance and gradually increase their Scrum Velocity in the upcoming Sprints. 

Burndown Chart

Burndown chart is also known as Velocity chart is a visual representation of Sprint velocity. It helps the team members to plan accordingly as it shows the time remaining to complete the planned User Stories for each day of the Sprint. The slope of the Burndown chart can help the team to predict how much time the team will take to complete the tasks in the Sprint. When the slope is extended along the X-axis, the time could be estimated. There are three basic burn-down strategies:

• Burndown points are given according to the Sprint backlog items. These items should be similar and should be completed within one-two day. Otherwise, it would be even and the burndown line would not be clear and accurate. 
• Burndown points are given when the team completes a particular task. A strategy called Planning Poker is used to estimate the end tasks in points. This method takes more time during planning but it does not require small backlog items to get a clear Scrum velocity picture. 
• Burndown points are given based on the hours used to complete the tasks. This implies that tasks are estimated based on the ideas hours allotted during the Sprint Planning. 

How to improve Velocity?

• When the team invests their time in the quality of the code, their productivity is improved gradually. The team has to continuously focus on refactoring code, such that all traces of technical debt can be removed. Removing any code which has not been used should be done to improve Scrum Velocity. 
• Do not waste your time on unnecessary tests such as testing unused features, test overlap, and testing a code that has not changed. 
• Plan for the near future and do not plan in detail. Planning too far in advance and planning too much in detail does not yield any benefits but only wastes time which could be used to develop valuable products. 
• Do not skip the Sprint Retrospective sessions as it helps in identifying problems during the Sprints and helps the team resolve the issue. This makes the next iteration smoother and easy to achieve. 

Capacity

Capacity refers to the total number of hours the team is available and does not account for the quantity of work. In this method, the highest priority User Story is chosen by the team members and is broken down into smaller tasks. Each task is given an estimated number of hours that can be accommodated in the Scrum capacity. If any capacity is remaining, the next priority is chosen and the task is added to the Sprint. The task is chosen such that all of the Scrum Capacity is filled and there is no more capacity left. 

How to Calculate Scrum Capacity?

The Scrum Capacity should be calculated in the following steps:

• The maximum capacity of the team should be calculated in man-hours. For instance, you have ten working days in a two-week Sprint where all the members of the team are available. 
• You should now calculate the capacity loss you will have in the upcoming Sprint and then subtract it with the maximum capacity. This will give you the adjusted capacity.
• Get the ratio of adjusted capacity to the maximum capacity. 
• You have to apply this ratio to your current average velocity.

Example:

• Let us assume that there are 9 team members in the Scrum Team who work within the 2-week Sprint, 40 hours a week. The team’s maximum capacity is 9*2*40= 720 hours. 
• Suppose 1 Business Analyst is taking leave for the next two weeks and would not be available. Then the adjusted capacity would be 720 − (2 weeks * 40 hours *1 person) = 720 − 80 = 640 hours.
• The ratio is: Adjusted Capacity: Maximum Capacity which is 640/720= 0.88
• If the average velocity of the previous three Sprints was 160 points then the redefined story points for the upcoming Sprint is 160*0.88= 142 points.

Benefits of Scrum Capacity based Planning

There are three main reasons where capacity-based planning is considered. They are:

• The capacity of the team varies each time depending on the availability of the team members. It considers the leaves, holidays, and other commitments and does not consider each Sprint as the same.
• It considers the hours available by the team and does not entirely rely on the story points. Hence, better planning for releasing the product could be done and proper release date could be given.
• In Sprint Planning, using the User Stories helps the Product Owner and the Developers to take each story in detail and develop a shared understanding of the end product.

Drawbacks of Capacity Based Planning

• This method assumes that all the task estimates are accurate as it is committing the Sprint size based on the available capacity. 
• It also assumes that the tasks can be done in parallel, which is practically difficult unless each task is independent. 
• It considers every team member equal which in reality will not be the case. Each person has a varied capacity and they would complete the task based on their capability. 
• Do not make use of the User Story sizing which makes the task of sizing the User Story irrelevant to the team.

Which one should you go for?

Choosing a metric between these should not be a light decision as it can heavily impact the work process of the Scrum team. Metrics help in shaping the workflow of the team and allow them to view their success and failure. It also shows what your team will be thinking about while the development process. Do not get your team attached to the numbers and metrics as your team will resist those estimates and their morale will drop. Low morale leads to unhappier and unproductive teams. You should use Scrum capacity or velocity by keeping in the benefits and drawbacks of either of the planning methods. If the benefits overweigh the drawbacks, then it is the planning method that is suitable for your team. You should use these metrics to predict the future and should use them to criticize what happened in the past. Whichever metrics you use, the main aim should be on:

• Focusing on delivering value and not completing arbitrary goals.
• Focusing on making progress and not just checking off items on the list. 
• Focusing on incremental improvements will lead to the bigger picture and just creating a feature factory and measuring the results. 

You should never bind time or performance in Scrum capacity or velocity as they are only metrics that are used for planning the upcoming Sprint. They are designed to make realistic estimates such that appropriate tasks could be chosen and completed. However, if you tie these metrics to absolute hours such as giving a developer-specific hour and not more, you cannot expect the Developer to give the best shot in their work. And in the worst scenario, if you are not satisfied with the Developers for not living up to your expectations and planning, then you encourage them to make conservative adjustments to their abilities.

Conclusion

Velocity and Capacity are metrics that help the Developers to estimate the tasks that could be completed in a particular Sprint. It should not be used as a metric to estimate the performance of the team members as it would lower their morale and also create unnecessary pressure during the development process. Both the metrics have their benefits and drawbacks. If you believe that these benefits would make a difference in your Scrum team and the drawbacks do not affect your team, then it may be the correct metric for you. Nevertheless, you have to keep in mind to not create an unnecessary environment of stress by strictly following the metrics among the team members. Your team members would not be happy and could not perform according to their full potential.