Estimating Velocity for Iterations in Agile
Agile allows companies to deliver value to their clients earlier and to adapt to changes faster. Agile methodologies such as scrum, kanban, and XP are widely using in software development industry.
Recently I researched about the velocity, velocity estimation, and its benefits as prior to my final year project. I would like to share some points I found during my research about velocity estimation.
Velocity is a measure of a team’s rate of progress. It is calculated by summing the number of story points assigned to each user story that the team completed during the iteration.
Let’s start with iteration planning. Iteration is a single development cycle, usually measured as one week or two weeks. There are two ways of planning an iteration,
01. velocity-driven iteration planning
02. commitment-driven iteration planning
Commitment-Driven Iteration Planning
Here, rather than creating an iteration plan that according to the number of story points or ideal days already completed in the prior iteration, the team is asked to add stories to the iteration one-by-one until they can commit to completing no more.
Velocity Driven Iteration Planning
First, they identify the target velocity for the coming iteration. The team then selects an iteration goal, which is a general description of what they wish to accomplish during the coming iteration. After selecting an iteration goal, the team selects the top priority user stories that support that goal. Stories are selected as necessary for the sum of their ideal day or story point estimates to equal the target velocity. Finally, each selected story is split into tasks and each task is estimated.
How does a team estimate the velocity?
The commonly used assumption by most teams is that their velocity in the
next iteration will equal the velocity of the most recent iteration. By doing an industry survey we found that many teams select the velocity of the most recent iteration for as the basis of next iterations with some adjustments.
According to many resources including [1], the most preferred way to forecast velocity is to run at least 3 iterations and then estimate velocity from the observed velocity during the one to three iterations.
Further, the observed average velocity can be converted into a range using Cone of Uncertainty.
If the team has run a single Iteration, the “initial product definition” milestone is considered and the corresponding range is used. If two Iterations are completed, the range corresponding to the “approved product definition” milestone is used, and so on. For example, a team has run three iterations with an average velocity of 50 during that period. For three iterations the appropriate range is 85% to 115%. This means that if the team’s average velocity is 50 after three iterations, their actual true velocity by the end of the project will probably be in the range 42–58.
Factors Cause to Fluctuations in Sprint Velocity
The factors that cause velocity can divide into two categories.
01. The Friction forces are the factors that are make constant drag on productivity and reduce Project Velocity.
Examples :
a. Team Composition (right people with right skills)
b. Process (changes to the current development process)
c. Environment (interruption, noise, poor ventilation condition etc.)
d. Team dynamics (Some team members may not fit well with others)
02. The Variable or Dynamic Forces that decelerate the project or team members and cause the Project Velocity to be irregular.
Examples:
a.Team changes
b. New tools
c. Vendor defects (defects in third-party tools)
d. Outside responsibilities
e. Personal issues
f. Stakeholder issues
g. Unclear requirements
h. Personal issues
Apart from that, I pointed out that the high work in progress rate is caused to decrease the velocity at the end of a sprint.
High work in progress (WIP)
There can be issues in the sprint, which are not met the definition of done at the end of the sprint, but already committed. The commitment has already acquired the effort of the developer, but it does not consider when counting team velocity. It is very important to manage WIP amount to get an effectively delivered velocity.
Conclusion
Velocity estimation is pretty challenging as the dynamic nature of the team and outside environment. But it is still possible to do an estimation by considering historical data of past iterations and the accuracy can improve using the cone of uncertainty. Development teams should pay attention to work in progress amount at the end of a sprint as they are not captured as done velocity of a sprint.
Reference
[1]Agile estimating and planning by Mike Cohn
[2]Effort Estimation in Agile Development using Story Points by Evita Coelho and Anirban Basu
[3]An Effort Estimation Model for Agile Software Development by Ziauddin, Shahid Kamal Tipu, Shahrukh Zia
[4]Understanding sprint velocity fluctuations for improved project
plans with Scrum: a case study by Filipe Albero Pomar, Jose A. Calvo Manzano, Edgar Caballero and Magdalena Arcilla-Cobián
Level Up Coding
Thanks for being a part of our community! Subscribe to our YouTube channel or join the Skilled.dev coding interview course.
