Sunday, September 11, 2005, at 10:51:45 AM, Steven Woody wrote:

if an use case got three even flows, so there might be three stories there,
right? so i want to ask, in XP, what's is the time to list all the user stories
and got know the clear boundary of the system (all the functions need to
delivery). if i don't know that, i think i can not plan the prject -- i can not
only plan the next two week.

Couldn't you plan as far out as all the stories extend, not just two
weeks?

on the other hand, because user stories will be disscovered out during
iterations. so, at the very beginning of the project, how do i tell my boss how
many month the system will be done? this question keep confusing me.

Well, I'd think that the most important stories would come out
early. Would you agree? If so, the essence of the system should be
easy to estimate.

And I'd think that the boss would understand the basic benefits of
the proposed system, and would know how much time and money it would
be worth. So the Agile approach allows you to say how much can be
done within those resources, and to pick the best stuff to do, even
if a good idea does pop up late on in the project.

Ron Jeffries
www.XProgramming.com
To gain knowledge, add something every day;
to gain wisdom, remove something every day.
-- Lao Tzu

To Post a message, send it to: extremeprogramming (AT) eGroups (DOT) com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe (AT) eGroups (DOT) com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*To visit your group on the web, go to:

<*To unsubscribe from this group, send an email to:
extremeprogramming-unsubscribe (AT) yahoogroups (DOT) com

<*Your use of Yahoo! Groups is subject to:

Tuesday, September 13, 2005, at 9:45:42 AM, Steven Woody wrote:

>And I'd think that the boss would understand the basic benefits of
>the proposed system, and would know how much time and money it would
>be worth. So the Agile approach allows you to say how much can be
>done within those resources, and to pick the best stuff to do, even
>if a good idea does pop up late on in the project.

so it's still a rough estimate. in a very beginning of the development,
supposing got 80% user stories, and having few of them was well described, i
also even can not image the speed of the team (it will be known after two or
three iterations), how do i talk with my boss about the overall resources we
will need and total time we will need to build and delivery a system?

sorry for so much a hard question

How would you estimate the project if you weren't doing it in an
Agile fashion? Why would the estimate on an Agile project be other
than just as good, or better?

Ron Jeffries
www.XProgramming.com
2 + 2 = 5, for sufficiently large values of 2.

To Post a message, send it to: extremeprogramming (AT) eGroups (DOT) com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe (AT) eGroups (DOT) com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*To visit your group on the web, go to:

<*To unsubscribe from this group, send an email to:
extremeprogramming-unsubscribe (AT) yahoogroups (DOT) com

<*Your use of Yahoo! Groups is subject to:

Ron Jeffries wrote:
Steven Woody wrote:

>>in a very beginning of the development,
>>supposing got 80% user stories, and having few of them was well described, i
>>also even can not image the speed of the team (it will be known after two or
>>three iterations), how do i talk with my boss about the overall resources we
>>will need and total time we will need to build and delivery a system?

>>sorry for so much a hard question

Hi Steve,

It's a delightful question!

How would you estimate the project if you weren't doing it in an
Agile fashion?

I take a user story here and a user story there and guestimate the
number of ideal days each would take. I'd have a guess that velocity is
about 1 ideal day / 3 elapsed days. And that gives me an feel for the
size of a typical story.

I have a look through the specification and see how complete it feels
and guestimate the percentage of missing stories.

Given enough time, I do a matrix with stories on the vertical and
activities across the horizontal and estimate each cell individually.

Given not enough time, I still do the matrix and estimate each row and
column and do a straight multiply to get a value in each cell.

It takes a few days, given the need to understand the horizontal stories
and vertical tasks. But it's time that has to be spent at some point
and often turns up things that haven't been properly considered.

2 + 2 = 5, for sufficiently large values of 2.

The method gives you a ballpark figure and it gives you something to
track against as the project moves forwards.

Learning requires feedback. To improve, find a way to get feedback.

Regards, Ben

To Post a message, send it to: extremeprogramming (AT) eGroups (DOT) com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe (AT) eGroups (DOT) com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*To visit your group on the web, go to:

<*To unsubscribe from this group, send an email to:
extremeprogramming-unsubscribe (AT) yahoogroups (DOT) com

<*Your use of Yahoo! Groups is subject to:

Ben,
Either you or I are mixing XP up with some other way of doing software
development.
Under my understanding of XP, one could make an rough estimate against some
spec in order to help management decide whether the project was worth
starting, but with the explicit understanding that:
1. The "go/no go" decision should be reviewed again after every few
iterations anyway, given the continually improved information about what the
project really entails and how much progress is being made.
2. Much of the requirements in any traditional upfront spec consist of
features that will be discovered to be totally unnecessary when working
software is delivered in business value order iteratively to customers who
then rethink what they need.
3. Iterative delivery will also lead to the discovery of new requirements
that will displace much of the initial spec.
Therefore, the "need to understand the horizontal stories and vertical
tasks" as they exist at project estimation time is time that will NT need
to be spent at some later point in time. It is a big waste of time and
resources. Much more will be discovered during the first iteration of
development.
Furthermore, one would NT track progress against the initial estimate, but
rather track progress against features being delivered, and perhaps their
value to the customer.
If your particular management forces you to waste effort creating a plan at
a level of detail that is not supported by the information available at the
beginning of a project and then track progress against that initial plan,
then your particular management is not letting you do XP.
Steven Gordon

9/13/05, BenAveling <bena (AT) xenon (DOT) triode.net.auwrote:

Ron Jeffries wrote:
Steven Woody wrote:

>>in a very beginning of the development,
>>supposing got 80% user stories, and having few of them was well
described, i
>>also even can not image the speed of the team (it will be known after
two or
>>three iterations), how do i talk with my boss about the overall
resources we
>>will need and total time we will need to build and delivery a system?

>>sorry for so much a hard question

Hi Steve,

It's a delightful question!

How would you estimate the project if you weren't doing it in an
Agile fashion?

I take a user story here and a user story there and guestimate the
number of ideal days each would take. I'd have a guess that velocity is
about 1 ideal day / 3 elapsed days. And that gives me an feel for the
size of a typical story.

I have a look through the specification and see how complete it feels
and guestimate the percentage of missing stories.

Given enough time, I do a matrix with stories on the vertical and
activities across the horizontal and estimate each cell individually.

Given not enough time, I still do the matrix and estimate each row and
column and do a straight multiply to get a value in each cell.

It takes a few days, given the need to understand the horizontal stories
and vertical tasks. But it's time that has to be spent at some point
and often turns up things that haven't been properly considered.

2 + 2 = 5, for sufficiently large values of 2.

The method gives you a ballpark figure and it gives you something to
track against as the project moves forwards.

Learning requires feedback. To improve, find a way to get feedback.

Regards, Ben

[Non-text portions of this message have been removed]

To Post a message, send it to: extremeprogramming (AT) eGroups (DOT) com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe (AT) eGroups (DOT) com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*To visit your group on the web, go to:

<*To unsubscribe from this group, send an email to:
extremeprogramming-unsubscribe (AT) yahoogroups (DOT) com

<*Your use of Yahoo! Groups is subject to:

Hi Steven and Ben,

I think it's best to compare XP style planning and whatever
other means one has been using, with comparable information.

If the original spec is weak, no scheme will give a good estimate,
and XP's may be better because it focuses on what is known about the
time to actually build software rather than a broader notion. The XP
project is also likely to perform better against the perceived need,
because it adapts to that need as it goes along, and because the
more waterfall-style project learns less in the early stages, and is
thus unable to adapt.

I'll comment a bit below, in the light of my thinking above.

Ron Jeffries
www.XProgramming.com
If there's only one answer, then this must not be a very interesting topic.

Tuesday, September 13, 2005, at 5:45:32 PM, Steven Gordon wrote:

Either you or I are mixing XP up with some other way of doing software
development.
Under my understanding of XP, one could make an rough estimate against some
spec in order to help management decide whether the project was worth
starting,

and so could any other process, I would think we'd agree

but with the explicit understanding that:
1. The "go/no go" decision should be reviewed again after every few
iterations anyway, given the continually improved information about what the
project really entails and how much progress is being made.

Yes, and the XP project actually focuses on delivering software, so
that the go/no go decision can be made more effectively. (Plus, if
the software is actually shippable, which it is supposed to be, more
value is likely to be salvaged.)

Note that this topic is not unrelated to the discussion with Ken
Boucher and others about waterfall and whether iterative is
preferable. I think it is, and the above is part of why.

2. Much of the requirements in any traditional upfront spec consist of
features that will be discovered to be totally unnecessary when working
software is delivered in business value order iteratively to customers who
then rethink what they need.

While we might quibble over how much is "much", I agree. However,
the people with whom we debate these topics do not grant that. They
believe that it is possible to have a solid spec, and that "this
time" they will. They are comparing an ideal to reality, and ideals
usually win in that comparison.

I'm not sure what one does about this, though I've had a lot of
rueful smiles in response to a question I learned from KB: "How's
that working out for you?"

3. Iterative delivery will also lead to the discovery of new requirements
that will displace much of the initial spec.

Yes, subject to similar comments as just above

Therefore, the "need to understand the horizontal stories and vertical
tasks" as they exist at project estimation time is time that will NT need
to be spent at some later point in time. It is a big waste of time and
resources. Much more will be discovered during the first iteration of
development.

Agreed, but the big process idealists will not agree. Not clear what
one does about this.

Furthermore, one would NT track progress against the initial estimate, but
rather track progress against features being delivered, and perhaps their
value to the customer.

Yes. I think this is an important point and there should be a good
way to turn it to our advantage, though I don't see it right this
second.

If your particular management forces you to waste effort creating a plan at
a level of detail that is not supported by the information available at the
beginning of a project and then track progress against that initial plan,
then your particular management is not letting you do XP.

True but they might do it, and if they do, XP is probably still
one of the best strategies you can adopt. Would you agree?

Regards,

R

To Post a message, send it to: extremeprogramming (AT) eGroups (DOT) com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe (AT) eGroups (DOT) com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*To visit your group on the web, go to:

<*To unsubscribe from this group, send an email to:
extremeprogramming-unsubscribe (AT) yahoogroups (DOT) com

<*Your use of Yahoo! Groups is subject to:

Ben,
The question you were answering was posed on the XP list by somebody who
appeared to earnestly want to do XP in the stated situation. I just
naturally assumed you were presenting what you believed was an answer that
would work in the context of XP. If the crux of your answer was "do not do
XP", then you really should so say clearly.
Comparing estimates with actuals in iteration planning is a good way to
improve your ability at estimating technical tasks. Comparing actuals with
estimates before a project has even started is not a measurement of your
ability to estimate, but rather a measurement of one or more of:
- the accuracy of your crystal ball,
- the ability of your organization to resist change,
- the willingness of the troops to work enough overtime to make the estimate
appear to be accurate
I have no problem with making initial swags any way you need to, but
constraining a project to stick to the original spec or measuring it against
the original swag is simply not agile. Change will be resisted,
communication will decrease, opportunities to leverage learning will
disappear, and delivered value will suffer.
However, if management paints you in this corner and you are unable to
change your organization (or change your organization), then XP as the
implementation approach does at least guarantee you will have working
software to deliver when the promised end date arrives, even if it is
missing some of the least valuable features promised before the project
started.
Steve

9/13/05, ben_aveling <bena (AT) xenon (DOT) triode.net.auwrote:

In extremeprogramming (AT) yahoogroups (DOT) com, Steven Gordon
<sgordonphd@gwrote:
Either you or I are mixing XP up with some other way of doing
software development.

Hi Steve,

I'm not discussing XP. The question I was answering was:

How would you estimate the project if you weren't doing
it in an Agile fashion?

I hope I managed to do that.

The "need to understand the horizontal stories and
vertical tasks" as they exist at project estimation time is time
that will NT need to be spent at some later point in time. It is
a big waste of time and resources.

I'm not sure about that. Even on an XP project, perhaps especially
on an XP project, Development need to tell Business how much
individual stories will cost so that Business can prioritise.

That requires understanding the story, and the steps needed to
complete the story.

Much more will be discovered during the first iteration of
development.

course, which means that estimates change. It doesn't mean we
shouldn't do estimates. that we shouldn't go into too much
detail for stories that are clearly not going into the next
iteration.

Furthermore, one would NT track progress against the initial
estimate, but rather track progress against features being
delivered, and perhaps their value to the customer.

You need to track estimates against actuals if you want to know and
improve the accuracy of your estimates.

If your particular management forces you to waste effort creating
a plan at a level of detail that is not supported by the
information available at the beginning of a project and
then track progress against that initial plan,
then your particular management is not letting you do XP.

My management tend to hand down tasks and say 'you can do this by
then, right?' And they don't want to hear 'no'.

So if the answer is actually 'no' I need to know that and I need to
be able to back it up. I'm mainly doing this for my benefit,
because I don't want to commit to something I can't deliver. That
way lies pain, suffering and unpaid overtime.

Regards, Ben

[Non-text portions of this message have been removed]

To Post a message, send it to: extremeprogramming (AT) eGroups (DOT) com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe (AT) eGroups (DOT) com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*To visit your group on the web, go to:

<*To unsubscribe from this group, send an email to:
extremeprogramming-unsubscribe (AT) yahoogroups (DOT) com

<*Your use of Yahoo! Groups is subject to:

Tuesday, September 13, 2005, at 11:22:05 PM, Steven Gordon wrote:

Comparing estimates with actuals in iteration planning is a good way to
improve your ability at estimating technical tasks. Comparing actuals with
estimates before a project has even started is not a measurement of your
ability to estimate, but rather a measurement of one or more of:
- the accuracy of your crystal ball,
- the ability of your organization to resist change,
- the willingness of the troops to work enough overtime to make the estimate
appear to be accurate

Steven I don't understand the reasoning here. What makes
comparing estimates and actuals a reasonable thing to do at
iteration scale, and virtually insane at the project scale?

Why wouldn't we learn things from either comparison?

Ron Jeffries
www.XProgramming.com
Perhaps this Silver Bullet will tell you who I am

To Post a message, send it to: extremeprogramming (AT) eGroups (DOT) com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe (AT) eGroups (DOT) com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*To visit your group on the web, go to:

<*To unsubscribe from this group, send an email to:
extremeprogramming-unsubscribe (AT) yahoogroups (DOT) com

<*Your use of Yahoo! Groups is subject to:

Ron,
We have increasing feedback, knowledge, and learning at the iteration level
during the life of any given project. This should allow us to hone our
estimates (and better understand exactly what the customer needs/wants) over
time for that project.
the other hand, we can only give an initial estimate for any given
project once. Furthermore, an initial estimate is made at a time when we
have the least information about that project, its circumstances, and how it
will change.
course, if we were doing virtually the same project in the same
circumstances over and over again, that would be a different story.
Steve

9/13/05, Ron Jeffries <ronjeffries (AT) xprogramming (DOT) comwrote:

Tuesday, September 13, 2005, at 11:22:05 PM, Steven Gordon wrote:

Comparing estimates with actuals in iteration planning is a good way to
improve your ability at estimating technical tasks. Comparing actuals
with
estimates before a project has even started is not a measurement of your
ability to estimate, but rather a measurement of one or more of:
- the accuracy of your crystal ball,
- the ability of your organization to resist change,
- the willingness of the troops to work enough overtime to make the
estimate
appear to be accurate

Steven I don't understand the reasoning here. What makes
comparing estimates and actuals a reasonable thing to do at
iteration scale, and virtually insane at the project scale?

Why wouldn't we learn things from either comparison?

Ron Jeffries
www.XProgramming.com <http://www.XProgramming.com>
Perhaps this Silver Bullet will tell you who I am

[Non-text portions of this message have been removed]

To Post a message, send it to: extremeprogramming (AT) eGroups (DOT) com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe (AT) eGroups (DOT) com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*To visit your group on the web, go to:

<*To unsubscribe from this group, send an email to:
extremeprogramming-unsubscribe (AT) yahoogroups (DOT) com

<*Your use of Yahoo! Groups is subject to:

It is well known that you cannot control all three of scope, time, and cost.
When you pretend you can, you end up with a cost overrun and usually have
nothing to deliver on the due date. While XP has little to say about initial
estimates, it does have something to say about honest communication.
I am seeing significant progress on acceptance of XP/agile over here. I
have even seen XP work on fixed price projects if the customer is willing to
accept the option after each iteration to:
1. Cancel the project if they are not getting adequate value for their cost
(and pay for what they got so far).
2. Trade new stories for equivalent stories in the initial contract.
Why would a customer not accept extra options for free. Yet, these options
usually lead to high customer satisfaction with a project that ultimately
does not deliver all the contracted features. The customer discovers they
are happier with working software on schedule with the features the customer
discovers they really need. Many of these projects get extended because the
customer discovers even more new features they want to pay for.
Why does this work? Cancellation after any iteration means either a quick
exit where neither side loses face, or increasingly good rapport. Embracing
change works because no up front spec of a piece of software that does not
yet exist will correctly identify all the necessary features and none of the
unnecessary features. This approach only fails if management enforces no
change to the spec by not allowing direct contact with the customer. Under
those circumstances, the project is most likely to fail using any
methodology. so it is business you should not want to undertake anyway.
Lastly, XP does deliver working software after every iteration, so of
course, we can guarantee working software on the due date. What we cannot
guarantee is which features have been implemented yet, but if we implement
them in customer priority order, then the features of least value are the
ones that are missing.

9/13/05, ben_aveling <bena (AT) xenon (DOT) triode.net.auwrote:

Ben,

The question you were answering was posed on the XP list by
somebody who appeared to earnestly want to do XP in the stated
situation.

Hi Steve,

I don't think XP covers the situation he was in. XP is an excellent
methodology for Time and Materials contracts. But XP doesn't say
much about how to do a business case for a T&M contract. Maybe one
day it will. I hope so.

his project gets approved, he might be in a situation where he
can do XP. Between now and then, I gather he needs some idea of how
much time it will take to deliver on a somewhat vague list of
features.

If he estimates low, pain and suffering because he'll be expected to
deliver on it. If he estimates high enough but can't defend it,
pain and suffering anyway because the estimate will be 'negotiated'
downwards.

I just
naturally assumed you were presenting what you believed was an
answer that would work in the context of XP.

You could do it in the context of XP, but probably you wouldn't need
to. That's partially because of all the extra information you
have. It's partially because you're not so worried about the
future, and it's partially because you're not in the least worried
about controlling the total scope.

If the crux of your answer was "do not do
XP", then you really should so say clearly.

Very well. If you have a fixed time frame and you have a contract
that says exactly what you have to deliver, do not do Pure XP. Do
as many of the XP practices as you can and no more.

Comparing actuals with
estimates before a project has even started is
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I didn't say that. course you can't do anything with actuals
until you have actuals. I'm confused about why you think I was
advocating doing so?

I have no problem with making initial swags any way you need to,
but constraining a project to stick to the original spec or
measuring it against the original swag is simply not agile.
Change will be resisted, communication will decrease,
opportunities to leverage learning will
disappear, and delivered value will suffer.

By swag you mean schedule? If so, everything you say is true.
Waterfall is a suboptimal way to develop software, from the point of
view of the software developers.

But business pays the bills. The most efficient way for most big
corporates to commision software is for them to understand what they
are buying before they sign the check. That means having a list of
features and a price tag.

It's less efficient for us, but moving from up-front approval to
week by week approvals would creates costs elsewhere, in most
companies anyway.

XP as the
implementation approach does at least guarantee you will have
workingsoftware to deliver when the promised end date arrives,
even if it is missing some of the least valuable features promised
before the project started.

No methodology does that. XP makes it more likely, but XP imposes
other costs elsewhere in the business. Most corporates haven't yet
persuaded themselves of the /overall/ value of XP.

We're working on it. It's a slow process.

Regards, Ben

To Post a message, send it to: extremeprogramming (AT) eGroups (DOT) com

To Unsubscribe, send a blank message to:
extremeprogramming-unsubscribe (AT) eGroups (DOT) com

ad-free courtesy of objectmentor.com <http://objectmentor.com>
Yahoo! Groups Links

[Non-text portions of this message have been removed]

To Post a message, send it to: extremeprogramming (AT) eGroups (DOT) com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe (AT) eGroups (DOT) com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*To visit your group on the web, go to:

<*To unsubscribe from this group, send an email to:
extremeprogramming-unsubscribe (AT) yahoogroups (DOT) com

<*Your use of Yahoo! Groups is subject to:

Wednesday, September 14, 2005, at 12:36:36 AM, ben_aveling wrote:

>If the crux of your answer was "do not do
>XP", then you really should so say clearly.

Very well. If you have a fixed time frame and you have a contract
that says exactly what you have to deliver, do not do Pure XP. Do
as many of the XP practices as you can and no more.

And for the rest?

Ron Jeffries
www.XProgramming.com
Prediction is very difficult, especially if it's about the future. -- Niels Bohr

To Post a message, send it to: extremeprogramming (AT) eGroups (DOT) com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe (AT) eGroups (DOT) com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*To visit your group on the web, go to:

<*To unsubscribe from this group, send an email to:
extremeprogramming-unsubscribe (AT) yahoogroups (DOT) com

<*Your use of Yahoo! Groups is subject to:

Wednesday, September 14, 2005, at 12:26:40 AM, Steven Gordon wrote:

We have increasing feedback, knowledge, and learning at the iteration level
during the life of any given project. This should allow us to hone our
estimates (and better understand exactly what the customer needs/wants) over
time for that project.
the other hand, we can only give an initial estimate for any given
project once. Furthermore, an initial estimate is made at a time when we
have the least information about that project, its circumstances, and how it
will change.
course, if we were doing virtually the same project in the same
circumstances over and over again, that would be a different story.

Well but isn't it all a matter of scale? At the time we give any
estimate, we have only the past to consider and the future is a
guess based on what has happened in the past.

I can see that an initial project estimate is much less accurate
than a mid-project one probably the error bars increase worse
than linearly with the duration estimated but it seems to me
that we can't do any project without some kind of initial estimate.

Ron Jeffries
www.XProgramming.com
Make it real or else forget about it -- Carlos Santana

To Post a message, send it to: extremeprogramming (AT) eGroups (DOT) com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe (AT) eGroups (DOT) com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*To visit your group on the web, go to:

<*To unsubscribe from this group, send an email to:
extremeprogramming-unsubscribe (AT) yahoogroups (DOT) com

<*Your use of Yahoo! Groups is subject to:

Wednesday, September 14, 2005, at 8:31:45 AM, Steven Woody wrote:

>I take a user story here and a user story there and guestimate the
>number of ideal days each would take. I'd have a guess that velocity is
>about 1 ideal day / 3 elapsed days. And that gives me an feel for the

what did you mean by 1 ideal day / 3 elapsed days? is it a typo here?

I estimate in ideal days how long it would take me to do if
everyone left me alone, I was as intelligent as I like to think I
am, I didn't have to go to any meetings, there weren't any network
problems that is, it's an ideal day.

It takes, I would estimate, 3 real days to get an ideal day. So
velocity is one ideal day per three real days, shown as the ratio

1 ideal day / 3 elapsed days

So that if I thought the features could be done in ten ideal days,
I'd estimate 30 working days for the project, or about six weeks.

K?

Ron Jeffries
www.XProgramming.com
I could be wrong. I frequently am.

To Post a message, send it to: extremeprogramming (AT) eGroups (DOT) com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe (AT) eGroups (DOT) com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*To visit your group on the web, go to:

<*To unsubscribe from this group, send an email to:
extremeprogramming-unsubscribe (AT) yahoogroups (DOT) com

<*Your use of Yahoo! Groups is subject to:

Wednesday, September 14, 2005, at 8:56:19 AM, Steven Woody wrote:

one side, people just do an estimate and keep an eye on it while in
progress, and believe the estimate will become closer and closer. the other
side, pure XPers think that just do it and delivery real jobs day to day and
consider any overall estimate as none of worthy, they just want to report
what will happen in the next two weeks, anything far than this is just like a
moving target.

There is no such thing, as far as I know, as "Pure XP", and as far
as I know, no people who understand XP think "just do it" and stuff
like that. XP has a practice called "Release Plan" which is about
predicting the course of the whole project. I'd suggest you might
like to read about that, perhaps in /Extreme Programming Installed/.

Ron Jeffries
www.XProgramming.com
Any errors you find in this are the work of Secret Villains,
whose mad schemes will soon be revealed. -- Wil McCarthy

To Post a message, send it to: extremeprogramming (AT) eGroups (DOT) com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe (AT) eGroups (DOT) com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*To visit your group on the web, go to:

<*To unsubscribe from this group, send an email to:
extremeprogramming-unsubscribe (AT) yahoogroups (DOT) com

<*Your use of Yahoo! Groups is subject to:

Wednesday, September 14, 2005, at 10:22:53 AM, aacockburn wrote:

>Steven I don't understand the reasoning here. What makes
>comparing estimates and actuals a reasonable thing to do at
>iteration scale, and virtually insane at the project scale?
>

Hi, Ron,

I notice you shifted Steven's sentence in your return question.
Steven wrote: <<Comparing actuals with estimates before a project has
even started>>
and you left out the "before a project has started" when you wrote
the rejoinder.

There's a big difference between the presence and absense of that
phrase.

The difference in comparing between iterations and projects is that
iterations are much more like each other than projects are. That's
what makes Yesterday's Weather a plausible practice across
iterations; it has almost no meaning across projects (domain change,
technology change, team change, assignment change). Indeed, from
where I sit, one of the reasons to do incremental development at all
is to exploit the internal similarity within the project (i.e., the
increments / releases / iterations) where there is so little
similarity across projects.

I think you've gone too binary, Alistair. It would be rare for a
team to face two projects with no continuity of any kind. And even
then, I would expect that a team would have a sense of what they
could do, unless they were actually faced with a different
technology and domain. In which case you're screwed whatever you do.

Ron Jeffries
www.XProgramming.com
New and stirring things are belittled because if they are not belittled,
the humiliating question arises, "Why then are you not taking part in
them?" -- H. G. Wells

To Post a message, send it to: extremeprogramming (AT) eGroups (DOT) com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe (AT) eGroups (DOT) com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*To visit your group on the web, go to:

<*To unsubscribe from this group, send an email to:
extremeprogramming-unsubscribe (AT) yahoogroups (DOT) com

<*Your use of Yahoo! Groups is subject to:

Wednesday, September 14, 2005, at 11:00:18 AM, Rob Park wrote:

My hopefully related question is that when we track velocity we have a
fairly steady "divisor". But if you divide your initial estimate by your
velocity, you're very likely to come up short on your end date. Since we're
"embracing change" and change is likely to occur, how would you measure in
order to better estimate how much change is likely to occur between now and
release 1? if it really doesn't matter, why not?

Why would you think that initial estimate / velocity would come up
short?

Ron Jeffries
www.XProgramming.com
Talent determines how fast you get good, not how good you get. -- Richard Gabriel

To Post a message, send it to: extremeprogramming (AT) eGroups (DOT) com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe (AT) eGroups (DOT) com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*To visit your group on the web, go to:

<*To unsubscribe from this group, send an email to:
extremeprogramming-unsubscribe (AT) yahoogroups (DOT) com

<*Your use of Yahoo! Groups is subject to: