Creating efficient timelines is a must for time critical projects. Not only does it help the development team define their day-to-day tasks but also helps them chart out task priorities for each sprint or iteration. In Agile, timelines are calculated by considering velocity.
What is velocity in agile? It is a metric or calibration tool that helps teams measure the work that is done in an iteration. Calculating velocity helps the team arrive at timelines and define how soon the project can be delivered. In this blog, we attempt to look at velocity in Agile and its associated benefits and pitfalls.
Contents
What is velocity in Agile?
Let us look at some of the terms mentioned in this definition.
- Estimates: In Agile, an estimate is the effort required to complete tasks in the product backlog. Estimation is an important activity to forecast the overall effort needed to complete a project.
- User Stories: In Agile, a project is broken down into smaller units. The smallest unit of work is known as a user story and is an end goal. It is a written description of the feature from the perspective of the end user.
By computing the velocity, teams can estimate how long it will take to complete the project. Velocity is calculated by using the estimates on the remaining user stories and with the assumption that velocity will remain the same over the coming iterations.
Though velocity may not be a 100% accurate, it provides a rough estimate that is precise. Velocity makes it easier to work in the Agile iterative model as you can estimate how much work is to be done to complete the project, how long it will take for your team to move through the backlog and assign tasks effectively.
Evolution of Velocity:
Agile has never been prescriptive and its concepts have never been rigid and defined. Agile concepts and fundamentals have evolved over time, and practices that have proven to be successful have become Agile standards.
The concept of velocity too was a late addition to the Agile toolkit. In the year 2000, velocity was used in Extreme Programming, replacing ‘load factor’. From 2002 onwards, velocity became a main stay in Scrum teams that started incorporating the practice of measuring velocity.
How is Velocity in Agile Measured?
Velocity can be measured at several levels:
- At the individual task level
- At the sprint level
- At the epic or release level
Measuring or calculating velocity in Agile is simple. Velocity at the sprint level can be calculated by measuring the total amount of backlog items that were delivered during a sprint.
Velocity can also be calculated by considering story points. Story points make up user stories and are a unit of measurement that represent the amount of effort required to complete a task. Typically, each organization has its own method of assigning values to story points.
The velocity for a particular sprint would be calculated by multiplying the number of user stories completed in the sprint with the story point assigned to each user story. For example: If you have completed 4 user stories and have assigned 3 story points to each story then the total velocity for the sprint would be 4*3=12.
Individual sprint velocities can be averaged to find out the average sprint velocity.
How to Use Average Velocity in Agile Development
Agile is all about iterative development, providing quick solutions and getting the products to market fast. In order to do this, Agile teams must know how much work they can do in a sprint and how long they will take to complete the project or deliver to the customer. Velocity helps them decide this and work effectively.
Average velocity is calculated once the project has progressed through three or four sprints. The average velocity is calculated by averaging the story points accumulated in each sprint. Based on this average velocity calculated, teams can base the amount of work that still needs to be done.
If we consider the above example of average sprint velocity, then we can assume that the team can accomplish work at the rate of 12 story points in each sprint. So, if you still have 120 story points left to be completed in your project, then you can go with the assumption that you will need an additional 10 sprints to complete the project.
