Get certified - Transform your world of work today

Close

Ways to Measure Velocity in Agile

17 September 2015

Sandip Saha
Cisco Systems


All of us are familiar with the velocity concept used in Agile. We define velocity in Agile as the sum of story points delivered in a sprint over a period of time. So to make it clear, let us assume that we have completed ten sprints, as illustrated in Figure 1 below.
 
Sprint Total story points delivered Velocity
Sprint 1 20 20
Sprint 2 22 22
Sprint 3 19 19
Sprint 4 19 19
Sprint 5 23 23
Sprint 6 21 21
Sprint 7 13 13
Sprint 8 22 22
Sprint 9 21 21
Sprint 10 25 25

Velocity-in-Agile-IMAGE-1.jpg
Figure 1. Story points delivered in a sprint over time

By examining the data and trend chart, I can calculate my team’s mean velocity, which will further help me forecast release dates and come up with a release strategy. This is the most conventional way of capturing a team’s velocity in Agile.

Now let us try to explore the same concept from different perspectives. I will cover two scenarios to demonstrate the velocity concept.

If you look into the broader definition of velocity, it is nothing but the run rate of the team, and it helps forecast the target date by which the team will be able to reach their goal.
 

Scenario 1: When the team is working on tickets, service requests, or incidents

My experience in the IT industry and with Agile tells me that across many organizations, it's often the case that the complexity, effort, and size among different incidents, service requests (SR), or tickets are minimal. Or I can say that these SRs or incidents are similar in nature. My question is: Do we still need to do story-point estimations in such cases? I feel that it would be a waste of time to engage the entire team to do story-point estimation.

So what can be done in such cases? My recommendation is to calculate the number of stories completed per sprint over a period, which then becomes the team’s velocity, as illustrated in Figure 2 below.
 
Sprint # of Incidents closed Velocity
Sprint 1 10 10
Sprint 2 11 11
Sprint 3 12 12
Sprint 4 10 10
Sprint 5  9  9
Sprint 6 11 11
Sprint 7 13 13
Sprint 8  8  8
Sprint 9 10 10
Sprint 10 12 12

Velocity-in-Agile_IMAGE-2.jpg
Figure 2. Number of incidents closed over time

In this scenario, you can also find out the team’s mean velocity and forecast your release date. The goal of forecasting the release date is met.

Note: The above recommendation can be applied only when the differences among size, complexity, and effort needed to solve the incidents are minimal (i.e., hardly any differences exist among the tickets).
 

Scenario 2: What if we calculate velocity in man-hours?

In this case also, we can save the time spent on story-point estimation. Let us see how it works in the following scenario.

The team has completed ten sprints, and we have captured the total effort in hours (team’s utilization) per sprint over time (see Figure 3).
 
Sprint Actual effort in hours Velocity
Sprint 1 221 221
Sprint 2 252 252
Sprint 3 230 230
Sprint 4 218 218
Sprint 5 232 232
Sprint 6 225 225
Sprint 7 225 225
Sprint 8 247 247
Sprint 9 231 231
Sprint 10 237 237

Velocity-in-Agile_IMAGE-3.jpg
Figure 3. Actual effort in man hours over time

In this case also, if we know our backlog in terms of hours and we know our team size, we can come up with a release date. You might wonder what team maintains their backlog by breaking user stories into tasks and keeping them estimated in real time. The point is not to break your user stories in the backlog into tasks and estimate them in hours, but, rather, you can take a holistic approach: My total backlog may take 1,000 man hours (guesstimate), and if I know my team’s velocity in man-hours, I can still predict a release date. As you can see, the overall objective of velocity has been met again.

These are a few challenges I have faced in my Agile career, and these approaches have worked well for me. Please go through a scenario that closely simulates your own current Agile environment and provide your feedback.
 

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 4 (6 ratings)

Comments

Tim Baffa, CSM, 9/17/2015 3:50:40 PM
Sandip,

A few observations:

- Your velocity metrics in figures 1 and 2 are not accurate. You have velocity equal to the delivered story points each sprint, instead of recalculating the team velocity each sprint based on the total number of completed story points divided by number of sprints.

For example, the velocity in figure 1 after sprint 5 would be 20.6 (20 + 22 + 19 + 19 + 23)/5, not 25 as listed.

- If a team is defining stories that are always similarly-sized, then one can certainly use number of stories as a velocity metric, which would save on effort estimation.

However, that is a BIG "if". I have only seen this type of sizing occur within very mature scrum teams; therefore, I would challenge your assertion that this practice of creating similarly-sized stories is often true and occurs throughout many organizations. The evidence simply doesn't support that.

- I would avoid any attempt to equate team work effort to number of hours. This ignores the mountain of empirical evidence that proves people do a terrible job estimating time to completion when the item has variability (software development = creative process = variable!).

Using hours is inherently inaccurate, and potentially destructive. How can the "team" provide an estimate based on the number of hours? Who is doing the work? Can the story get finished quicker (or slower) depending on who works on it? Yes it can. So stop pretending that you can provide a time-based estimate with ANY level of certainty. You simply can't.

Use relative estimating, in any way possible (Fibonacci, t-shirt sizes, etc.). Estimate the SIZE of the story, not how long you think it will take to complete.

How big is the hole you have to dig? It doesn't matter if you have a shovel, or a bulldozer, the SIZE of the hole doesn't change!
Sunil Peter, CSM,CSPO, 9/21/2015 5:21:01 AM
Nice article, like your overall way of trying present velocity. I do find it difficult to grasp the tabular representations of the measures. I would look at more of average with ranges than absolute numbers for the initial stages till the process gets matured. Secondly, I would not really bet on the effort and incidents to arrive with the velocity.

Do share your views.
Meghan Robinson, CSM,CSPO, 3/17/2016 4:13:53 PM
Would you be okay with us highlighting this article on our new AgileCareers Blog?

You can view the blog here: http://membership.scrumalliance.org/blogpost/1322603/AgileCareers-News

I look forward to hearing your response! Thanks.
Kaushik Saha, CSP,CSM,CSPO, 3/29/2016 2:54:58 AM
Hi Sandeep,

A small observation - how come efforts equate with velocity ? Velocity is measured by "Story Points" and "Effort Estimation" is measured by "Hours". Your table derives, 1 Hour = 1 Story Point - This is NOT true.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.

 

Newsletter Sign-Up

Subscribe