Def: Velocity is the amount of estimated product backlog that a team can fully implement to meet the team Definition of Done within a given sprint [time-box].
The amount of product backlog in the definition above is often expressed in terms of “story points” or “ideal days”. Fully Implement implies that the product increment built during the sprint is end-to-end functionality and is potentially shippable. Also, velocity measurements are made only at the end of every sprint.
Track Record
The purpose of taking velocity measurements is to capture team-system’s track record at translating product backlog items into acceptable working software. This track record is typically expressed in total number of story points (velocity). Traditionally projects have been estimated prior to the start of the project. Estimates at their best are educated guesses. Guesses – none the less, based on assumptions that need validation from reality. In traditional project management this aspect of validating assumptions, made during the start of the project, is severely lacking during project execution. Project management is then reduced to protecting the planned estimates as opposed to achieving desired goals. Iterative delivery of software every sprint and taking velocity measurements for every sprint has negated the need to make large inaccurate estimates for the entire project. Instead small inaccurate estimates are made for each sprint. And that is a good thing! velocity works with the fact that estimates are inherently inaccurate.
Velocity acts as a correction factor.
This is how: Say a team estimates (makes an educated guess) that they can fully implement 40 story points of work in a sprint. At the end of the sprint if only 20 story points are fully implemented and accepted then the team’s velocity for that sprint is 20. Velocity is informed by reality. Going forward, in the next sprint, if the team is consistent with their estimating technique then they can reasonably expect to complete about 20 points of work. Disciplined velocity measurement provides correctional ability to re-estimate amount of work that can be reasonably expected to be done in the next sprint. Thus allowing for reliable commitments for a given sprint.
Velocity and commitment.
It is important to note that velocity does not imply commitment. Most of us understand this however we behave at odds with our understanding. Too often I have observed product owners and other managers demand that a team commit to 20 points of work this sprint since their velocity previous sprint or average velocity was 20 points. Velocity is a tool to make reliable commitments, not a substitute for team judgement at making these commitments. Velocity does not imply commitment for the upcoming sprint and it definitely does not imply commitment over the next bunch of sprints.
Peering into the future:
Future can not be predicted. However one can arguably say that project release date based on velocity measurements is many times more probable to be true than the probability of releasing on a date arrived from purely educational guess work. I’m not aware of a scientific study that will prove my assertion but I’m confident that the probability of my assertion being true is greater than it being wrong 😉
Velocity directly depends on:
Reliable velocity measurement are based on consistent sprint length, same team members, similar product domain, similar product technology and consistent relative estimating. These are the direct cause and effect links with velocity. Changes to any of these factors make velocity unreliable. There are numerous other indirect factors which affect velocity. Understanding these requires understanding the relation between velocity and team.
Velocity and team:
The most common misconception is that velocity is an attribute of a team. This is understandable since changes to team members directly impacts velocity. This link of cause and effect is frequently yanked where in team members are changed thus impacting velocity thus re-enforcing our belief that velocity is an attribute of team. When in-fact velocity is an attribute of the system which includes both the team and the organizational environment surrounding the team. An example of organizational environment impacting velocity is evident through the dramatic increase in velocity observed in teams after they are collocated. There are various other organizational factors that affect velocity of a team system. Organizational culture and management’s response to team impediments are the biggest contributors to velocity improvements.
Velocity and team productivity:
Velocity is often mis-used to express team productivity. There are two common ways of mis-using velocity to express productivity
- MisUse 1. Velocity used to comparatively express productivity of one team over that of another team. This is when Team A is deemed more productive than Team B since Team A velocity in story points is greater than that of Team B.
- MisUse 2. Velocity from previous sprints is used to express relative gains in productivity. In other words if teams velocity in sprint 1 was 10 and then in sprint 4 it is 20 then it is incorrect to state that team doubled its productivity in Sprint 4. Let me share an example of a real team. This team had a consistent velocity in the range of 70-80 story points. In one of their sprints the team created an automation script that effectively made testing data inconsistencies a breeze. Stories that were initially estimated at 8 were now being estimated at 2. The level of effort involved with these stories decreased dramatically and so did their relative estimates. Their total velocity however remained at 70-80 story points. Now you will agree with me that the automation script did improve team productivity however it didnot change overall velocity. This is one example of why velocity is a bad measure of productivity. For an excellent article on productivity; see Martin Fowler’s article here.
Another example of Misuse 2:
Team has built a component which will be integrated on various screens of a web app. Let’s say the estimated size of integration work is 5 points. However, over the period of time team gains expertise for this integration and is able to finish work faster. Earlier one dev pair used to deliver 5 points and now is delivering 10 points.
However, since ability to finish the work faster should not change the size of the work, increased velocity doesn’t mean their velocity has actually doubled.
When they will pick up the new and non repetitive work, there is high possibility of they getting back to old velocity of 5 points or something close to that.
Hence, these kind of spikes in team’s velocity should be understood, analyzed and looked from wider perspective instead of looking at them in isolation.