## RE: [XP] average velocity?

Expand Messages
• Hi Jeff, ... Are you implying that there are folks other than the team itself who are deciding on the velocity to use in planning? If so, I d suggest this is a
Message 1 of 25 , May 2 9:22 AM
Hi Jeff,

> I'm looking for thoughts about the use of a velocity
> *average* to establish a limit for iteration planning. I've
> always promoted yesterday's weather (points completed last
> iteration = points tackled this iteration). We have a few
> people here who like calculation average across all
> iterations and use that as a basis for planning.
> They also look to inject some level of "intelligence," such
> as adjusting for absence and/or new resources.

Are you implying that there are folks other than the team itself
who are deciding on the velocity to use in planning? If so,
I'd suggest this is a bad idea. The most important thing about
the number of points to be placed in an iteration is that the
it be a number the team has committed to.

Charlie
• ... Been there, done that. No one really believed the results. Far better, in my opinion, to look each other in the eye, look at the list of what s to do, and
Message 2 of 25 , May 2 10:09 AM
Hello, Jeff. On Wednesday, May 2, 2007, at 11:52:04 AM, you wrote:

> I'm looking for thoughts about the use of a velocity *average* to
> establish a limit for iteration planning. I've always promoted
> yesterday's weather (points completed last iteration = points tackled
> this iteration). We have a few people here who like calculation
> average across all iterations and use that as a basis for planning.
> They also look to inject some level of "intelligence," such as
> adjusting for absence and/or new resources.

Been there, done that. No one really believed the results. Far
better, in my opinion, to look each other in the eye, look at the
list of what's to do, and commit, as a team, to do it.

Ron Jeffries
www.XProgramming.com
--Gunnery Sergeant Tom Highway (Heartbreak Ridge)
• ... Ron, how could you possibly suggest that I commit to my team to get something done. I
Message 3 of 25 , May 2 11:35 AM
Quoting Ron Jeffries <ronjeffries@...>:

> Hello, Jeff. On Wednesday, May 2, 2007, at 11:52:04 AM, you wrote:
>
>> I'm looking for thoughts about the use of a velocity *average* to
>> establish a limit for iteration planning. I've always promoted
>> yesterday's weather (points completed last iteration = points tackled
>> this iteration). We have a few people here who like calculation
>> average across all iterations and use that as a basis for planning.
>> They also look to inject some level of "intelligence," such as
>> adjusting for absence and/or new resources.
>
> Been there, done that. No one really believed the results. Far
> better, in my opinion, to look each other in the eye, look at the
> list of what's to do, and commit, as a team, to do it.

<sarcasm mode="dripping" tone="whiny" volume="loud" duration="long">
Ron, how could you possibly suggest that I commit to my team to get
something done. I want to do, whatever I want to do, whenever I want
to do it, any way I want to do it. Those stories aren't the most
important thing right now anyhow. I just found this new tool that is
so cool. I have to find a way to use it in all of our applications.
And besides, there are a kazillion reasons why I might not be able to
get that stuff done. The only sure way for us to get those stories
done, is to buckle down, follow the team practices, and get to work.
You can't really, seriously, expect us to do *that*, can you. This is
really just another sinister management plot intended to force us to
do some work, isn't it? Come on Ron, admit it! You're trying to
impose responsibility and accountability on us. Management around
here is so stupid. They just don't get it. We're a self-directed team!
</sarcasm>

8^)

GB.
• Hi Charlie, Thanks for the response. ... I m interacting with a large number of teams, each deciding their own velocity, so no, to answer your question.
Message 4 of 25 , May 2 12:12 PM
Hi Charlie,

Thanks for the response.

Quoting Charlie Poole <xp@...>:
> Are you implying that there are folks other than the team itself
> who are deciding on the velocity to use in planning? If so,
> I'd suggest this is a bad idea. The most important thing about
> the number of points to be placed in an iteration is that the
> it be a number the team has committed to.

I'm interacting with a large number of teams, each deciding their own

thanks,
Jeff
• Greetings Ron, ... Hm. Are you suggesting that we dispense with the concept of velocity completely? thanks, Jeff
Message 5 of 25 , May 2 1:15 PM
Greetings Ron,

Quoting Ron Jeffries <ronjeffries@...>:
> Been there, done that. No one really believed the results. Far
> better, in my opinion, to look each other in the eye, look at the
> list of what's to do, and commit, as a team, to do it.

Hm. Are you suggesting that we dispense with the concept of "velocity"
completely?

thanks,
Jeff
• Greetings Gary, ... Thanks for the response! I agree with not worrying about one-day or unplanned absences. Sounds good. I haven t seen the 3-week average
Message 6 of 25 , May 2 1:18 PM
Greetings Gary,

Quoting Gary Brown <glbrown@...>:
> We use each team's rolling three week average velocity to set their
> expected velocity for planning purposes. We do adjust for planned
> absences, like training, conferences, and vacation. We don't adjust
> for unplanned absences that happen mid-iteration. In an organization
> of our size, a few people are always missing, so that lost velocity
> washes out in the rolling average.

Thanks for the response! I agree with not worrying about one-day or
unplanned absences. Sounds good. I haven't seen the 3-week average used.

Jeff
http://langrsoft.com/agileJava
• ... African, or European? (For those not sure: http://www.mwscomp.com/movies/grail/grail-23.htm) -- Cory Foy http://www.cornetdesign.com
Message 7 of 25 , May 2 1:24 PM
Jeff Langr wrote:
> I'm looking for thoughts about the use of a velocity *average* to
> establish a limit for iteration planning.

African, or European?

(For those not sure: http://www.mwscomp.com/movies/grail/grail-23.htm)

--
Cory Foy
http://www.cornetdesign.com
• Greetings David, ... Thanks for the response! So, it s certainly clear from the four responses, each offering a different solution, that there is no hard
Message 8 of 25 , May 2 1:26 PM
Greetings David,

Quoting "David H." <dmalloc@...>:
> I like ranges. Look at the worst velocity, look at the best velocity,
> then make an educated guess and a good pick somewhere in that range.

Thanks for the response!

So, it's certainly clear from the four responses, each offering a
different solution, that there is no hard definition to how to apply
notions of velocity to future planning. I think one could come up with
potential problems that any application of velocity (or not) can
cause, whether they be political, motivational, or whatever.

The takeaway would seem to be to do what works best, and fix it when
it doesn't. I've had good experience with yesterday's weather, but I'm
not married to it. I *am* trying to challenge the notion that there is
one true way.

Jeff
http://langrsoft.com/agileJava
• ... No. Ron Jeffries www.XProgramming.com The model that really matters is the one that people have in their minds. All other models and documentation exist
Message 9 of 25 , May 2 1:38 PM
Hello, Jeff. On Wednesday, May 2, 2007, at 4:15:59 PM, you wrote:

> Quoting Ron Jeffries <ronjeffries@...>:
>> Been there, done that. No one really believed the results. Far
>> better, in my opinion, to look each other in the eye, look at the
>> list of what's to do, and commit, as a team, to do it.

> Hm. Are you suggesting that we dispense with the concept of "velocity"
> completely?

No.

Ron Jeffries
www.XProgramming.com
The model that really matters is the one that people have in
their minds. All other models and documentation exist only to
get the right model into the right mind at the right time.
-- Paul Oldfield
• Hi Ron, ... Hm, ok thanks. Are you suggesting that we dispense with the concept of velocity for purposes of establishing a limit to commitment for an
Message 10 of 25 , May 2 1:50 PM
Hi Ron,

Quoting Ron Jeffries <ronjeffries@...>:
>> Hm. Are you suggesting that we dispense with the concept of "velocity"
>> completely?
>
> No.

Hm, ok thanks. Are you suggesting that we dispense with the concept of
velocity for purposes of establishing a limit to commitment for an
iteration?

thanks,
Jeff
• ... I think it s worth considering. Velocity (i.e. number of stories done) is probably useful for predicting releases and for deciding how to manage scope. Ron
Message 11 of 25 , May 2 1:56 PM
Hello, Jeff. On Wednesday, May 2, 2007, at 4:50:13 PM, you wrote:

> Quoting Ron Jeffries <ronjeffries@...>:
>>> Hm. Are you suggesting that we dispense with the concept of "velocity"
>>> completely?
>>
>> No.

> Hm, ok thanks. Are you suggesting that we dispense with the concept of
> velocity for purposes of establishing a limit to commitment for an
> iteration?

I think it's worth considering. Velocity (i.e. number of stories
done) is probably useful for predicting releases and for deciding
how to manage scope.

Ron Jeffries
www.XProgramming.com
It is not because things are difficult that we do not dare,
it is because we do not dare that they are difficult. --Seneca
• ... I don t like velocity as a tool for commitment because, among other things, velocity is an average: you should be embarrassed if you don t meet your
Message 12 of 25 , May 2 2:18 PM
On Wed, 2 May 2007 16:56:49 -0400, Ron Jeffries <ronjeffries@...> said:
> Hello, Jeff. On Wednesday, May 2, 2007, at 4:50:13 PM, you wrote:

>> Hm, ok thanks. Are you suggesting that we dispense with the concept of
>> velocity for purposes of establishing a limit to commitment for an
>> iteration?

> I think it's worth considering. Velocity (i.e. number of stories
> done) is probably useful for predicting releases and for deciding
> how to manage scope.

I don't like velocity as a tool for commitment because, among other
things, velocity is an average: you should be embarrassed if you don't
meet your commitments, while you should expect to be below average
half the time.

It's not clear to me in what circumstances you need commitments to
delivering specific features during an iteration. (As opposed to
committing to do your best, knowing that sometimes you'll overdeliver
and sometimes you'll underdeliver.) If I were asked to do so, I
imagine that I'd commit to something closer to half the velocity than
the full velocity. Doubtless we're less consistent than is ideal, but
everybody has some variability.

This is all related to something I'm dealing with at work right now:
just what roadmap promises should we make to our external customers
over the next N months?

David Carlton
carlton@...
• ... In my organization, the problem with variance in velocity is mostly (~80%) due to large stories (greater than 4 units in our case) and our failure to write
Message 13 of 25 , May 2 2:45 PM
Quoting David Carlton <carlton@...>:

> On Wed, 2 May 2007 16:56:49 -0400, Ron Jeffries
> <ronjeffries@...> said:
>> Hello, Jeff. On Wednesday, May 2, 2007, at 4:50:13 PM, you wrote:
>
>>> Hm, ok thanks. Are you suggesting that we dispense with the concept of
>>> velocity for purposes of establishing a limit to commitment for an
>>> iteration?
>
>> I think it's worth considering. Velocity (i.e. number of stories
>> done) is probably useful for predicting releases and for deciding
>> how to manage scope.
>
> I don't like velocity as a tool for commitment because, among other
> things, velocity is an average: you should be embarrassed if you don't
> meet your commitments, while you should expect to be below average
> half the time.
>
> It's not clear to me in what circumstances you need commitments to
> delivering specific features during an iteration. (As opposed to
> committing to do your best, knowing that sometimes you'll overdeliver
> and sometimes you'll underdeliver.) If I were asked to do so, I
> imagine that I'd commit to something closer to half the velocity than
> the full velocity. Doubtless we're less consistent than is ideal, but
> everybody has some variability.
>
> This is all related to something I'm dealing with at work right now:
> just what roadmap promises should we make to our external customers
> over the next N months?
>
> David Carlton

In my organization, the problem with variance in velocity is mostly
(~80%) due to large stories (greater than 4 units in our case) and our
failure to write our stories as vertical slices. We have been
emphasizing these two ideas over the last three months, and we have
seen a calming of our velocity fluctuations.

GB.
• ... Yeah, we went through exactly the same problem a couple of years ago. It s played a role in our recent problems, but they ve also had other causes: a team
Message 14 of 25 , May 2 3:08 PM
On Wed, 02 May 2007 16:45:50 -0500, Gary Brown <glbrown@...> said:
> Quoting David Carlton <carlton@...>:

>> If I were asked to do so, I imagine that I'd commit to something
>> closer to half the velocity than the full velocity. Doubtless
>> we're less consistent than is ideal, but everybody has some
>> variability.

> In my organization, the problem with variance in velocity is mostly
> (~80%) due to large stories (greater than 4 units in our case) and our
> failure to write our stories as vertical slices. We have been
> emphasizing these two ideas over the last three months, and we have
> seen a calming of our velocity fluctuations.

Yeah, we went through exactly the same problem a couple of years ago.
It's played a role in our recent problems, but they've also had other
causes: a team merger with legacy code played a role (it's amazing how
long it can take to get out from under 25 red bars!); and we didn't
have real customers for a while, and were hence fooling ourselves

Fortunately, there are signs of improvement on both the recent fronts
(if you're in the market for a honking big video server, go to
<http://www.sun.com/servers/networking/streamingsystem/>), as well as
on the small vertical slice issue that you mention, and our velocity
this month has been much smoother than in the past. So I'm
optimistic.

David Carlton
carlton@...
• ... This is the approach that Mike Cohn, who has devoted a lot of energy to this topic, advocates. He is more of a Scrum guy than an XP guy, but his
Message 15 of 25 , May 2 4:47 PM
On 5/2/07, Ron Jeffries <ronjeffries@...> wrote:
>
>
>
>
>
>
> Hello, Jeff. On Wednesday, May 2, 2007, at 4:50:13 PM, you wrote:
>
> > Quoting Ron Jeffries <ronjeffries@...>:
> >>> Hm. Are you suggesting that we dispense with the concept of "velocity"
> >>> completely?
> >>
> >> No.
>
> > Hm, ok thanks. Are you suggesting that we dispense with the concept of
> > velocity for purposes of establishing a limit to commitment for an
> > iteration?
>
> I think it's worth considering. Velocity (i.e. number of stories
> done) is probably useful for predicting releases and for deciding
> how to manage scope.
>

This is the approach that Mike Cohn, who has devoted a lot of energy
to this topic, advocates. He is more of a Scrum guy than an XP guy,
but his information is valuable. I attended one of his "Agile
Estimating and Planning" courses in Santa Clara, CA last year and
found it quite informative.

Specifically, Mike advocates using an average, most recent, and lowest
historical velocity to establish a range. He then uses this range to
estimate how many stories will likely be done by a certain date,
and/or when a particular collection of stories will be complete. This
is used only for "big picture" and release planning. What stories will
be attempted in an iteration is purely a function of what the team
agrees to.

It's probably worthwhile to take a look at his book:
http://www.amazon.com/Agile-Estimating-Planning-Robert-Martin/dp/0131479415
• For what it s worth, we work from an 8w rolling average. It s a very consistent number. The final iteration meeting adjustment tends to be whether to round
Message 16 of 25 , May 2 8:45 PM
For what it's worth, we work from an 8w rolling average. It's a very
consistent number. The final iteration meeting adjustment tends to be
whether to round up or down.

What we don't like about the literal yesterday's weather, is if the 8w
average is 12, but last week we had major road blocks and achieved 5, 5
makes no sense for next week. Similarly, if some things were easier than
expected and we achieve 19, I don't want to commit to that.

Possibly, with experience you really don't need to measure the average,
because if you see 11, 10, 14, 12, 5, 12, 11, 12, you can make an educated
guess at 11 or 12 without the actual average. I just think it's an easy
number to calculate that it doesn't hurt.

We also don't worry about unplanned absences, but even for planned ones, we
never adjust the rounded average (up or down) more than +/- 1.

rob.

From: extremeprogramming@yahoogroups.com
[mailto:extremeprogramming@yahoogroups.com] On Behalf Of Jeff Langr
Sent: Wednesday, May 02, 2007 2:19 PM
To: extremeprogramming@yahoogroups.com
Subject: Re: [XP] average velocity?

Greetings Gary,

>:
> We use each team's rolling three week average velocity to set their
> expected velocity for planning purposes. We do adjust for planned
> absences, like training, conferences, and vacation. We don't adjust
> for unplanned absences that happen mid-iteration. In an organization
> of our size, a few people are always missing, so that lost velocity
> washes out in the rolling average.

Thanks for the response! I agree with not worrying about one-day or
unplanned absences. Sounds good. I haven't seen the 3-week average used.

Jeff
http://langrsoft.com/agileJava

[Non-text portions of this message have been removed]
• We use the 8w avg for that too; to track where we are WRT plan. rob. From: extremeprogramming@yahoogroups.com [mailto:extremeprogramming@yahoogroups.com] On
Message 17 of 25 , May 2 8:47 PM
We use the 8w avg for that too; to track where we are WRT plan.

rob.

From: extremeprogramming@yahoogroups.com
[mailto:extremeprogramming@yahoogroups.com] On Behalf Of Ron Jeffries
Sent: Wednesday, May 02, 2007 2:57 PM
To: extremeprogramming@yahoogroups.com
Subject: Re: [XP] average velocity?

Hello, Jeff. On Wednesday, May 2, 2007, at 4:50:13 PM, you wrote:

> Quoting Ron Jeffries <ronjeffries@...
<mailto:ronjeffries%40XProgramming.com> >:
>>> Hm. Are you suggesting that we dispense with the concept of "velocity"
>>> completely?
>>
>> No.

> Hm, ok thanks. Are you suggesting that we dispense with the concept of
> velocity for purposes of establishing a limit to commitment for an
> iteration?

I think it's worth considering. Velocity (i.e. number of stories
done) is probably useful for predicting releases and for deciding
how to manage scope.

Ron Jeffries
www.XProgramming.com
It is not because things are difficult that we do not dare,
it is because we do not dare that they are difficult. --Seneca

[Non-text portions of this message have been removed]
• Do you have any variance numbers you can share? What was it then and now? Thanks. rob. From: extremeprogramming@yahoogroups.com
Message 18 of 25 , May 2 8:50 PM
Do you have any variance numbers you can share?

What was it then and now?

Thanks.

rob.

From: extremeprogramming@yahoogroups.com
[mailto:extremeprogramming@yahoogroups.com] On Behalf Of Gary Brown
Sent: Wednesday, May 02, 2007 3:46 PM
To: extremeprogramming@yahoogroups.com
Subject: Re: [XP] average velocity?

Quoting David Carlton <carlton@... <mailto:carlton%40bactrian.org>
>:

> On Wed, 2 May 2007 16:56:49 -0400, Ron Jeffries
> <ronjeffries@... <mailto:ronjeffries%40XProgramming.com> >
said:
>> Hello, Jeff. On Wednesday, May 2, 2007, at 4:50:13 PM, you wrote:
>
>>> Hm, ok thanks. Are you suggesting that we dispense with the concept of
>>> velocity for purposes of establishing a limit to commitment for an
>>> iteration?
>
>> I think it's worth considering. Velocity (i.e. number of stories
>> done) is probably useful for predicting releases and for deciding
>> how to manage scope.
>
> I don't like velocity as a tool for commitment because, among other
> things, velocity is an average: you should be embarrassed if you don't
> meet your commitments, while you should expect to be below average
> half the time.
>
> It's not clear to me in what circumstances you need commitments to
> delivering specific features during an iteration. (As opposed to
> committing to do your best, knowing that sometimes you'll overdeliver
> and sometimes you'll underdeliver.) If I were asked to do so, I
> imagine that I'd commit to something closer to half the velocity than
> the full velocity. Doubtless we're less consistent than is ideal, but
> everybody has some variability.
>
> This is all related to something I'm dealing with at work right now:
> just what roadmap promises should we make to our external customers
> over the next N months?
>
> David Carlton

In my organization, the problem with variance in velocity is mostly
(~80%) due to large stories (greater than 4 units in our case) and our
failure to write our stories as vertical slices. We have been
emphasizing these two ideas over the last three months, and we have
seen a calming of our velocity fluctuations.

GB.

[Non-text portions of this message have been removed]
• I track something very similar (and taken from Mike Cohn s book). I have a line graph that shows how our actual velocity hovers around / near our 8w average
Message 19 of 25 , May 2 8:56 PM
I track something very similar (and taken from Mike Cohn's book).

I have a line graph that shows how our actual velocity hovers around / near
our 8w average and rarely dips below the average of the worst 3 of the last
8 velocities.

rob.

From: extremeprogramming@yahoogroups.com
[mailto:extremeprogramming@yahoogroups.com] On Behalf Of Adam Sroka
Sent: Wednesday, May 02, 2007 5:48 PM
To: extremeprogramming@yahoogroups.com
Subject: Re: [XP] average velocity?

On 5/2/07, Ron Jeffries <ronjeffries@...
<mailto:ronjeffries%40xprogramming.com> > wrote:
>
>
>
>
>
>
> Hello, Jeff. On Wednesday, May 2, 2007, at 4:50:13 PM, you wrote:
>
> > Quoting Ron Jeffries <ronjeffries@...
<mailto:ronjeffries%40XProgramming.com> >:
> >>> Hm. Are you suggesting that we dispense with the concept of "velocity"
> >>> completely?
> >>
> >> No.
>
> > Hm, ok thanks. Are you suggesting that we dispense with the concept of
> > velocity for purposes of establishing a limit to commitment for an
> > iteration?
>
> I think it's worth considering. Velocity (i.e. number of stories
> done) is probably useful for predicting releases and for deciding
> how to manage scope.
>

This is the approach that Mike Cohn, who has devoted a lot of energy
to this topic, advocates. He is more of a Scrum guy than an XP guy,
but his information is valuable. I attended one of his "Agile
Estimating and Planning" courses in Santa Clara, CA last year and
found it quite informative.

Specifically, Mike advocates using an average, most recent, and lowest
historical velocity to establish a range. He then uses this range to
estimate how many stories will likely be done by a certain date,
and/or when a particular collection of stories will be complete. This
is used only for "big picture" and release planning. What stories will
be attempted in an iteration is purely a function of what the team
agrees to.

It's probably worthwhile to take a look at his book:
http://www.amazon.com/Agile-Estimating-Planning-Robert-Martin/dp/0131479415

[Non-text portions of this message have been removed]
• ... You ve gotten a good variety of answers, but let me add one more. For a team that s getting started or is having trouble, I usually insist on Yesterday s
Message 20 of 25 , May 2 10:20 PM
Jeff Langr wrote:
> I'm looking for thoughts about the use of a velocity *average* to
> establish a limit for iteration planning. I've always promoted
> yesterday's weather (points completed last iteration = points tackled
> this iteration). We have a few people here who like calculation
> average across all iterations and use that as a basis for planning.
> They also look to inject some level of "intelligence," such as
> adjusting for absence and/or new resources.
>

You've gotten a good variety of answers, but let me add one more.

For a team that's getting started or is having trouble, I usually insist
on Yesterday's Weather. I find it very valuable in keeping things
approximately sane.

For example, a lot of shops I've worked with have a culture of
unrealistic expectations, and left to their own devices would plan an
unrealistic iteration week after week. Because having every Friday be a
stressful failure is fun, apparently. Another good example is high
variability; if they are alternating velocities of 15 and 5, something
is going on. Planning for the low number gives breathing space to sort
out root problems, and I've never seen a team just loaf Thursday and
Friday rather than tackling debt or pulling something ahead.

Once a team regularly is completing what they set out to complete, I
don't care at all how they pick the next week's work. The ones I've seen
doing the best tend to use a variety of methods in harmony. They may
calculate a running average. They might adjust that number for special
circumstances. They'll sanity check the number against yesterday's
weather. And then they'll look at the work and do a gut check. And off
they go!

That said, for long-term planning, I feel a product manager should feel
free to use any method they can reasonably support from the data, and a
moving average is a good choice there. But people should be very careful
about letting the dreams of product managers influence the amount of
work a team is expected to take on. A little pressure can be a good
thing, but a lot of it can make a mess of the schedule.

Hoping that helps,

William

--
William Pietri - william@... - +1-415-643-1024
Agile consulting, coaching, and development: http://www.scissor.com/
A startup, done XP-style: http://www.sidereel.com/
• ... Worst case was +/- 100%, now we re at +/- 30%, heading for +/- 10%. GB.
Message 21 of 25 , May 3 4:23 AM
Quoting Rob Park <rpark68@...>:

> Do you have any variance numbers you can share?
>
> What was it then and now?

Worst case was +/- 100%, now we're at +/- 30%, heading for +/- 10%.

GB.
• ... The problem we ve had with product and project management is setting the delivery date. Before XP, we were like many shops, work on a six month project
Message 22 of 25 , May 3 4:59 AM
Quoting William Pietri <william@...>:

> Jeff Langr wrote:
>> I'm looking for thoughts about the use of a velocity *average* to
>> establish a limit for iteration planning. I've always promoted
>> yesterday's weather (points completed last iteration = points tackled
>> this iteration). We have a few people here who like calculation
>> average across all iterations and use that as a basis for planning.
>> They also look to inject some level of "intelligence," such as
>> adjusting for absence and/or new resources.
>>
>
> You've gotten a good variety of answers, but let me add one more.
>
> For a team that's getting started or is having trouble, I usually insist
> on Yesterday's Weather. I find it very valuable in keeping things
> approximately sane.
>
> For example, a lot of shops I've worked with have a culture of
> unrealistic expectations, and left to their own devices would plan an
> unrealistic iteration week after week. Because having every Friday be a
> stressful failure is fun, apparently. Another good example is high
> variability; if they are alternating velocities of 15 and 5, something
> is going on. Planning for the low number gives breathing space to sort
> out root problems, and I've never seen a team just loaf Thursday and
> Friday rather than tackling debt or pulling something ahead.
>
> Once a team regularly is completing what they set out to complete, I
> don't care at all how they pick the next week's work. The ones I've seen
> doing the best tend to use a variety of methods in harmony. They may
> calculate a running average. They might adjust that number for special
> circumstances. They'll sanity check the number against yesterday's
> weather. And then they'll look at the work and do a gut check. And off
> they go!
>
> That said, for long-term planning, I feel a product manager should feel
> free to use any method they can reasonably support from the data, and a
> moving average is a good choice there. But people should be very careful
> about letting the dreams of product managers influence the amount of
> work a team is expected to take on. A little pressure can be a good
> thing, but a lot of it can make a mess of the schedule.
>
> Hoping that helps,
>
> William

The problem we've had with product and project management is setting
the delivery date. Before XP, we were like many shops, work on a six
month project for four months, then announce that we needed four more
months. Work for three more months, then announce that we needed two
more months, etc.

After adopting XP, product and project management expected that we
would immediately begin estimating more accurately. On our early
projects, we would do an estimate, set an initial velocity, and
announce the expected delivery date, with the caveat that in three or
four weeks, we would provide a more accurate delivery date, based on
our demonstrated capacity to do work.

We sat through a lot of rather hostile meetings explaining that all
estimates are guesses, and that if they allow us to bring more facts
to the process, we'll get better guesses. After letting the process
play out a few times, we were able prove that our estimates were more
accurate. We haven't missed a delivery date in a couple of years.

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