Recently, I wrote an article Understanding Velocity in Agile Approaches with MS Project, where the foundational concepts of velocity have been explained first followed with a bit deeper dive into this concept. I’ve also explained a practical hands-on approach to determine velocity with a software tool.
In this Agile Asanas series, we will check-upon a few key guidelines while using velocity in Agile approaches. This is in continuation of Agile Asanas series. In the earlier part, we saw a completely new concept of Naikan and its applicability.
You can read it here: Agile Asanas: Using Naikan as an Agile Practice
*********
However, many teams use velocity wrongly in a number of areas. In this post, I’ll outline a few which I see frequently, e.g., comparing velocity of one team with another, which is a big NO in Agile. So, let’s see the guidelines for Agile teams, if you are using velocity as a metric.
Guideline – 1: Don’t compare velocity of one team with another
You compare things which are comparable, e.g., you can say one runner is faster than the other runner, one is a better speaker than another, one vehicle is producing better fuel efficiency than another or equipment is producing more outputs than another. You can’t just compare things which are no way comparable, e.g., velocity of the teams.
How?
Let’s say a team (Team 1) completed 3 features estimated at 5SPs, 8SPs and 3SPs in an iteration. Hence:
Velocity for Team 1 = 5 + 8 + 3 = 16
Now, let’s say another team (Team 2) completed 4 features estimated at 3SPs, 2SPs, 5SPs, 8SPs, respectively. Hence:
Velocity for Team 2 = 3 + 2 + 5 + 8 = 18
Next, the question which is usually asked is this:
Is Team 2 doing better than Team 1?
No. Because story point – the unitless measure used for the features – is a form of relative estimation. And it’s subjective to the team.
To know more about story points, refer:
Project Estimation with Story Points in Agile Development
A team which has been working for a long time on a project may estimate a feature at 3 story points (SPs), because they are quite familiar with the project. However, the similar feature by another team can be estimated at 5 story points or 8 SPs or even 13 story points. Because they are learning on a new project.
It is also possible there can be dependencies, compliance related work or external risks which may increase the estimate to 8 or 13 story points, for another team. Hence the team estimating a feature 8 SPs is no way comparable with a team estimating at 3 SPs.
Guideline – 2: Give ranges of velocity in your estimation, in place of absolute numbers
The first and foremost problem when you give an estimation in absolute numbers is this: estimates usually becomes commitments. Because it becomes a commitment, you will be required or at least expected to meet that commitment.
Another problem with absolute estimation is this: it becomes a benchmark to meet, if you meet it once! This will be shown to you, because you have earlier done so.
A team goes with Agile approaches, when there are uncertainties in technology, requirements or platforms. As there are many uncertain things, agile is both iterative and incremental in nature.
To know more about iterative and incremental developments, refer:
Why and When To Go For Agile Life Cycle
Hence, in an uncertain environment, it’s futile to give an absolute number. For example, let’s say a team has these velocity measures:
- Iteration 1: Velocity = 12
- Iteration 2: Velocity = 16
- Iteration 3: Velocity = 17
A histogram representation is shown below.
Next, many times, I’ve seen teams are enticed to give an average velocity, i.e., (12 + 16 + 17)/ 3 = 15. But what happens if the team has less velocity in the next iteration?
Let’s say for the next iteration the velocity comes as:
- Iteration – 4: Velocity = 13
You had earlier communicated the velocity (average one) to be 15. Now the velocity has come down to 13. It’s likely that your management will ask questions. And of course, it also looks bad.
What should you do?
You should communicate the velocity in range, i.e., 12 to 18:
- 12 as the worst-case scenario.
- 18 as the best-case scenario.
With this approach, other stakeholders realize that velocity measure given is not a commitment, but a range. And if you don’t meet the earlier one given, nobody will complain or ask questions, because they know it’s in ranges, not absolute numbers.
To read part – 2 of this article, refer this link.
References:
[1] Article - Understanding Velocity in Agile Approaches with MS Project, by Satya Narayan Dash
[2] Article - Project Estimation with Story Points in Agile Development, by Satya Narayan Dash
[3] Article - Why and When To Go For Agile Life Cycle, by Satya Narayan Dash
[4] Book - I Want To Be An ACP, The Plain and Simple Way to be a PMI-ACP, 2nd Edition, by Satya Narayan Dash
Agile Asanas Series:
- Agile Asanas: Using Naikan as an Agile Practice
- Agile Asanas: Key Guidelines to Follow for Velocity (2)
- Agile Asanas: Bus Factor, Broken Comb Skills and Cross Functional Team
- Agile Asanas: Story Map Vs Product Backlog - The Differences
- Agile Asanas: Mapping Traditional Project Roles to Agile Frameworks
You May Also Like:
- Book for PMI-ACP Exam Prep: "I Want To Be An ACP"
- Book for PMI-PMP Exam Prep: "I Want To Be A PMP"
- Book for PMI-RMP Exam Prep: "I Want To Be A RMP"
- Book for PMI-CAPM Exam Prep: "I Want To Be A CAPM"
No comments:
Post a Comment
Sign- or Log-in and put your name while asking queries in comments. Any comment is welcome - comments, review or criticism. But off-topic, abusive, defamatory comments will be moderated or may be removed.