## Re: [scrumdevelopment] Velocity - Estimate or Actuals?

Expand Messages
Message 1 of 19 , Aug 1, 2006
• 0 Attachment
Why aren't you explaining velocity in term of story points instead of task hours?

On 8/1/06, Nicholas Cancelliere < nicholas@...> wrote:

I've read that velocity is calculated using historical estimates
(what the team estimated and committed to) vs. the actuals a team
did. An example (condensed for easy math):

5 day iteration, three developers are expected to burn 5 hrs a day
(the other 3 hrs are slop/buffer for email, meetings, etc - last
day), there are 3 stories (for each developer).

Story 1 - 20 hrs estimated - 22 actual
Story 2 - 20 hrs estimated - 38 actual
Story 3 - 20 hrs estimated - 18 actual

Would you not then say the velocity as 78 (average of the 3 actuals,
26 * 3), and maybe schedule 70-75 hrs next iteration, or is it just
60. I am having a difficult time explaining this to our project
manager to understand why actuals don't equal velocity -- or should
they? In Mike Cohn's book it seems to indicate velocity is based on
historical estimates, not the actuals.

-Nick

--
• ... I use historical estimates (but I do try to get better estimates). I look at velocity as, what is the team s demonstrated ability to predict and deliver
Message 2 of 19 , Aug 1, 2006
• 0 Attachment
On 8/1/06, Nicholas Cancelliere <nicholas@...> wrote:
> I've read that velocity is calculated using historical estimates
> (what the team estimated and committed to) vs. the actuals a team
> did. An example (condensed for easy math):
>
> 5 day iteration, three developers are expected to burn 5 hrs a day
> (the other 3 hrs are slop/buffer for email, meetings, etc - last
> day), there are 3 stories (for each developer).
>
> Story 1 - 20 hrs estimated - 22 actual
> Story 2 - 20 hrs estimated - 38 actual
> Story 3 - 20 hrs estimated - 18 actual
>
> Would you not then say the velocity as 78 (average of the 3 actuals,
> 26 * 3), and maybe schedule 70-75 hrs next iteration, or is it just
> 60. I am having a difficult time explaining this to our project
> manager to understand why actuals don't equal velocity -- or should
> they? In Mike Cohn's book it seems to indicate velocity is based on
> historical estimates, not the actuals.

I use historical estimates (but I do try to get better estimates). I
look at velocity as, "what is the team's demonstrated ability to
predict and deliver stories?"

In the case at hand, it seems to me like you're talking about going
exactly the wrong direction. You tried to schedule 60 hours work, but
it ended up as 78 (~30% over the prediction). For you to actually
schedule 60 hours work, it seems you should have planned ~45 hours.

(In this case, it looks like 2 stories were close to their estimate,
one was way over. I'd want to understand what happened there. Is it
something that's going to affect a certain class of story?)

What I'd do:
- re-estimate the remaining stories in light of what I learned this time
- estimate 60 as my velocity for next iteration.
- deliver those 60 and expect/hope to ask for more stories (raising

(We expect to do more, as we believe our estimates are now more accurate.)

I prefer to let velocity be a "trailing" indicator in this sense, as a
measure of our *demonstrated* ability to deliver.

--
Bill Wake William.Wake@... www.xp123.com
• I think you hit it on the nose. I d guess that when the PM hears the word velocity she s naturally thinking in terms of speed and how much work the team is
Message 3 of 19 , Aug 1, 2006
• 0 Attachment
I think you hit it on the nose.  I'd guess that when the PM hears the word "velocity" she's naturally thinking in terms of speed and how much work the team is able to process.  The subtle difference is the idea of the team's ability to demonstrate predict and deliver stories.  I'll try to explain it in this way and see how that goes over.

The example was made up to demonstrate the point, but yeah if there was a 38 I'd want to know what went wrong there in the estimate.

On Aug 1, 2006, at 8:24 PM, William Wake wrote:

On 8/1/06, Nicholas Cancelliere <nicholas@ozmox.com> wrote:
> I've read that velocity is calculated using historical estimates
> (what the team estimated and committed to) vs. the actuals a team
> did. An example (condensed for easy math):
>
> 5 day iteration, three developers are expected to burn 5 hrs a day
> (the other 3 hrs are slop/buffer for email, meetings, etc - last
> day), there are 3 stories (for each developer).
>
> Story 1 - 20 hrs estimated - 22 actual
> Story 2 - 20 hrs estimated - 38 actual
> Story 3 - 20 hrs estimated - 18 actual
>
> Would you not then say the velocity as 78 (average of the 3 actuals,
> 26 * 3), and maybe schedule 70-75 hrs next iteration, or is it just
> 60. I am having a difficult time explaining this to our project
> manager to understand why actuals don't equal velocity -- or should
> they? In Mike Cohn's book it seems to indicate velocity is based on
> historical estimates, not the actuals.

I use historical estimates (but I do try to get better estimates). I
look at velocity as, "what is the team's demonstrated ability to
predict and deliver stories?"

In the case at hand, it seems to me like you're talking about going
exactly the wrong direction. You tried to schedule 60 hours work, but
it ended up as 78 (~30% over the prediction). For you to actually
schedule 60 hours work, it seems you should have planned ~45 hours.

(In this case, it looks like 2 stories were close to their estimate,
one was way over. I'd want to understand what happened there. Is it
something that's going to affect a certain class of story?)

What I'd do:
- re-estimate the remaining stories in light of what I learned this time
- estimate 60 as my velocity for next iteration.
- deliver those 60 and expect/hope to ask for more stories (raising

(We expect to do more, as we believe our estimates are now more accurate.)

I prefer to let velocity be a "trailing" indicator in this sense, as a
measure of our *demonstrated* ability to deliver.

--
Bill Wake William.Wake@acm.org

• ... How accurate an estimate is needed? Is there a range of uncertainty that is allowed or is an estimate in this case a precise amount of hours(which seems
Message 4 of 19 , Aug 1, 2006
• 0 Attachment
On 8/1/06, Nicholas Cancelliere <nicholas@...> wrote:
>
> The example was made up to demonstrate the point, but yeah if there was a 38 I'd want to know what went wrong there in the estimate.
>

How accurate an estimate is needed? Is there a range of uncertainty
that is allowed or is an estimate in this case a precise amount of
hours(which seems to be an odd defintion of estimate)?

If one was making a statisitical analysis there would be concern for
multiple outlying points, but estimates do tend to 'range' depending
upon the story and task in my experience.

I.e. The team estimates that story A will have 5 tasks totally 30
hours. It turns out during the work that it takes 8 tasks and 50
hours. Was story A estimated poorly? What could one say went wrong
if the story was implemented to the user's satisfaction?

thanks,
--
• Even though this might be a bit off topic to start off with, I have found that using a more abstract version of estimating has been more useful for my projects
Message 5 of 19 , Aug 1, 2006
• 0 Attachment
Even though this might be a bit off topic to start off with, I have
found that using a more abstract version of estimating has been more
useful for my projects to determine a velocity. This abstraction
started out with days of effort left, then moved to story points, and
recently I have found that t-shirt sizing has been the most "accurate"
for me. Accurate is quoted because estimates, as you have shown in
your estimates vs. actuals example, are incorrect by nature of humans
not being able to predict the future. By using more abstract
estimating units managers, customers, and product owners are less
likely to equate actuals and estimates based on time as predictable
units for a velocity to be defined by. It will probably start a
conversation such as "what are these points anyway?" but that is

When applying the t-shirt sizing method we usually use a doubling
factor from XS to L as pointed out in the Mike Cohn book "Agile
Estimating and Planning". It appears to be much easier for teams to
make comparisons between stories than to define duration based
estimations. For instance, here is a breakdown of the points to
t-shirt size:

XS - 1
S - 3
M - 6
L - 12
XL - ? (doesn't matter, too BIG)

As you can see, XS does not keep with the doubling factor and I can't
explain that very quickly so I will just leave it up to the
imagination of how we got to the unit 1. Based on the points we can
derive a velocity over the first few iterations with the team as an
average or something close to that such as:

Sprint 1 - 33 points completed
Sprint 2 - 42 points completed
Sprint 3 - 38 points completed

Based on this information we may decide that our velocity is
approximately 37 points and decide on how close to this point total
that we should allow on the sprint backlog. There are definite
possibilities of anomalies for an individual sprint but this doesn't
usually mean the estimation and velocity planning was flawed. It is
usually because there are more unknowns in the items that are
prioritized high on the product backlog and making their way onto the
sprint backlog.

To make a long story short, I have found over my past 4-6 projects
that velocity derived from estimates has been more useful than from
any averages derived from actuals. In fact, I have usually not found
use for tracking actuals at all unless we were trying to educate the
customer on the state of their legacy codebase which we are now
maintaining and what types of features take longer to work on.

Chris Sterling
SolutionsIQ
www.SolutionsIQ.com <http://www.solutionsiq.com/>
Redmond, WA 98052
csterling@...

________________________________

From: scrumdevelopment@yahoogroups.com on behalf of Nicholas
Cancelliere
Sent: Tue 8/1/2006 17:15
To: scrumdevelopment@yahoogroups.com
Subject: [scrumdevelopment] Velocity - Estimate or Actuals?

I've read that velocity is calculated using historical estimates
(what the team estimated and committed to) vs. the actuals a team
did. An example (condensed for easy math):

5 day iteration, three developers are expected to burn 5 hrs a day
(the other 3 hrs are slop/buffer for email, meetings, etc - last
day), there are 3 stories (for each developer).

Story 1 - 20 hrs estimated - 22 actual
Story 2 - 20 hrs estimated - 38 actual
Story 3 - 20 hrs estimated - 18 actual

Would you not then say the velocity as 78 (average of the 3 actuals,
26 * 3), and maybe schedule 70-75 hrs next iteration, or is it just
60. I am having a difficult time explaining this to our project
manager to understand why actuals don't equal velocity -- or should
they? In Mike Cohn's book it seems to indicate velocity is based on
historical estimates, not the actuals.

-Nick
• In my opinion, velocity is a measure that is used in two ways: finding the approximate size of the chunk that can be done in the next sprint and providing high
Message 6 of 19 , Aug 2, 2006
• 0 Attachment
In my opinion, velocity is a measure that is used in two ways: finding the
approximate size of the chunk that can be done in the next sprint and
providing high level predictions of when a product can reach a certain set
functionality with given resources (for whom a velocity has been
established). Considering this and the fact that estimations in hours should
only (if at all) be used within a sprint when the team starts planning the
actual sprint, I'd say that using hours in velocity is probably not very
useful.
From personal experience I would advise against using hours at all. It took
me some time to convince our PO, but he now has come to realize that the
inner workings of a team within a sprint are actually not important to him,
because he can rely on the fact that at the end of the sprint he will
usually get what the team promised. In consequence we have dropped the
estimation of tasks in hours (it was just wasting time and therefore
eliminated). We estimate our stories in an abstract size unit (similar to
the T-shirt sizes mentioned by Chris Sterling in another post, except we
have more sizes) which considers complexity, risk, duration, domain
knowledge and ideal developer time. The accuracy is surprisingly high (after
some sprints) and it is fast.

IMO velocity should be calculated as a floating average over the last couple
of sprints from the size units (gummi-bears, T-shorts, ...) of actual
results delivered.

Regards,

Wolfgang

> -----Original Message-----
> From: scrumdevelopment@yahoogroups.com
> [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of
> Nicholas Cancelliere
> Sent: 02 August 2006 01:15
> To: scrumdevelopment@yahoogroups.com
> Subject: [scrumdevelopment] Velocity - Estimate or Actuals?
>
>
> I've read that velocity is calculated using historical
> estimates (what the team estimated and committed to) vs. the
> actuals a team did. An example (condensed for easy math):
>
> 5 day iteration, three developers are expected to burn 5 hrs
> a day (the other 3 hrs are slop/buffer for email, meetings,
> etc - last day), there are 3 stories (for each developer).
>
> Story 1 - 20 hrs estimated - 22 actual
> Story 2 - 20 hrs estimated - 38 actual
> Story 3 - 20 hrs estimated - 18 actual
>
> Would you not then say the velocity as 78 (average of the 3 actuals,
> 26 * 3), and maybe schedule 70-75 hrs next iteration, or is
> it just 60. I am having a difficult time explaining this to
> our project manager to understand why actuals don't equal
> velocity -- or should they? In Mike Cohn's book it seems to
> indicate velocity is based on historical estimates, not the actuals.
>
> -Nick
>
>
>
>
>
• Hello Nicholas, Thanks for your email. On Tuesday, August 1, 2006, at 8:15:03 PM, ... We accomplished 60 hours estimated this past iteration. Since we have no
Message 7 of 19 , Aug 2, 2006
• 0 Attachment
Hello Nicholas,

Thanks for your email. On Tuesday, August 1, 2006, at 8:15:03 PM,
you wrote:

> I've read that velocity is calculated using historical estimates
> (what the team estimated and committed to) vs. the actuals a team
> did. An example (condensed for easy math):

> 5 day iteration, three developers are expected to burn 5 hrs a day
> (the other 3 hrs are slop/buffer for email, meetings, etc - last
> day), there are 3 stories (for each developer).

> Story 1 - 20 hrs estimated - 22 actual
> Story 2 - 20 hrs estimated - 38 actual
> Story 3 - 20 hrs estimated - 18 actual

> Would you not then say the velocity as 78 (average of the 3 actuals,
> 26 * 3), and maybe schedule 70-75 hrs next iteration, or is it just
> 60. I am having a difficult time explaining this to our project
> manager to understand why actuals don't equal velocity -- or should
> they? In Mike Cohn's book it seems to indicate velocity is based on
> historical estimates, not the actuals.

We accomplished 60 hours estimated this past iteration. Since we
have no reason to believe that our estimation will be any better
next iteration, we should probably expect to do 60 hours estimated
next time, and that it would again take about 78 hours. (By the way,
a somewhat more efficient way to get 78 is to add up the actuals,
not add them up, divide by three, and multiply by three. ;->)

However, if I recall what the Scrum literature actually says, it is
that the team should look at the work to be done and commit to it.
IMO, blind reliance on these numbers is not as strong as looking
each other in the eye and deciding to accomplish what's on the
board.

Ron Jeffries
www.XProgramming.com
Fatalism is born of the fear of failure, for we all believe that we carry
success in our own hands, and we suspect that our hands are weak. -- Conrad
• (responding to Nick) Let me take a shot at this one from a differnt angle... ... Suppose we were estimating in story points and had estimated these each as 3
Message 8 of 19 , Aug 2, 2006
• 0 Attachment
(responding to Nick)

Let me take a shot at this one from a differnt angle...

> 5 day iteration, three developers are expected to burn 5 hrs a
day
> (the other 3 hrs are slop/buffer for email, meetings, etc -
last
> day), there are 3 stories (for each
developer).
>
> Story 1 - 20 hrs estimated - 22 actual
> Story
2 - 20 hrs estimated - 38 actual
> Story 3 - 20 hrs estimated - 18
actual

Suppose we were estimating in story points and had estimated
these each as 3 story points.  This is an arbitrary number
that somewhere in the back of our minds we may think
would normally take 20 hours.

Suppose we had the capacity for 80 hours work per iteration.

We may have expected to complete 12 story points worth
of work for the iteration, but actually we only completed 9.

Going forward, what do we know at this time?
- we know that 1 of our 3 point stories should have been a
6 point story.
- we know some of our 3 point story estimates were correct.
- we know there's a possibility of more of our estimates
being incorrect.
- we know that our current best guess of these inaccuracies
is that 1 in 3 of our stories should have its estimate doubled.

Given that information, our best estimate of what we will be
able to attain next iteration is 9 story points.

We now have a choice.

We know a bit more about where our estimates are wrong,
so we could try and re-estimate everything.  But if we do
this, what velocity should we use?  It could be anything
between 9 and 12.  Sometimes it's worth doing; sometimes
not.

Alternatively we could say that we can live with the uncertainty
and carry on using 9 as our velocity.  This need not be as
bad as we might think, because our new knowledge on estimating
can be folded in to planning of the sprint.  We may choose,
at that time, to commit to more than 9 story points because,
given our current knowledge, the team believes it can commit
to them and deliver them this iteration.  The sprint planning
is the fine control, achieved primarily by what the team feel
they can commit to.  That's what really matters.

Paul Oldfield
• Hi Nick, I am the patent holder on Velocity calcualtion in software development prediction. The key is to measure thing like complexity and effort or each
Message 9 of 19 , Aug 2, 2006
• 0 Attachment
Hi Nick,

I am the patent holder on Velocity calcualtion in software development prediction.  The key is to measure thing like complexity and effort or each small interation and than to start charting that data, after a few interations you will be able to determine which coder is moving at which speed.  That is certainly helpful, but beyond that you need to account for those random happening like power outage, stuck in traffic and the like, that is where overall group snap shots make it work a lot better and finally, you need to gather the metric from raw code, not just swags from the staff.  Keep the creative staff free to create and have management mine and chart the progress data.  I am really happy to see interest in the question.

Best,

Cliff

----- Original Message ----
From: Nicholas Cancelliere <nicholas@...>
To: scrumdevelopment@yahoogroups.com
Sent: Tuesday, August 1, 2006 7:49:03 PM
Subject: Re: [scrumdevelopment] Velocity - Estimate or Actuals?

I think you hit it on the nose.  I'd guess that when the PM hears the word "velocity" she's naturally thinking in terms of speed and how much work the team is able to process.  The subtle difference is the idea of the team's ability to demonstrate predict and deliver stories.  I'll try to explain it in this way and see how that goes over.

The example was made up to demonstrate the point, but yeah if there was a 38 I'd want to know what went wrong there in the estimate.

On Aug 1, 2006, at 8:24 PM, William Wake wrote:

On 8/1/06, Nicholas Cancelliere <nicholas@ozmox.com> wrote:
> I've read that velocity is calculated using historical estimates
> (what the team estimated and committed to) vs. the actuals a team
> did. An example (condensed for easy math):
>
> 5 day iteration, three developers are expected to burn 5 hrs a day
> (the other 3 hrs are slop/buffer for email, meetings, etc - last
> day), there are 3 stories (for each developer).
>
> Story 1 - 20 hrs estimated - 22 actual
> Story 2 - 20 hrs estimated - 38 actual
> Story 3 - 20 hrs estimated - 18 actual
>
> Would you not then say the velocity as 78 (average of the 3 actuals,
> 26 * 3), and maybe schedule 70-75 hrs next iteration, or is it just
> 60. I am having a difficult time explaining this to our project
> manager to understand why actuals don't equal velocity -- or should
> they? In Mike Cohn's book it seems to indicate velocity is based on
> historical estimates, not the actuals.

I use historical estimates (but I do try to get better estimates). I
look at velocity as, "what is the team's demonstrated ability to
predict and deliver stories?"

In the case at hand, it seems to me like you're talking about going
exactly the wrong direction. You tried to schedule 60 hours work, but
it ended up as 78 (~30% over the prediction). For you to actually
schedule 60 hours work, it seems you should have planned ~45 hours.

(In this case, it looks like 2 stories were close to their estimate,
one was way over. I'd want to understand what happened there. Is it
something that's going to affect a certain class of story?)

What I'd do:
- re-estimate the remaining stories in light of what I learned this time
- estimate 60 as my velocity for next iteration.
- deliver those 60 and expect/hope to ask for more stories (raising

(We expect to do more, as we believe our estimates are now more accurate.)

I prefer to let velocity be a "trailing" indicator in this sense, as a
measure of our *demonstrated* ability to deliver.

--
Bill Wake William.Wake@acm.org

• That makes sense. (The bit about the average -- the reason I say 26 * 3 ... is because the assumption is that instead of each developer doing 20 pts, they
Message 10 of 19 , Aug 2, 2006
• 0 Attachment

That makes sense.

(The bit about the average -- the reason I say 26 * 3 ... is because the assumption is that instead of each developer doing 20 pts, they might do 25.  We generally assign each developer X pts - so if the team has 4 members it'd be able to do 100 pts of work.  If the team adds a member we say it can do 125 pts, and if it looses one 75, etc.  Granted, it's just a guess - but when a team has a resource added we need a starting point for the velocity -- of course over time the new team makeup we might find it changes)

On Aug 2, 2006, at 4:16 AM, Ron Jeffries wrote:

We accomplished 60 hours estimated this past iteration. Since we
have no reason to believe that our estimation will be any better
next iteration, we should probably expect to do 60 hours estimated
next time, and that it would again take about 78 hours. (By the way,
a somewhat more efficient way to get 78 is to add up the actuals,
not add them up, divide by three, and multiply by three. ;->)

However, if I recall what the Scrum literature actually says, it is
that the team should look at the work to be done and commit to it.
IMO, blind reliance on these numbers is not as strong as looking
each other in the eye and deciding to accomplish what's on the
board.

Ron Jeffries
www.XProgramming.com
Fatalism is born of the fear of failure, for we all believe that we carry
success in our own hands, and we suspect that our hands are weak. -- Conrad

• Hello Nicholas, Thank you for your email. On Wednesday, August 2, 2006, at 8:09:19 ... Numerology, mostly, it seems to me. Ron Jeffries www.XProgramming.com I
Message 11 of 19 , Aug 2, 2006
• 0 Attachment
Hello Nicholas,

Thank you for your email. On Wednesday, August 2, 2006, at 8:09:19
AM, you wrote:

> (The bit about the average -- the reason I say 26 * 3 ... is because
> the assumption is that instead of each developer doing 20 pts, they
> might do 25. We generally assign each developer X pts - so if the
> team has 4 members it'd be able to do 100 pts of work. If the team
> adds a member we say it can do 125 pts, and if it looses one 75,
> etc. Granted, it's just a guess - but when a team has a resource
> added we need a starting point for the velocity -- of course over
> time the new team makeup we might find it changes)

Numerology, mostly, it seems to me.

Ron Jeffries
www.XProgramming.com
I could be wrong, of course. It's just not the way to bet.
• ... Cliff, I apologize for ripping you off for years now. I had been assuming Velocity was public domain since so many different people have been presenting
Message 12 of 19 , Aug 2, 2006
• 0 Attachment
On 8/2/06, Clifford Gregory <cliff_gregory@...> wrote:
>
> Hi Nick,
>
> I am the patent holder on Velocity calcualtion in software development
> prediction.

Cliff,

I apologize for ripping you off for years now. I had been assuming
Velocity was public domain since so many different people have been

BTW, what is the number for that patent?

Regards,

Steve
• ... Searching US Patents Text Collection... Results of Search in US Patents Text Collection db for: IN/Clifford-Gregory: 0 patents. No patents have matched
Message 13 of 19 , Aug 2, 2006
• 0 Attachment
On 02/08/06, Steven Gordon <sgordonphd@...> wrote:
> On 8/2/06, Clifford Gregory <cliff_gregory@...> wrote:
> >
> > Hi Nick,
> >
> > I am the patent holder on Velocity calcualtion in software development
> > prediction.
>
> Cliff,
>
> I apologize for ripping you off for years now. I had been assuming
> Velocity was public domain since so many different people have been
> presenting the idea without attribution.
>
> BTW, what is the number for that patent?
>
Searching US Patents Text Collection...

Results of Search in US Patents Text Collection db for:
IN/Clifford-Gregory: 0 patents.

No patents have matched your query

We need you real name man Clifford :)

--
Sent from gmail so do not trust this communication.
Do not send me sensitive information here, ask for my none-gmail accounts.

"Therefore the considerations of the intelligent always include both
benefit and harm." - Sun Tzu
• Hello Steven, Thank you for your ideas. On Wednesday, August 2, 2006, at 9:31:10 ... And the date? There may be prior art. ;- Ron Jeffries
Message 14 of 19 , Aug 2, 2006
• 0 Attachment
Hello Steven,

Thank you for your ideas. On Wednesday, August 2, 2006, at 9:31:10
AM, you wrote:

> I apologize for ripping you off for years now. I had been assuming
> Velocity was public domain since so many different people have been
> presenting the idea without attribution.

> BTW, what is the number for that patent?

And the date? There may be prior art. ;->

Ron Jeffries
www.XProgramming.com
One test is worth a thousand expert opinions.
-- Bill Nye (The Science Guy)
• How would you adjust a velocity of a team then if you added say 2 developers - if not by looking at the current velocity and trying to determine the average
Message 15 of 19 , Aug 2, 2006
• 0 Attachment

How would you adjust a velocity of a team then if you added say 2 developers - if not by looking at the current velocity and trying to determine the average per developer and then apply that to the new resources?  Would you just go forward with the same velocity as last sprint, or make a guess based on what the average per dev was, or just guess without any historical data?

Nick

On Aug 2, 2006, at 7:30 AM, Ron Jeffries wrote:

Hello Nicholas,

Thank you for your email. On Wednesday, August 2, 2006, at 8:09:19
AM, you wrote:

> (The bit about the average -- the reason I say 26 * 3 ... is because
> the assumption is that instead of each developer doing 20 pts, they
> might do 25. We generally assign each developer X pts - so if the
> team has 4 members it'd be able to do 100 pts of work. If the team
> adds a member we say it can do 125 pts, and if it looses one 75,
> etc. Granted, it's just a guess - but when a team has a resource
> added we need a starting point for the velocity -- of course over
> time the new team makeup we might find it changes)

Numerology, mostly, it seems to me.

Ron Jeffries
www.XProgramming.com
I could be wrong, of course. It's just not the way to bet.

• Since adding new folks to the team often results in an immediate *loss* of overall productivity until the new folks get ramped up, I d tend to not adjust the
Message 16 of 19 , Aug 2, 2006
• 0 Attachment
Since adding new folks to the team often results in an immediate *loss* of overall productivity until the new folks get ramped up, I'd tend to not adjust the velocity and give it a couple of sprints and observe what happens. I certainly wouldn't make any committents around a projected new velocity until I saw what it actually was empirically.

-Jeff H.

From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Nicholas Cancelliere
Sent: Wednesday, August 02, 2006 12:54 PM
To: scrumdevelopment@yahoogroups.com
Subject: Re: [scrumdevelopment] Velocity - Estimate or Actuals?

How would you adjust a velocity of a team then if you added say 2 developers - if not by looking at the current velocity and trying to determine the average per developer and then apply that to the new resources?  Would you just go forward with the same velocity as last sprint, or make a guess based on what the average per dev was, or just guess without any historical data?

Nick

On Aug 2, 2006, at 7:30 AM, Ron Jeffries wrote:

Hello Nicholas,

Thank you for your email. On Wednesday, August 2, 2006, at 8:09:19
AM, you wrote:

> (The bit about the average -- the reason I say 26 * 3 ... is because
> the assumption is that instead of each developer doing 20 pts, they
> might do 25. We generally assign each developer X pts - so if the
> team has 4 members it'd be able to do 100 pts of work. If the team
> adds a member we say it can do 125 pts, and if it looses one 75,
> etc. Granted, it's just a guess - but when a team has a resource
> added we need a starting point for the velocity -- of course over
> time the new team makeup we might find it changes)

Numerology, mostly, it seems to me.

Ron Jeffries
www.XProgramming. com
I could be wrong, of course. It's just not the way to bet.

• ... I think the key point is that the team wouldn t make a commitment to any sprint, even with a constant number of people, based on velocity numbers. They
Message 17 of 19 , Aug 2, 2006
• 0 Attachment

> How would you adjust a velocity of a team then if you added
> say 2 developers - if not by looking at the current velocity
> and trying to determine the average per developer and then
> apply that to the new resources? Would you just go forward
> with the same velocity as last sprint, or make a guess based
> on what the average per dev was, or just guess without any
> historical data?

I think the key point is that the team wouldn't make a
commitment to any sprint, even with a constant number of
people, based on velocity numbers. They sit down together,
look at the stories on the top of the backlog, discuss how
they see things playing out, and then commit to what they
think they can get done with whatever level of "certainty"
they and the organization are looking for. IMHO, it's all
too easy to try to make it a "data-driven" process, but it's
not.

When changing the team makeup, all bets are off on the next
sprint's velocity. It probably won't go up in some proportion
to what the previous team makeup was doing. In a lot of cases,
it goes down while incorporating the new team members. I
don't think any magic velocity adjustment calculations will
help more than the team sitting down together and figuring out
what they think they can accomplish with the new team makeup.

the velocity. I'd let the team commit for the next sprint,
and then see what actually happened.

If everything is in a stable state (the team makeup, the
context and environment, as well as the estimates on the
stories), we can use the historical velocity as an average
guess for longer-term planning, with some appropriate error
bar, and tempered by our judgement and common sense. Sprint
by sprint, I'd expect the velocity to be close, but in my
experience it still flutters around a bit due to all the
variables involved.

Paul
-----
Paul Hodgetts -- CEO, Coach, Trainer, Consultant
Agile Logic -- www.agilelogic.com
Training, Coaching, Consulting -- Agile Processes/Scrum/Lean/XP
Complete solutions for adopting agile processes, Scrum and XP.
• I consider it a complement to use this data, and not a rip off. Here is the notice, and as you can see it was issued Dec 29 of 2005. It was written almost 3
Message 18 of 19 , Aug 7, 2006
• 0 Attachment
I consider it a complement to use this data, and not a rip off.  Here is the notice, and as you can see it was issued Dec 29 of 2005.  It was written almost 3 or 4 years before, but those guys are slow.  The term "velocity" is not the real subject it is the graphs and calculations.

Best,

Cliff
"Cliff,

This is to inform you that the U.S. utility patent application for the project velocity development was published on December 29, 2005 as Publication No. US-2005-0289503-A1.  The direct link to access the published application is http://www.uspto.gov/patft/
Best regards,

Bill"

----- Original Message ----
From: David H. <dmalloc@...>
To: scrumdevelopment@yahoogroups.com
Sent: Wednesday, August 2, 2006 6:48:19 AM
Subject: Re: [scrumdevelopment] Velocity - Estimate or Actuals?

On 02/08/06, Steven Gordon <sgordonphd@gmail. com> wrote:
> On 8/2/06, Clifford Gregory <cliff_gregory@ yahoo.com> wrote:
> >
> > Hi Nick,
> >
> > I am the patent holder on Velocity calcualtion in software development
> > prediction.
>
> Cliff,
>
> I apologize for ripping you off for years now. I had been assuming
> Velocity was public domain since so many different people have been
> presenting the idea without attribution.
>
> BTW, what is the number for that patent?
>
Searching US Patents Text Collection.. .

Results of Search in US Patents Text Collection db for:
IN/Clifford- Gregory: 0 patents.

No patents have matched your query

We need you real name man Clifford :)

--
Sent from gmail so do not trust this communication.
Do not send me sensitive information here, ask for my none-gmail accounts.

"Therefore the considerations of the intelligent always include both
benefit and harm." - Sun Tzu

Your message has been successfully submitted and would be delivered to recipients shortly.