Skip to main content

What is Velocity

Last post 12:12 pm May 17, 2016 by Andrew Lishomwa
8 replies
02:50 pm May 12, 2016

Searching the web, I seem to have found several different thoughts on what velocity is.

Here is an example that might clear it up for me.

Suppose we are looking back on a product development effort, trying to figure out what the velocity should have been in each sprint. Each row in the table below represents a sprint. To simplify, in each sprint the development team were fully occupied finishing exactly the one backlog item shown in a row.


|r | forecast work / | Units of | units of | Velocity | Velocity | Velocity |
|o | effort of the | Business | business | Answer | Answer | Answer |
|w | product backlog | Functionality | value | A | B | C |
|# | item Delivered | Delivered | delivered | | | |
| | | | | | | |
| 1| 8 | 8 | 8 | 8 | 8 | 8 |
| 2| 8 | 1 | 50 | 8 | 1 | 50 |
| 3| 1 | 8 | 50 | 1 | 8 | 50 |
| 4| 8 | -10 | 5 | 8 | -10 | 5 |
| 5| 8 | 5 | -10 | 8 | 5 | -10 |


Note: In row four, ten units of functionality were removed which increased the products value by five.
Note: in row five, five units of functionality were added, but they decreased the products value by ten.


Which answer has the velocity that should have been reported, perhaps shown on a chart of some sort?

What would be the velocity shown in row 3 if the another 5 units of effort had been directed to items not on the backlog, like defects, fixing unexpected technical debt, or attending a training course?

Thanks.


03:40 pm May 12, 2016

Trying to use code to pretty the table up again.
[code]
|r | forecast work / | Units of | units of | Velocity | Velocity | Velocity |
|o | effort of the | Business | business | Answer | Answer | Answer |
|w | product backlog| Functionality | value | A | B | C |
|# | item Delivered | Delivered | delivered | | | |
| | | | | | | |
| 1 | 8 | 8 | 8 | 8 | 8 | 8 |
| 2 | 8 | 1 | 50 | 8 | 1 | 50 |
| 3 | 1 | 8 | 50 | 1 | 8 | 50 |
| 4 | 8 | -10 | 5 | 8 | -10 | 5 |
| 5 | 8 | 5 | -10 | 8 | 5 | -10 |
[/code]


03:45 pm May 12, 2016

This seems rather complicated to me, and I find it hard to follow. What would you actually use such a measure for? Might there be a simpler way of assessing velocity that is fit for purpose?

Also, can a product's "value" really be accounted for by this, or indeed by velocity at all?


03:47 pm May 12, 2016

Steven,

Unfortunately, I cannot make heads nor tails of your example. It is unclear what the values in each row represent.

What is a unit of functionality? What is a unit of effort?

Velocity is a reflective metric gathered from the sprint throughput of a stable team. Usually, a velocity metric is not considered valid until several sprints have been completed.

It is used as a guide by the team to identify the amount of work they may be capable of completing in an upcoming sprint, and by the Product Owner to forecast potential release points of functionality.

Neither value, nor non-sprint efforts, factor in to a team's velocity calculation.


04:11 pm May 12, 2016

Formatting tables seems has defeated me.


The heart of the issues is what metric is used for velocity.


I was reading "Software in 30 days". On pg 131 is it says that Velocity is "A measure of how much business functionality is created during a period of time or for a unit of money"


I have build velocity out of the estimates of work needed to complete backlog items, but this seems to say that that doesn't matter. Its more about the functionality created, which is not necessarily the same thing.

What if the functionality is really small, but because the team doesn't know that part of the code very well, or there is a lot of technical debt, the estimate is really large?

What happens if you remove business functionality to get more value because of a simplified product?


05:29 pm May 12, 2016

If "A measure of how much business functionality is created during a period of time or for a unit of money" is a measure of velocity, what is a measure of business functionality?


06:23 pm May 12, 2016

Steven,

I do not claim to be an expert, but if that is indeed what "Software in 30 days" says on page 131, that velocity is a measure of how much business functionality is created during a period of time or for a unit of money, then they are simply incorrect in my opinion.

Velocity is simply a metric based on the completed items in a sprint by a single team. The metric is completely subjective to that specific team, and should never be extrapolated for any other comparison.

Regarding your estimation example, I believe you are also looking at it incorrectly. You should not relatively estimate based on the skill level of the team, but simply on the size of the item.

A favorite analogy of mine is to think of stories as boulders of rock that need to be moved from point A to point B. A team member may be "stronger" and can move a boulder quicker than others can, but the "size" of the boulder never changes. The estimate would change based on the size of the boulder (10 lb, 20 lb, 50 lb, etc), not on who is lifting it.

It is always a 50-lb boulder, regardless if it takes the team athlete 2 days to move it, or the scrawny team member 5 days to move it.

As team members get "stronger", they can move the 50-lb boulder in less time. THAT is how a team's velocity increases, as a result of their increased skill and proficiency, NOT because items are estimated differently based on who may be working on it.

When relatively estimating, it is always a matter of size, not duration.


05:59 pm May 14, 2016

I kept reading Software in 30 days and found a definition of "Business functionality" on page 82.

"Productivity is the number of units of business functionality that are developed for a specific amount of money. Productivity is also called velocity. This is not a measure of value, just of the amount of functionality produced. [A] unit of functionality is identified and measured. The size is measured in function points, an objective and abstract measurement for software. Function points are uniform and can be applied elsewhere within the system or product or to any other system"

If believe what the book is saying is that if a team estimates a Sprint will take 8 units of work, but it provides 1 unit of business functionality, and 5 units of value then the velocity of the Sprint is 1.

In that case Software in 30 days is essentially saying that
--velocity has nothing to do team estimates.
--velocity can be uniformly measured across teams.


12:12 pm May 17, 2016

The key thing for me is Timothy's point 'The metric is completely subjective'

If the team figures that adding a column to a table on a page is an effort of 2 (for example) is the effort for the current story being estimated more or less than that? Half? Double?

Once you've figured out how many of those 'points' (whatever you call them) you have then if you are just starting the team/project it's a gut feel thing but it gets better and more fine tuned as you go along. How many points did you manage last sprint? That's your velocity.

What we do is look at our average velocity over the last four sprints as a guide for how many points we can take in to the sprint being planned. If we wind up having capacity left over at the end we can take another story into the sprint backlog (ideally one that ties in with the sprint goal) and then our average velocity next time will be a bit higher and we know we can take on more than we could before.

PS we go up in Fibonacci numbers for story sizing


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.