Capacity and Velocity! Neither term is called out in the Manifesto of Agile Software Development, and only capacity is mentioned twice in the Scrum Guide. Velocity, a science term, is fairly new to the world of managing products, projects and services. However, Capacity is very familiar to this world. Most project managers use it to determine how much a team can produce in a normal work period; and oftentimes that estimate of work to produce is dictated by that manager. So how should these two terms be used in Scrum? Rather than take a dogmatic approach, I suggest we examine their origins and how one could utilize them with a Scrum Team.
More than often, these two terms are abused by people “doing” Agile. Some believe that teams with a high Velocity are better than other teams. They press these groups of people to increase their Velocity and develop metrics to compare other indices. Then, there are those that correlate Capacity to using some calculation to determine how many Story Points each team member should complete per hour. These are serious anti-patterns that distract teams from attaining the mindset of Agile; but that’s a different discussion for a different day.
Capacity: The Amount of Work a Team Forecasts for a Sprint
To figure out how we should consider the usage of Capacity, let’s start with its usage in the Scrum Guide. The first occurrence of the word Capacity references a projected value used to assist during Topic One of Sprint Planning; “forecasting the functionality that will be developed…”. This seems to be the exact usage when project managers perform Capacity Planning in Waterfall. The second sighting of the word specifies how much time, of the Development Team, should be utilized for refinement. The two usage reflects different values: time and effort, using Story Points. Examining the first usage of the term, we can conclude that they were not referencing time, as it is something that the Development Team cannot produce. Similar to how it is used in Waterfall, we will describe Capacity as the amount of Story Points that they forecast can be completed during a work period.
This forecast is just a gut-feeling estimation. The team might use some historic information as a deciding factor, such as the previous Sprint Velocities. Capacity should include the estimation of any work, whether defects or business value, in addition to the availability of each team member.
Velocity: Speed with Direction
Unlike Capacity, Velocity is about actual values and not estimated. In addition, not all effort travels in the same direction.Velocity is a term that is often associated with Scrum, but never mentioned once in the Scrum Guide; interesting, yet not uncommon. Often what people deem as “best practices” become deeply associated with the foundation of principles, values and rules. If enough people take on that action, it is quite difficult to separate the myth from the truth. So, what do people mean when they speak about Velocity? When reference in Scrum, it is the actual amount of Story Points completed over a period.
Over the course of my career, I have been adamant about counting only completed Story Points that reflect business value. I felt that Story Points for defects did not really showcase how the team was progressing. Why should the team get bonus points, in their Velocity, for re-working something that should have been done in the first place? Yet, when my colleagues challenge me about whether that reflects the Capacity of the team, I respond that Capacity is not synonymous with Velocity.
Before Velocity became associated with Scrum, it was purely associated with Physics to provide guidance about the combination of magnitude and direction. In fact, to say that your Velocity is 25mph is incorrect, because there is no direction; it should be 25mph North. Without direction, you only have speed. Let us align this back to Scrum. The development of a product or service will have many vectors. Delivering business value moves us closer in the direction of putting expected value in the hands of our customers. Identifying defects is the realization that we are off course in delivering our solution. Correcting those defects is like rotating our sails to steer the ship back on course. It is a costly experience to have a high Velocity heading in the wrong direction.
As organizations transition from the old ways of managing people to building teams and empowering them to perform critical thinking, the usage of Capacity and Velocity will have to be monitored so that it is not abused in terminology or as a key performance index. These two values are communication devices. They should be used to help the Scrum Team understand how much effort can be forecasted in the short term and how to perform planning for the long term.