How do you integrate actuals into future iterations and release plans?

Expand Messages
• Hi all, I would like to hear peoples comments with regards to how they are incorporating actual velocity measurements into their release plans. For example.
Message 1 of 6 , Jun 28, 2004
• 0 Attachment
Hi all,

I would like to hear peoples comments with regards to how
they are incorporating actual velocity measurements into their
release plans.

For example. Say we did our high level story planning and
estimated everything to take 1,3,5 Ideal Days (ID).

Then after 5 iterations, we discover, that based on our original
estimates, it actually takes twice as long (to be extreme). In
other words what we though could be done in 1 ID actually takes closer
to 2.

How would that change your estimates in future iterations?
Would you revise your estimates to more accurately reflect actual
velocity? (2 days instead of 1?)
Or would you continue estimating with the same relative measure you
used at the beginning of the project?

How would this affect your release plan?
Would you modify the high level estimates for all future stories?
Double them?
Or would you measure them relative to your original estimate and keep
them the same?

How do you incorporate actuals into your plans and how would you
explain it to customers?

Many thx,

Jonathan
• ... I /only/ incorporate actuals. And I don t necessarily use ideal days. When I do, I consider ideal days to be points, not a kind of day that rarely occurs.
Message 2 of 6 , Jun 28, 2004
• 0 Attachment
On Monday, June 28, 2004, at 4:35:41 PM, Jonathan Rasmusson wrote:

> I would like to hear peoples comments with regards to how
> they are incorporating actual velocity measurements into their
> release plans.

I /only/ incorporate actuals. And I don't necessarily use ideal days. When
I do, I consider ideal days to be points, not a kind of day that rarely
occurs.

> For example. Say we did our high level story planning and
> estimated everything to take 1,3,5 Ideal Days (ID).

> Then after 5 iterations, we discover, that based on our original
> estimates, it actually takes twice as long (to be extreme). In
> other words what we though could be done in 1 ID actually takes closer
> to 2.

Ideal days are not supposed to be what you thought you could do. The
definition of an Ideal Day is "if the B*st*rds would leave me alone, I
could do it in a day." I also refer to ideal days as "bar time, the amount
of time you'd say you could do it in if you had had a few beers."

The entire point of the estimate is to come up with estimates for all the
stories that are proportional. I prefer 1, 2, 3, but could live with 1, 3,
5.

So what we now know is that a 1 takes 2 days, a 3 takes 6 days, a 5 takes
10 days.

> How would that change your estimates in future iterations?

Not at all.

> Would you revise your estimates to more accurately reflect actual
> velocity? (2 days instead of 1?)

No.

> Or would you continue estimating with the same relative measure you
> used at the beginning of the project?

Yes.

> How would this affect your release plan?

If there are 100 points in the plan, the current best estimate for how long
it will take is 200 person days.

> Would you modify the high level estimates for all future stories?

No.

> Double them?

No.

> Or would you measure them relative to your original estimate and keep
> them the same?

Yes.

> How do you incorporate actuals into your plans and how would you
> explain it to customers?

"We have rated these stories 1, 3, and 5. It takes us two days to do each
point. Therefore, since you have given us a list that totals 100, the
project will take us about 200 person (or pair) days to complete. We don't
really believe this figure, nor should you, for these reasons:

1. You have the right to change your mind about what to do and what to
defer, and we expect that you'll do that.

2. We'll probably learn that some of these stories are easier than we
thought, and some are harder. That will change the total amount of time,
but there's no way to be sure how much or in which direction. Therefore,
we'll give you this same information regularly, and whenever you want it.

3. The size of the team may change or our abilities may change. This,
too, will effect how fast we go. Again, we'll keep you up to date on the
changes, and will gladly re-estimate whenever you wish."

Regards,

Ron Jeffries
www.XProgramming.com
Will Turner: This is either madness or brilliance.
Captain Jack Sparrow: It's remarkable how often those two traits coincide.
• ... I don t. Instead, I reestimate the remaining stories, trusting that I will incorporate into the new estimates whatever I have learned from our current
Message 3 of 6 , Jun 29, 2004
• 0 Attachment
Jonathan Rasmusson wrote:

> Hi all,
>
> I would like to hear peoples comments with regards to how
> they are incorporating actual velocity measurements into their
> release plans.

I don't. Instead, I reestimate the remaining stories, trusting that I
will incorporate into the new estimates whatever I have learned from our
current velocity. The result tends to converge to something that still
supports predictable delivery well enough for my needs.
--
J. B. Rainsberger,
Diaspar Software Services
http://www.diasparsoftware.com :: +1 416 791-8603
Let's write software that people understand
• ... do each ... the ... We don t ... what to ... than we ... of time, ... Therefore, ... want it. ... This, ... on the ... Ok. 1,2,3 points for all the
Message 4 of 6 , Jun 30, 2004
• 0 Attachment
--- In extremeprogramming@yahoogroups.com, Ron Jeffries
<jeffries@d...> wrote:
> On Monday, June 28, 2004, at 4:35:41 PM, Jonathan Rasmusson wrote:
>
>
>
> > How do you incorporate actuals into your plans and how would you
> > explain it to customers?
>
> "We have rated these stories 1, 3, and 5. It takes us two days to
do each
> point. Therefore, since you have given us a list that totals 100,
the
> project will take us about 200 person (or pair) days to complete.
We don't
> really believe this figure, nor should you, for these reasons:
>
> 1. You have the right to change your mind about what to do and
what to
> defer, and we expect that you'll do that.
>
> 2. We'll probably learn that some of these stories are easier
than we
> thought, and some are harder. That will change the total amount
of time,
> but there's no way to be sure how much or in which direction.
Therefore,
> we'll give you this same information regularly, and whenever you
want it.
>
> 3. The size of the team may change or our abilities may change.
This,
> too, will effect how fast we go. Again, we'll keep you up to date
on the
> changes, and will gladly re-estimate whenever you wish."
>

Ok. 1,2,3 points for all the reasons described above. I like that.

How do you convert this into a date?

i.e. how do you communicate to the customer when you expect to be
done? (based on how much/little you know today).

I understand the XP concept of adaptive planning and feedback based
on velocity. Wondering how you explain this to the customer, in
light of them still asking for a date?

Many thx,

Jonathan
• We ve scoped this project at around 140 points, based on our previous experience. Our previous experience also tells us we can do about 14 points of work per
Message 5 of 6 , Jun 30, 2004
• 0 Attachment
"We've scoped this project at around 140 points, based on our previous
experience. Our previous experience also tells us we can do about 14
points of work per week. So that puts it at about 10 weeks from when
we start."

--
John Brewer

Extreme Programming FAQ: http://www.jera.com/techinfo/xpfaq.html
• ... There is no easy answer: there is only the truth. Right now, this appears to be a 200 point project. Based on our performance on other projects (or a
Message 6 of 6 , Jul 1, 2004
• 0 Attachment
On Wednesday, June 30, 2004, at 7:09:40 PM, Jonathan Rasmusson wrote:

> How do you convert this into a date?

> i.e. how do you communicate to the customer when you expect to be
> done? (based on how much/little you know today).

> I understand the XP concept of adaptive planning and feedback based
> on velocity. Wondering how you explain this to the customer, in
> light of them still asking for a date?

There is no easy answer: there is only the truth.

"Right now, this appears to be a 200 point project. Based on our
performance on other projects (or a random guess), with N programmers on
it, and your intimate involvement in the project, a project of this size
will take between 4 and 6 months.

"However. We will be shipping software to you every two weeks, and we'll be
ticking off these feature stories to //your// satisfaction. The good news
is that if you're not satisfied, you can stop. The better news is that if
you become satisfied before all the features are done, you can stop. The
bad news is that you need to work with us to make it clear just what your
satisfaction means. The best news is that whenever there are enough
features working to make the program useful, you can ask us to prepare it
for deployment, and we'll do that.

"As we go forward, we'll all see how fast we're progressing, and our
estimate of the time needed will improve. In every case, you'll see what is
going on, you'll see concrete evidence of useful software running the tests
that you specify, and you'll know everything as soon as we know it."

Ron Jeffries
www.XProgramming.com
If names and real items do not correspond with each other, there will be fighting.
-- Jing Fa
Your message has been successfully submitted and would be delivered to recipients shortly.