What the heck is Velocity and how do I use it?
Super High Level:
- Velocity is a backward looking metric informed by historical performance.
- Velocity can help with predicting, once the team’s average velocity is discovered.
- Velocity fluctuates over time, often times by increasing as the team hits their stride.
- To begin a project we start with a high level estimate of a timeline, and start tracking velocity to see how well we estimated and get a gauge of what the team can do in the future.
High level –
Story points are an estimation of effort and complexity relative to the size of other stories. They don’t represent the amount of time it will take for an item to complete, but often times there can be a correlation. This article explains it well https://medium.com/expedia-group-tech/demystifying-story-points-d642f9879952
Velocity is the amount of story points a team is likely to accomplish based on historical data of the team’s past performance. Velocity fluctuates based on known and unknown factors, but can be used to help give an idea of future performance. This article lays this out nicely Scrum smells, pt. 7: Wishful plans | by mobile.IT | Medium
The Challenge -
Telling a team how many points we expect out of them per sprint causes two main issues. First, we don’t actually know what the team is capable of, thus either burning the team out or slowing the team down. The second main issue is that when we focus more on delivering points and hitting dates, we lose sight of delivering value. This is a (somewhat) controversial stance by one of the signatories of the Agile Manifesto, but it has some great points* Story Points Revisited (ronjeffries.com)
A solution –
We start with a high level estimate to help with predicting delivery dates and getting the project started. This is where T-Shirt sizes and scope negotiations come into play. At the beginning of the project the development team (or team leads) can provide a high level estimate of how long they believe the effort could take, given that the requirements are fairly well defined, as well as the size of the team and external factors are considered. This will give us a an idea of when we could potentially release.
The next step is to give the team the tickets and have them refine and build. We’ll track and update their velocity and be able to gauge how much they can do given the circumstances. We can use this as a semi-reliable indicator of what the team could do going forward.
Conclusion –
Once we get the ball rolling, we can move towards a more accurate understanding of what can be done and how long it may take. This only happens once the team begins, and can fluctuate slightly over time. More often than not a team increases velocity as they gain familiarity of the product and as requirements become more clear. This is one advantage of the empirical approach to improvement. There will be a time, however, when the team finds their sweet spot for a period, but that may not last as new members or new projects make their way into the fold. There are also times when velocity decreases and this may be due to many differing factors, and we work as a team to identify the cause and strive improve on that if it’s within our control.
Further reading (if you’re into that sort of thing):
The Anxiety of Agile Development | LinkedIn**
Have We Taken Agile Too Far? (hbr.org)**
Predicting Velocity When Teams Change Frequently (mountaingoatsoftware.com)
Initial sprint velocity problem. When starting a new project potentially… | by Dejan Radic | Medium
Why Agile Goes Awry — and How to Fix It (hbr.org)
*Pun fully intended :p
** These are great
