Pages

▼

Thursday, March 19, 2020

Agile Asanas: Key Guidelines to Follow for Velocity (2)



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:



at

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.