Velocity (software development)
 | This article needs additional citations for verification. (May 2018) |
| Part of a series on |
| Software development |
|---|
Velocity is a metric for work done, which is often used in agile software development.[1]
Measuring velocity is sometimes called velocity tracking.[citation needed] The velocity metric is used for planning sprints and measuring team performance. There is no scientific evidence that measuring velocity improves planning effectiveness or team performance. Furthermore, the metric can be misleading.[according to whom?]
Terminology
The following terminology is used in velocity tracking.
- Unit of work
- The unit chosen by the team to measure velocity. This can either be a real unit like engineer-hours, engineer-days or Product Backlog Items (PBI) , or story points.[2] Each task in the software development process should then be valued in terms of the chosen unit.
- Interval
- The interval is the duration of each iteration in the software development process for which the velocity is measured. The length of an interval is determined by the team. Most often, the interval is a week, but it can be as long as a month.
Calculation
Velocity always involves counting the number of units of work completed in a certain interval. In common practice Velocity measure the amount of story points that our Team is able to burn in one iteration (Sprint). But a Story Point is a subjective measure for effort, which in turn is not just complexity, but the sum of the following terms: volume, risk, uncertainty, and complexity of the work. For example, suppose we use the Fibonacci Series to define the available story points for a product backlog item. Let's assume that the Team's velocity in the past Sprint was 20 points. In particular, in the last Sprint the Team burned the following: 2+2+5+8+3 = 20 points
Today they've joined the Sprint Planning, and they're about to estimate the User Stories for the next Sprint. They want to include a User Story similar to the one they've delivered in the past Sprint, as 5 points. However, as they have improved their experience, now they can estimate that Story as 2 points, instead of 5.
So assuming everything stay the same, now they have: 2+2+2+8+3 = 17 points Assuming there are no User Stories available smaller or equal to 3 points to chose from, and assuming the Team is not comfortable to take more work, all going well, the velocity of this Team in the next Sprint will be 17 points.
If we compare the previous velocity (20) with the projected one (17), we may think that the Team's productivity is going down, whereas in reality it should go up. This example shows that the velocity cannot be used as a measure of productivity. [3]
Principle
The main idea behind velocity is to help teams estimate how much work they can complete in a given time period based on how quickly similar work was previously completed.[4] Velocity is relative measure. In other words, the raw numbers mean little; it is the trend that matters.[5]
Criticism
One problem with velocity is that it conflates work done with planning accuracy. In other words, a team can inflate velocity by estimating tasks more conservatively. If a team says that a task will take four hours or is worth 4 points instead of taking two hours or being worth two points, their velocity will look better (sometimes called point inflation).[6] Velocity should not be used as a performance metric.[1]
A second problem with velocity is that it does not take quality, alignment with user goals or priority into account. Velocity can be increased by neglecting good design, refactoring, coding standards and technical debt. Simply completing features as quickly as possible increases velocity regardless of quality. Similarly, velocity includes work done regardless of the benefits of that work. For example, building a feature no one wants or needs still counts as "work done” and completing a work unit which moves away from a user goal such as ease of use is movement in the opposite of the direction desired. This makes “velocity” in Agile more like the concept of directionless “speed” from physics.[citation needed]
A third problem with velocity is that it is often misused as a measure of efficiency or team performance. Velocity is a metric of work done, not efficiency. Velocity can be increased by working overtime or adding team members, neither of which necessarily increase efficiency or performance.[citation needed]
In summary, velocity is a problematic metric because it is easy to manipulate and often misused as an indicator of efficiency.[citation needed]
References
- ^ a b Rubin, Kenneth (2013), Essential Scrum. A Practical Guide to the Most Popular Agile Process, Addison-Wesley, ISBN 978-0-13-704329-3
- ^ Measures of size, agilesoftwaredevelopment.com, archived from the original on 2010-10-26, retrieved 2010-09-24
- ^ https://www.mountaingoatsoftware.com/blog/its-effort-not-complexity
- ^ Glossary of scrum terms: Velocity, archived from the original on 2010-11-29, retrieved 2010-09-24
- ^ Agile 101: Agile Software Development Velocity, VersionOne.com, archived from the original on 2010-10-02, retrieved 2010-09-23
- ^ "point inflation". innolution.com. Retrieved 2019-06-06.