Team Velocity, Estimate Dates, Agile Scrum
Team Velocity in agile is an important part of release planning and measuring and improving team performance. In this post I explain Velocity in Agile Scrum and how to use it.
Photo by Maico Amorim on Unsplash
What is Agile Velocity?
Agile Velocity is a numerical measurement of how fast a Scrum team is delivering. It is a measure of how much work is being completed in a Sprint. Each work item, usually expressed as a User Story, is assigned a number estimate known as its points estimate. The sum of the points for each completed story (meeting the Definition of Done) is the Sprint Velocity. The Team velocity is an overall average of the past completed Sprint Velocities.
Scrum handles project planning quite differently from traditional waterfall projects. Agile project scope is defined in a backlog of User Stories, or incremental deliverables with business value. These stories are new features, or changes to existing features in a product. Each of these User Stories is assigned a size estimate using a process like Planning Poker. This size estimate is a number decided on the team that represents the complexity of a User Story. In Sprint Planning a sprint backlog is determined, worked on during the sprint and delivered by the end of the sprint to a completeness standard known as the Definition of Done.
Calculate the Sprint Velocity by summing the poker point estimates of all the stories that are delivered in the sprint that meet the definition of done. The following is an example of the stories completed in a Sprint.
|Sprint Backlog||Poker Points|
In this example, there was an 8 point, 3 point and 1 point story completed in the sprint. Remember that points are not an effort or duration, they are a complexity rating. For example, a 3 is about 3 times more complex than a 1. The Sprint Velocity in this example is 12 (8+3+1). Strictly speaking, there are no part marks. If a story hasn’t completely achieved the Definition of Done (DoD) do not include it in the velocity calculation.
As sprints are completed a Team Velocity can be calculated. I don’t know of any hard fast rules for this calculation. JIRA calculates a team velocity after at least 3 sprints are completed and uses an average. It may take 5 or even 10 sprints to get to a predictable velocity depending on the agile maturity of the team.
Here is a table showing 3 example sprints with velocities.
Perhaps, in this example, the team was still getting organized in sprint 1 and getting foundational work done in order to drive out the first sprint, some stories weren’t completed, but a single 1 point story was. The velocity for Sprint 1 is 1 point. As the team delivered sprints they got better and more work was achieving the definition of done. Sprint 2 achieved 3 points of work and Sprint 3 achieved 8. The average velocity for these 3 sprints is 4 points. Because the team has to ramp up to a stable velocity, a rolling average works well. Say, a rolling average of the last three sprints. Later sprint are more likely to reflect the real velocity of the team.
How to use Team Velocity
After 3 Sprints we have a velocity of 4. This can be used to map out the full duraction of the project. This long term plan is known as the Release Plan.
|Product Backlog||Poker Points|
Given the remaining backlog has a total of 50 points of work left and the Team Velocity is 4 points, if we divide 50 by 4 we get 12.5. Scrum doesn’t work in half sprints, so rounding up we get 13. There are about 13 sprints worth of work left in the backlog.
A stable velocity requires a stable team. Everytime the team members change, or their allocation changes, the velocity will have to restabilize. Try to avoid changing team members.
Do not compare the Team Velocity with other teams. This is an invalid comparison. In fact, you may want to keep the velocity hidden to anyone but the delivery team.
Don’t overthink these numbers, they are not meant to be precise. Try to keep user stories as small as possible, 5 and under if you can. This helps get work through the pipe and increases the accuracy of the velocity. Your team estimates will also be more accurate on smaller User Stories.
The Sprint Velocity is a measure of how much work is completed in a sprint. The Team Velocity is a sprint velocity trend. This trend is usually calculated as a rolling average of the last 3 sprints. The simple way to forecast the number of sprints required to complete the work in the backlog is to add up the points on all remaining stories and divide by the Team Veolocty. Multiply the number of sprints required by the sprint length to get the calendar end date of the project.