For agile teams, scrum visualizations are a great communication tool to track your development process. It also fosters engineering best practices for continuous improvements. In scrum, velocity is how much work (in story points) is completed by the team in a sprint. Tasks have to achieve their acceptance criteria to be marked as done. Thus, a velocity chart tracks the velocity of previous sprints.
Velocity charts should become more and more consistent as time goes on as the team should have a good idea about their capabilities. Additionally, as the team experience more sprints and backlog grooming, the team should have a better handle at estimating a task’s complexity and give appropriate story points as well. In other words, a well-functioning scrum team will have a low variability in-between sprints, provided that all the members in the team are present during the sprint.
How to create a velocity chart
Your agile tracking tool (like Jira, monday.com, Trello) should already be able to automatically create a velocity chart. However, you can make your own as well manually.
After every sprint, accumulate how many story points you completed in the sprint. Make sure you only record the stories that pass the acceptance criteria and not all those that were committed initially in the sprint. Record this against other sprints in a bar chart as the sprints go on.
Common problems identified with velocity charts
As mentioned above, we strive for a low variability velocity chart that indicates a relatively consistent cadence between sprints. However, there are patterns you can see using a velocity chart that can indicate a problem for you to diagnose. Some common problems include erratic velocity, growing velocity, and jagged velocity.
This velocity chart shows that there is inconsistent performance across multiple sprints. This could mean a couple of things: First, the team still hasn’t been able to create a consistent rhythm of continuous development. Perhaps the team lacks permanent team members to complete the same amount of work. Or other impediments like a missing subject-matter expert needed to assist in completing the task. Another problem might be that the team gets distracted by external factors outside the sprint.
What you should do: Diagnose and identify what is causing this inconsistent performance. Particularly, the Scrum Master needs to eliminate obstructions that are blocking your team from completing a consistent velocity each sprint and optimize the process. If there are external changes, make sure that they are not going to detract the team from the sprint goal. One-off events are fine, but regularly missing your sprint goal is a sign that the team hasn’t performed as a proper scrum team.
There are two main reasons for an increasing velocity chart. First, the team has just started scrum and is figuring out its capabilities in delivering sprints. Or, the team is growing and having more contributors in each sprint. If these are the reasons for this pattern, then there is no problem and it is as expected.
Another reason is the team might consciously or unconsciously inflate story points for tasks, perhaps thinking that they lead to some performance indicator, showing that the team is artificially working better each time. This defeats the purpose of a velocity chart and needs to be addressed.
What should you do: If the reason is the latter, you need to make sure that there are no performance bonuses tied to story points completed. A story point is an arbitrary number that a team agrees to that helps them with comparing complexity between tasks. The amount of work associated with a story point differs from team to team, and so there is no reason to track story point completion to performance. Having consistent velocity is much more useful in showing whether you’re on track to complete milestones.
This velocity chart shows that in every other sprint, the team has completed more story points. Teams are not completing all the stories by the end of the sprint, and that the story points get recognized in the next sprint. The team might be overly ambitious about their sprint goal as well. Regularly missing the sprint goal is a sign of a problem needing to change.
What should you do: Figure out why the team is not completing the sprint goal on time. If the issue is the sprint length, perhaps consider a longer sprint duration. Or, if the team is too ambitious, then try to commit to fewer story points for the next sprint. If stories are poorly estimated, then focus on breaking down the tasks more to smaller stories.
Best practices of a velocity chart
Remember, a velocity chart is used for an estimation tool, and not a Key Performance Indicator (KPI). Having KPIs on velocity simply encourages teams to inflate story points. Once you get a roughly consistent velocity that you can target, you can then be confident of your projection of how much work can be done in the next few sprints with this team.