What is Velocity

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]

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?

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.

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?

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?

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.

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.

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