Velocity in Agile

Velocity in AGILE

What is Velocity?

Velocity is a metric that predicts for the agile software development team how much work the team can able to complete within a sprint. It is a spectacle to see the project how long or how much iteration would require completing it. It's a key factor in time management for any project. We can determine the velocity, the amount of story points the development team completes in each sprint.

How to use Velocity to estimate the project?

First we need to run the sprint and know the velocity of it. In other words how many story points a team has completed in a sprint (2 week sprint)?
Determine the number of sprints required to complete the remaining story points in the product backlog as in the following:

Number of sprints required = (the remaining story points in the product backlog) / velocity

Assume your product backlog has 400 story points and your team velocity is 20 story points per sprint.

Sprints required = 400 / 20

Total Sprints required to complete = 20 more sprints.
Determine the time required to complete the 20 additional sprints. If each sprint length is two weeks then it would take 40 weeks to complete it.

In the beginning of the project, the velocity will be low, then as the project progresses the velocity will increase and be consistent. Always use the velocity to measure the development speed, not to pressure the team to complete these tasks.

You might have a question now. How do I calculate velocity if one resource goes on vacation for the upcoming sprint? The answer is, your team has five members and the velocity is 60 story points per sprint. One member is on vacations during the next sprint. So the team capacity will decrease by 20%. Your estimated velocity for that sprint would then be 48 story points as in the following:

60 * (100% - 20%) = 60 * 0.80 = 48

How to increase Velocity?

Obviously, the project leader really loves this title, yes of course everywhere in the corporation, it is desirable to increase the output. Here we shall discuss some points that I experienced during my career.

Remove the barrier you felt for the specified developer; the barrier could be engaged in another project or lack of domain knowledge other personal reasons.
Determine the necessities of your team that are really needed once the sprint starts. It could be a hardware necessity to accomplish that story or it could be a third-party software necessity.
The team should not be disturbed by any non-sprint work. It's the job of the scrum master to protect the team. Multitasking is highly discouraged. There should not be any addition or reduction of members from the team
Self organizing principles should emerge from the team to work more efficiently
The planning and estimation is really important during the sprint plan meeting. If we derive a good plan in the beginning we would not end up
Product owner involvement daily with the team yields more benefit

Summary

Velocity is a range, not a single value and is generally most useful when planning the project schedule once the velocity stabilizes. So tracking the velocity is a valuable process. It can be helpful for sprint and release planning.