In an Agile project, one most misunderstood concept, which is vital for the project is “Velocity”. While different teams understand velocity in their own way, this blog aims to explain what is “Velocity”? What is the significance of it? And what teams can do to increase it?
Let’s try to understand the term “velocity” before we jump into how teams can increase it for them or more importantly, use it for prediction and improvement.
What is Velocity?
Velocity is a number which defines the team’s capacity to deliver a working software in a sprint. It is the average of total story points which a team has delivered in their last 3-5 sprints. Velocity can also be understood as the size of the increment which your team can deliver. It is a historical number which is used to predict your backlog completion time at any point in time. Velocity is an average and may change during the sprint execution.
How is Velocity Calculated ?
Velocity is the average of story points which a team has burnt in their last 3-5 sprints. For example : If Team A has delivered / burnt 30 Story Points in Sprint 1, 35 Story Points in Sprint 2 and 25 Story Points in Sprint 3;
Average Velocity = 30 + 35 + 25 / 3 = 30 Story Points
In this above example Team A can deliver 30 Sps of work every sprint and that is their velocity
Common Misconceptions and Antipatterns with Velocity:
- Teams considering velocity as the team’s efficiency
- Teams tracking velocity to track productivity
- Teams tying velocity to the performance appraisal
- Teams getting burnt trying to increase their velocity
- Teams calculating velocity / developer in a sprint to calculate individual capacity
- Teams bringing in anti agile practices to shoot up velocity
- Teams ignoring DOD , Acceptance Criteria to close the story so that their velocity adds up
- Teams estimating high story points so that velocity can be higher
- Increasing the team size to increase velocity
Velocity is just the measure of a team’s capacity and nothing else. Many teams run behind increasing the team’s velocity in a lot of ways, but they end up burning up development team members.
Practices that can help you derive best Velocity from your team :
Our Sincere recommendation is not to run behind increasing your team velocity but start using velocity to predict your releases or to identify any improvement points.
However, in a practical scenario, there are a few practices which help you maintain your velocity and to full utilize your team’s capacity to complete work.
- Reduce Manual Work : Bring in automation to help build and deploy stories. Explore CI/CD and Devops. Automate your team’s testing process. Use tools like SONARQUBE for automating code reviews
- Creating a mature cross functional team: Imagine a set of full stack developers picking up and completing a user story against 1 front end developer, 1 backend developer and 1 QA. The later option creates dependencies and results in part of stories being completed within a sprint rather than completing a story
- Train your dev team with multiple technologies. Training / sharing knowledge within the team can enable individuals to pick up a story and finish it by themselves which also reduces bottlenecks related to skillset and technology
- Start completing one story before picking up the next story : Teams tend to pick up a story while they are working on another story. It is highly recommended to start finishing a story before pickup the next one to give a logical closure for the story picked. Completing 3 out of 5 stories picked is always better than all 5 stories partially completed
- Break your stories into smaller stories: Teams spill their big stories to multiple sprints which affects their velocity as well. Start breaking stories into smaller goals and achieving it within a sprint rather than taking a big story and spilling them to multiple sprints
- Improve Quality Process to Reduce Retesting and Bugs : Bring in practices like unit testing, peer reviews, automation regression etc. to help reduce bugs which inturn promotes completion of stories
- Do Backlog Refinement : Backlog refinement in the mid of the sprint helps identify blockers / dependencies which can be resolved even before the sprint planning takes place. This can avoid scenarios where stories are picked up in the sprint with dependencies and cannot be completed because of delay in resolution
While velocity is an important metric which is used in Agile, it is important to understand what it is, why it is used and then make use of it appropriately.
Once Again, rather than putting your energy in Trying to increase your team’s velocity, concentrate on what your velocity is and how you can make full use of it for prediction.
Hope this blog helps you understand what Velocity is and the antipatterns around it and also ways to improve your process to make full use of your teams capacity. With this, our blog on “How to increase your team’s velocity” comes to an end.
Please reach out to us at “email@example.com” for any feedback , suggestions or questions.
Agile Consultant, Benzne