What is Velocity?
Velocity in Agile and Scrum is a measure of how much work can be done per sprint. As we discussed in the companion blog on Estimation, when we are working on estimating the size of user stories we are approximating d, the distance a user story requires us to travel. Velocity is literally the 'v'. How many user stories or story points can we complete in a given sprint. With 'd' and 'v' we can estimate the Time 't' required to complete the given work.
Velocity is a finite resource, kind of like money, or an allowance. Every sprint you are given a fixed allotment of capacity that can be completed in that sprint. Use it wisely. You can’t magically create more. Sometimes we can borrow a little bit from a future sprint and do a big push, but this is not sustainable and will eventually lead to bankruptcy/burnout! If we borrow from future sprints we will need to pull back in a future sprint to recover.
Planning with a Known Velocity
When a team has been together and consistent for a few sprints we can start working out a velocity range that the team is consistently capable of delivering. It might be something like: “this team usually delivers between 20-25 story points per sprint.” That range is important, because it helps us be accurate without trying to be overly precise. Our velocity will only be as accurate as our estimates, and that is okay. If we estimate correctly, it will be good enough.
With a velocity range that is good enough we can put together realistic sprint loads on our development teams that will allow them to be consistent and protect them from burnout. When done right, the velocity should allow the team to set goals for itself that will help them to consistently push to be productive without stretching in a way that is not sustainable.
Velocity should never be used as a comparative metric across teams, or as a metric that management uses to push teams to do more. The most important part of velocity is that it helps us be more consistent. If a team thinks they can increase their velocity by working smarter or making process improvements, then that is fine as long as this push originates within the team. Velocities do not compare across teams, and they should not be used in this way. Different teams will estimate differently, what’s important is that they are consistent.
One of the biggest benefits we can get out of proper Agile estimation (see companion blog) will be more accurate planning and forecasting. With a well-established velocity range, we can start to understand how much can be done in every sprint and then out into releases, quarterly, and even annually!
Long Term Planning with Velocity
With a historical average velocity range, we can extrapolate out a range of work that can be done for larger blocks of time. I worked as the ScrumMaster for a team that had a velocity which was usually around 50 points per sprint. We were planning the quarterly release for that team, with about six full two-week sprints in the quarter. This gave us around 300 story points of work that could be done. We had groomed the backlog and were then able to choose the most important 300 points of work to complete in that quarter. The first time we used this to aid our quarterly planning sessions we saw a huge increase in productivity of the meeting. Rather than just being a wish list where the team overcommits to what they can do, it was one of the first such meetings where everyone felt confident that everything could be completed in the given quarter. With proper estimation and velocity calculation we were able to use real historical data to project our capacity into the future.
A few other Tips
When calculating velocity, remember that something half done, is not done at all. Half built cars cannot be sold. We only count stories that are 100% done towards our velocity each sprint.
Velocity is not a bludgeoning device for management to use on the team. When management does this, the tendency can be to superficially boost estimation and velocity reporting to meet that quota. Quality can suffer as team members pass off things as done that maybe need a little more attention.
Individual contributions to velocity should not be tracked. The smallest unit we worry about in Agile is the Team. However, during sprint planning, the team can and should adjust planned velocity if there are missing team members out on PTO or other leave.
Team velocity will most likely increase as teams eliminate roadblocks, learn to work and communicate better, and inspect and adapt on their process. However, don’t expect constant linear improvement, you will likely see periods of rapid growth followed by periods of “norming and performing” as the team settles in. See the Tuckman Model - “Forming, Storming, Norming, Performing”
The Takeaway
Velocity measures how much work we can complete in a given sprint, usually two weeks.
Velocity is primarily used to encourage consistency and prevent burnout on the team.
It is usually best to calculate velocity as part of a range.
Proper accurate estimation is an important part of an accurate velocity.
Sprint Velocity can be extrapolated to longer time frames for release/quarterly planning. Be sure to focus on being accurate and not overly precise.
See the companion blog on Agile Estimation to increase the accuracy of your Velocity!