In the earlier part of this article, we saw two key guidelines regarding usage of Velocity in Agile development. In this part, we will see a few more with detailed analysis.
To understand the fundamentals of velocity in Agile approaches, with a hands-on tool of MS Project, you can refer: Understanding Velocity in Agile Approaches with MS Project
*********
Guideline – 3: Always prefer real data for velocity calculation
This guideline is about the usage of real data for velocity calculation. But why is this guideline needed?
Because many teams start off with Agile for the first time and they don’t have any historical information/data available to show the team’s velocity. You can ask the management to wait for some time before you can give an estimate. But it’s highly likely (and I’ve seen so), management will ask for velocity measure and associated release dates.
What would you do?
First, calculate the team capacity, which can be in hours for the duration of the Sprint/iteration. Next, find out the work to be done in the iteration, which can be found from the data of the planning meeting. Finally, use these two – capacity and total work – to arrive at an estimate.
For example, let’s say:
- The team’s capacity is around 100 hours for the week.
You can ask your team member’s available hours in a week and sum it up.
- The iteration’s duration is 2 weeks.
- Hence, the team can complete 200 hours’ worth of work in the iteration.
Next, how do you map these 200 hours’ worth of work with the features that have been committed for the iteration?
For that you have to take Story Points and break it down to hours, i.e., a correlation of story points to number of hours.
How to do so?
For the sake of our example, let’s say:
- The team took a feature estimated at 2 story points (SP).
- Next, the team broke down this feature into tasks, and the total estimation comes to be 20 hours.
- This makes 1 SP to be worth 10 hours of work.
(2 SPs = 20 hours; 1 SP = 10 hours)
- The team can complete 20SPs worth of work in an iteration.
(200 hours = total team capacity for the iteration; 200/10 = 20 SPs in an iteration)
This becomes the estimated velocity for the iteration, i.e., the estimated velocity for the iteration is 20 SPs.
But then, the team just followed a big NO in Agile, i.e., correlating story points to hours. This is not advisable.
Hence, you should preferably use historical information. If your team is pressured to give an estimation, use the way that I just mentioned and clearly inform the estimation approach.
And, most important – discard this data (Estimated velocity of 20) immediately as soon as you get the real data.
Guideline – 4: Velocity is not a reliable indicator for your project's completion!
Velocity will be used to determine when the project is expected to complete. But use this metric with caution. It’s not a reliable indicator for the project’s end date.
How so?
In guideline – 2, we understood that velocity should be communicated in ranges. This way you don’t fall into the trap of “estimates being commitments”.
When estimates are not commitment, then with an uncertain estimate, you can never say with 100% confidence about the project’s completion. Can you?
Let’s reuse our example – you have a velocity of 12 to 18, i.e., you communicated in ranges. And you have a product backlog of 180 story points.
Hence the product backlog can be completed in two timelines. The iteration length for the team stays as two-weeks.
With Velocity 12:
- Number of iterations needed = 180/12
- Number of iterations needed = 15
- Project duration = 15 * 2 = 30 weeks
- Project duration = 7.5 months
With Velocity 18:
- Number of iterations needed = 200/18
- Number of iterations needed = 10
- Project duration = 10 * 2 = 20 weeks
- Project duration = 5 months
Hence, the project can be pessimistically completed in 7.5 months and optimistically completed in 5 months.
This is depicted in the below figure.
Guideline – 5: Velocity is not a measure of productivity
This guideline is derived from the first guideline. We understood that velocity can’t be compared among teams. It’s not an objective estimate and it’s subjective to the team.
In the linked article for fundamentals of velocity with MS Project, I’ve defined velocity as:
“Velocity is the measure of product backlog items (PBI) delivered in an iteration. It’s the rate at which the PBIs are delivered, validated, and accepted according to the definition of “done,” per iteration. In other words, you can say that velocity is a measure of a team’s rate of progress.”
In addition, I’ve also noted:
"Velocity is a measure of output (the size of what delivered, such as a 20 story points delivered). It’s not a measure of outcome (translating to value)."
Productivity is quite difficult to measure in any software team. Ideally, when productivity is brought in, it should translate to how much value has been delivered to the customer. Velocity is not clearly meant for this.
More importantly, when you track velocity as a measure of productivity, it again becomes a commitment metric to follow. Also, velocity as we saw depends on how the team is estimating the story points, the capacity available for the team during an iteration, the understanding of the team about the domain involved etc. – all of these are variable items.
To read part – 1 of this article, refer this link.
Agile Asanas Series:
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
*********
Velocity is a useful metric followed in many Agile teams and the calculation for it is quite plain and simple.
Velocity is the total story points (SPs) delivered by a team in an iteration or Sprint. For example, if a team completes 20 SP worth of features in an iteration, the velocity of the team for that iteration is 20.
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
This is shown in the below figure.
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.
Agile Asanas Series:
Projects, like human beings, are living entities. Just as every human being goes through a life cycle, so does a project. To understand life cycles, let’s break down a real-life example. Every day, you wake up from your bed, do your morning chores, have your breakfast, do your work, come back home in the evening, give some time to yourself, and then retire again to bed. Would you say these activities constitute a life cycle?
Think about it for a moment.
Did you think that your daily activities formed a life cycle? I guess not. It is not a life cycle because you are waking up the next day to do those same activities again, aren’t you? I hope so. I don’t expect to leave the world tomorrow, and I don’t think you do that either, so, our daily activities, in fact, constitute our daily routines rather than a life cycle.
What is a life cycle then?
Your human life cycle began when you were born into the world. You’ve passed through or will pass through many phases—infancy, adolescence, young adulthood, old age, retirement. Every one of us will have to leave the world one day, too. Your life cycle spans a timeline from you being born into the world and finally leaving the world. Similarly, the life cycle of a project spans from the time it is born into an organization and created until it is finally been finished or closed.
Why are life cycles so important? I’d like to suggest the importance is because a life cycle determines what things you do in your life and how you do them. Let’s say you had a good childhood, you received care in your upbringing, and hence, you grew well in later stages. With a good beginning, as you aged, you were able to contribute back to society in a positive way. Similarly, a project’s life cycle selection and correspondingly the development approach impacts how the project is going to be executed, led, managed, and finished. Life cycle dictates how a schedule will be managed, how cost will be estimated, how budget will be determined, how requirement changes will be addressed, and how various stakeholders will be engaged, etc. If all of this is determined and executed correctly, then the output of the project—product, service, or result—is expected to be a good one.
Various Life Cycles
PMI’s PMBOK® guide 6th edition documents that a project life cycle is a series of phases from its start to completion. The project life cycles can be predictive or adaptive. However, within a project, there can be one or many phases of development. These constitute the project’s life cycle, as depicted in the figure below.
Development life cycles can be of many types:
- Predictive Life Cycle
- Iterative Life Cycle
- Incremental Life Cycle
- Adaptive Life Cycle
- Hybrid Life Cycle
Understanding life cycles and selection of life cycle are important concepts while preparing for the Project Management Institute® Project Management Professional (PMP)® or Agile Certified Practitioner (PMI-ACP)® examinations. If you are a project manager, you also know that every project is unique, and you want to implement a good understanding of the various types of life cycles when tailoring a project’s development according to your need. This is where life cycle selection plays a crucial role.
Predictive Life Cycle
This life cycle is also known as “Plan Driven,” “Fully Plan Driven,” or as the “Waterfall Model.” The later term has been used in the last century mostly to refer to software development. The scope is known early in the life cycle, and you know exactly what the time needed and cost requirements are to deliver. In summary, this life cycle is used when the product to be delivered is well understood.
In many projects; however, requirements and scope are rarely known in detail before the project begins. As details and finalized scope is not known in advance, you can’t have the time and cost known in detail either. And so, this leads to another life cycle—the iterative life cycle.
Iterative Life Cycle
Here, you deliver in iterations by progressively refining the product every step of the way. The concept of progressive elaboration fits in here. Progressive elaboration is basically an iterative process of increasing the level of detail as greater amounts of information becomes available.
Both the product containing unclear requirements and the plan having unclear estimates are progressively elaborated. The product is developed over a series of iterations. The detailed scope for the current iteration is only known at the beginning of the iteration. You incorporate the feedback from previous iterations into the subsequent iterations.
Incremental Life Cycle
In some projects, there can be complexities with respect to technology or the platform being used. Now, this is different from low agreement or lack of clarity on requirements. This is the case where the customer is wanting the deliverables quickly.
Also, many times, it’s not important how well-refined your product is or how beautifully it’s done. Rather, the focus is on speed of delivery. In such cases, you can use the incremental life cycle. Here, the delivery that you give to the customer can be immediately used and/or the product increment is potentially shippable.
Adaptive Life Cycle
Our next cycle to explore is the adaptive life cycle. It is also known as the Agile life cycle. Agile development is both iterative and incremental (or I&I).
Many confuse iterative development with incremental development. They are not same.
Incremental development and delivery means that a product is developed in small chunks—not all at once. This is shown on the left side of the above diagram. Here, we take the highest priority features, as prioritized by the customer, first and foremost. When the highest priority features are delivered, the customer get the highest value features first. In incremental development, all features that you develop, should be fully complete or done.
Iterative development, on the other hand, means we deliver in iterations. We deliver a skeleton product or a prototype first. The next delivery is based on the feedback from the previous iteration(s). Then, with successive releases of the product (a release being a set of iterations), the product is refined further.
Remember, an Agile life cycle is both iterative and incremental?
In Agile life cycles, products are developed in iterations, a series of them. Each iteration also incrementally builds the product, and at the end of iteration, a deliverable or a set of deliverables is completed, as shown below.
To understand these life cycles, we will take a look at a popular diagram used by Agile practitioners, Stacey’s Diagram.
Stacey’s Diagram
On the Y-axis, we have the agreement (typically on requirements) and on X-axis, we have uncertainty (typically on technology or platform). You can also say the Y-axis is about “what to do,” whereas the X-axis is about is “how to do it.”
For simple projects, shown on the lower left side of the above figure, you know exactly what to do and how to do the work. Those simple items are rarities in software development and may not show up at all, other than perhaps in maintenance projects. If a disagreement on requirements comes up, you can use the iterative cycle, or if the technology complexity increases, you can use incremental cycle. These are items which are shown as “complicated” above.
At a high level of requirement complexity and a high level of technological complexity, the Agile life cycle is best. In other words, in “complex” projects, as shown in the above diagram, we take an Agile approach. Here, the iterations are very rapid and usually completed in a 2 to 4 week time period. Since it is also incremental, you get successively added functionalities. The adaptive approach is implemented in a rapidly changing environment, when requirements and scope are difficult to define in advance. At the end of each short and time-boxed iteration, there is a retrospective session or feedback meeting. Information collected from this session is incorporated into subsequent iterations.
We can also put it in another way, as shown below:
When you have high agreement on requirements or low churn in requirements and low uncertainties, you go for predictive mode. However, if the requirement churn is high (for example, there is a high degree of change) or the clarity on the requirement is not there, the project will be running in an iterative mode. For finished work that your customer may want to use immediately (such as high frequency deliveries), apply an incremental approach. Finally, go for Agile, when you iterate many times and are creating deliverables at the end of every iteration.
Advantages of Agile
The Agile approach has many advantages over traditional or fully plan driven approaches.
- Since the iterations are short and time-boxed, the team stays focused on the current iteration and delivery.
- The highest priority features are taken into consideration. Hence, the customer immediately gets value on them instead waiting for a longer time.
- High uncertainties mean high risks. The biggest risk a project can have is failure to deliver anything, or delivering something that was not originally intended. You cut down on these risks by delivering, not only early, but frequently.
- The customer gets an incremental version of the product at the end of every iteration. Hence, value is produced often, not just early.
- As the delivery happens rapidly, so also is feedback gathered. The issues, problems, new features, and/or emerging features can be incorporated into subsequent iterations.
I hope you’ve enjoyed this in-depth analysis into the various life cycle’s available within project management. As you can see, it is important to choose the correct one or the correct combination as it relates to the needs of your customer. More often than not, for complex projects, a flexible Agile approach, is the best.
References:
[1] I Want To Be An ACP: The Plain and Simple Way To Be A PMI-ACP, by Satya Narayan Dash
[2] Project Management Body of Knowledge (PMBOK) Guide, 6th Edition by Project Management Institute (PMI)
[3] Agile Practice Guide, by Project Management Institute (PMI)
[4] Agile Project Management with Scrum, by Ken Schwaber
[5] I Want To Be A PMP: The Plain and Simple Way To Be A PMP, by Satya Narayan Dash
This article was first published by MPUG on 17th April, 2018.
