Discussion:
Estimation: Time or Size?
Tobias Mayer
2007-05-21 16:43:07 UTC
Permalink
I have recently come across a few people in the Agile field who prefer estimating in "real time" over estimating in size (e.g. story points); I have even heard statements such as: the most advanced implementations of Agile use real time estimates, because it offers the most powerful benefits.

It intrigued me, so I wrote a blog about it: Estimation: Time or Size?

Has anyone on this list found that real time estimation is useful in an Agile context (actually, in any context)? I'd be very interested to hear about it. Thanks.

Tobias Mayer
http://agilethinking.net





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



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Craig Demyanovich
2007-05-21 17:39:05 UTC
Permalink
I'm reading Mike Cohn's book, Agile Estimating and Planning, right now. He
writes that ideal days are an estimate of effort just like story points are.
You use either of these estimates of effort with your velocity to derive
when you'll be done with your work. In short, "...we estimate size but
derive duration." [p. 39]

I don't have any experience with anything other than points so far, but I'm
finding Mike's book to be a fantastic guide. Also, you might want to search
for another thread in this group that is discussing the topic of points
versus hours; it's entitled, "A Real-World Experiment With Hours Instead of
Points."

Craig
Post by Tobias Mayer
I have recently come across a few people in the Agile field who prefer
estimating in "real time" over estimating in size (e.g. story points); I
have even heard statements such as: the most advanced implementations of
Agile use real time estimates, because it offers the most powerful benefits.
It intrigued me, so I wrote a blog about it: Estimation: Time or Size?
Has anyone on this list found that real time estimation is useful in an
Agile context (actually, in any context)? I'd be very interested to hear
about it. Thanks.
Tobias Mayer
http://agilethinking.net
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Steven Gordon
2007-05-21 18:03:36 UTC
Permalink
I have been recommending that teams obtain the best advantages of both real
time and abstract estimation by using story points for release planning (i.e.,
the product backlog) and real time estimation for sprint/iteration planning
(i.e., the task board).

This allows for long-term calibration of story points to avoid continuous
re-estimation of stories and support a meaningful interpretation of evolving
velocities. It also allows for improving real time estimation of what can
be finished on a sprint by sprint basis.

Steve Gordon
Post by Tobias Mayer
I have recently come across a few people in the Agile field who prefer
estimating in "real time" over estimating in size (e.g. story points); I
have even heard statements such as: the most advanced implementations of
Agile use real time estimates, because it offers the most powerful benefits.
It intrigued me, so I wrote a blog about it: Estimation: Time or Size?
Has anyone on this list found that real time estimation is useful in an
Agile context (actually, in any context)? I'd be very interested to hear
about it. Thanks.
Tobias Mayer
http://agilethinking.net
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Daniel Wildt
2007-05-21 22:28:27 UTC
Permalink
And how do you guys translate story points to the real time?

Are you guys using some kind of load factor calculation?

I like to estimate using ideal hours, so the formula goes like:
ideal hours x load factor = expected time

Regards,
Daniel Wildt
HYPERLINK "http://danielwildt.blogspot.com"http://danielwildt.blogspot.com






_____

De: ***@yahoogroups.com [mailto:***@yahoogroups.com] Em nome de Steven Gordon
Enviada em: segunda-feira, 21 de maio de 2007 15:04
Para: ***@yahoogroups.com
Assunto: Re: [XP] Estimation: Time or Size?




I have been recommending that teams obtain the best advantages of both real
time and abstract estimation by using story points for release planning (i.e.,
the product backlog) and real time estimation for sprint/iteration planning
(i.e., the task board).

This allows for long-term calibration of story points to avoid continuous
re-estimation of stories and support a meaningful interpretation of evolving
velocities. It also allows for improving real time estimation of what can
be finished on a sprint by sprint basis.

Steve Gordon
Post by Tobias Mayer
I have recently come across a few people in the Agile field who prefer
estimating in "real time" over estimating in size (e.g. story points); I
have even heard statements such as: the most advanced implementations of
Agile use real time estimates, because it offers the most powerful benefits.
It intrigued me, so I wrote a blog about it: Estimation: Time or Size?
Has anyone on this list found that real time estimation is useful in an
Agile context (actually, in any context)? I'd be very interested to hear
about it. Thanks.
Tobias Mayer
HYPERLINK "http://agilethinking.net"http://agilethinkin-g.net
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]






No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.467 / Virus Database: 269.7.6/814 - Release Date: 21/05/2007 14:01



No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.467 / Virus Database: 269.7.6/814 - Release Date: 21/05/2007 14:01



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



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Steven Gordon
2007-05-21 22:37:03 UTC
Permalink
There is no need to translate story points to real time.

One uses velocity (the moving average of how many story points a team
completely finishes per iteration) to periodically forecast how many story
points worth of functionality is likely to get done by the next release date
in order to periodically revise the release plan (i.e., what will make it
into the release).

Steve
Post by Daniel Wildt
And how do you guys translate story points to the real time?
Are you guys using some kind of load factor calculation?
ideal hours x load factor = expected time
Regards,
Daniel Wildt
HYPERLINK "http://danielwildt.blogspot.com"http://danielwildt.blogspot.com
_____
Em nome de Steven Gordon
Enviada em: segunda-feira, 21 de maio de 2007 15:04
Assunto: Re: [XP] Estimation: Time or Size?
I have been recommending that teams obtain the best advantages of both real
time and abstract estimation by using story points for release planning (
i.e.,
the product backlog) and real time estimation for sprint/iteration planning
(i.e., the task board).
This allows for long-term calibration of story points to avoid continuous
re-estimation of stories and support a meaningful interpretation of evolving
velocities. It also allows for improving real time estimation of what can
be finished on a sprint by sprint basis.
Steve Gordon
On 5/21/07, Tobias Mayer <HYPERLINK "mailto:tobyanon% <tobyanon%25>
Post by Tobias Mayer
I have recently come across a few people in the Agile field who prefer
estimating in "real time" over estimating in size (e.g. story points); I
have even heard statements such as: the most advanced implementations of
Agile use real time estimates, because it offers the most powerful
benefits.
Post by Tobias Mayer
It intrigued me, so I wrote a blog about it: Estimation: Time or Size?
Has anyone on this list found that real time estimation is useful in an
Agile context (actually, in any context)? I'd be very interested to hear
about it. Thanks.
Tobias Mayer
HYPERLINK "http://agilethinking.net"http://agilethinkin-g.net
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.467 / Virus Database: 269.7.6/814 - Release Date: 21/05/2007 14:01
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.467 / Virus Database: 269.7.6/814 - Release Date: 21/05/2007 14:01
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Daniel Wildt
2007-05-21 23:27:46 UTC
Permalink
I measure the number of functionalities inside an iteration by velocity too, but I also use load factor calculation.

This is because I have cases where I don't have developers 100% available to code in the project, so one can be 50% available to the
project, and other can be only focused on the project, so 100%.

Do you guys agree with the possibility to use load factor calculation?

Some of you see that practice as something useful?

Regards,
Daniel Wildt
HYPERLINK "http://danielwildt.blogspot.com"http://danielwildt.blogspot.com






_____

De: ***@yahoogroups.com [mailto:***@yahoogroups.com] Em nome de Steven Gordon
Enviada em: segunda-feira, 21 de maio de 2007 19:37
Para: ***@yahoogroups.com
Assunto: Re: [XP] Estimation: Time or Size?



There is no need to translate story points to real time.

One uses velocity (the moving average of how many story points a team
completely finishes per iteration) to periodically forecast how many story
points worth of functionality is likely to get done by the next release date
in order to periodically revise the release plan (i.e., what will make it
into the release).

Steve
Post by Daniel Wildt
And how do you guys translate story points to the real time?
Are you guys using some kind of load factor calculation?
ideal hours x load factor = expected time
Regards,
Daniel Wildt
HYPERLINK "HYPERLINK "http://danielwildt.blogspot.com"http://danielwildt.-blogspot.-com"HYPERLINK
"http://danielwildt.blogspot.com"http://danielwildt.-blogspot.-com
Post by Daniel Wildt
_____
De: HYPERLINK
<extremeprogramming-%40yahoogroups.-com>]
Post by Daniel Wildt
Em nome de Steven Gordon
Enviada em: segunda-feira, 21 de maio de 2007 15:04
Para: HYPERLINK
Assunto: Re: [XP] Estimation: Time or Size?
I have been recommending that teams obtain the best advantages of both real
time and abstract estimation by using story points for release planning (
i.e.,
the product backlog) and real time estimation for sprint/iteration planning
(i.e., the task board).
This allows for long-term calibration of story points to avoid continuous
re-estimation of stories and support a meaningful interpretation of evolving
velocities. It also allows for improving real time estimation of what can
be finished on a sprint by sprint basis.
Steve Gordon
On 5/21/07, Tobias Mayer <HYPERLINK "mailto:tobyanon% <tobyanon%25>
Post by Tobias Mayer
I have recently come across a few people in the Agile field who prefer
estimating in "real time" over estimating in size (e.g. story points); I
have even heard statements such as: the most advanced implementations of
Agile use real time estimates, because it offers the most powerful
benefits.
Post by Tobias Mayer
It intrigued me, so I wrote a blog about it: Estimation: Time or Size?
Has anyone on this list found that real time estimation is useful in an
Agile context (actually, in any context)? I'd be very interested to hear
about it. Thanks.
Tobias Mayer
HYPERLINK "HYPERLINK "http://agilethinking.net"http://agilethinkin-g.net"HYPERLINK
"http://agilethinkin-g.net"http://agilethinkin--g.net
Post by Daniel Wildt
Post by Tobias Mayer
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.467 / Virus Database: 269.7.6/814 - Release Date: 21/05/2007 14:01
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.467 / Virus Database: 269.7.6/814 - Release Date: 21/05/2007 14:01
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]






No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.467 / Virus Database: 269.7.6/814 - Release Date: 21/05/2007 14:01



No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.467 / Virus Database: 269.7.6/814 - Release Date: 21/05/2007 14:01



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



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Steven Gordon
2007-05-22 00:42:10 UTC
Permalink
For iteration planning, I recommend teams make a projection of how many
hours the team has available to compace to their estimation of how many
hours it will take to complete the stories the team would like to commit to
(as a sanity check before really making the commitment). This seems simpler
than what I would imagine a load factor might be (unless, of course, this is
exactly what you mean).

Using some sort of load factor in the velocity would be useless, unless you
can predict the availability of people each iteration until the next release
date. If you cannot predict that (or the prediction would be similar enough
to the mix over the set of iterations that is being used to calculate the
velocity), then the average velocity is as good a predictor as any.

Keep it simple, and then only add complications when the simple approach is
not working for you. Part of agility is the discipline to not
overcomplicate by anticipating problems and implementing solutions for them
before they actually prove to be problems.

Steve
Post by Daniel Wildt
I measure the number of functionalities inside an iteration by velocity
too, but I also use load factor calculation.
This is because I have cases where I don't have developers 100% available
to code in the project, so one can be 50% available to the
project, and other can be only focused on the project, so 100%.
Do you guys agree with the possibility to use load factor calculation?
Some of you see that practice as something useful?
Regards,
Daniel Wildt
HYPERLINK "http://danielwildt.blogspot.com"http://danielwildt.blogspot.com
_____
Em nome de Steven Gordon
Enviada em: segunda-feira, 21 de maio de 2007 19:37
Assunto: Re: [XP] Estimation: Time or Size?
There is no need to translate story points to real time.
One uses velocity (the moving average of how many story points a team
completely finishes per iteration) to periodically forecast how many story
points worth of functionality is likely to get done by the next release date
in order to periodically revise the release plan (i.e., what will make it
into the release).
Steve
On 5/21/07, Daniel Wildt <HYPERLINK "mailto:dwildt% <dwildt%25>40gmail.com
Post by Daniel Wildt
And how do you guys translate story points to the real time?
Are you guys using some kind of load factor calculation?
ideal hours x load factor = expected time
Regards,
Daniel Wildt
HYPERLINK "HYPERLINK "http://danielwildt.blogspot.com"
http://danielwildt.-blogspot.-com"HYPERLINK
"http://danielwildt.blogspot.com"http://danielwildt.-blogspot.-com
Post by Daniel Wildt
_____
De: HYPERLINK
"mailto:extremeprogramming%40yahoogroups.com
Post by Daniel Wildt
HYPERLINK "mailto:extremeprogramming%40yahoogroups.com
<extremeprogramming-%40yahoogroups.-com>]
Post by Daniel Wildt
Em nome de Steven Gordon
Enviada em: segunda-feira, 21 de maio de 2007 15:04
Para: HYPERLINK
"mailto:extremeprogramming%40yahoogroups.com
Post by Daniel Wildt
Assunto: Re: [XP] Estimation: Time or Size?
I have been recommending that teams obtain the best advantages of both real
time and abstract estimation by using story points for release planning
(
Post by Daniel Wildt
i.e.,
the product backlog) and real time estimation for sprint/iteration planning
(i.e., the task board).
This allows for long-term calibration of story points to avoid
continuous
Post by Daniel Wildt
re-estimation of stories and support a meaningful interpretation of evolving
velocities. It also allows for improving real time estimation of what
can
Post by Daniel Wildt
be finished on a sprint by sprint basis.
Steve Gordon
On 5/21/07, Tobias Mayer <HYPERLINK "mailto:tobyanon% <tobyanon%25><tobyanon%25>
Post by Tobias Mayer
I have recently come across a few people in the Agile field who prefer
estimating in "real time" over estimating in size (e.g. story points);
I
Post by Daniel Wildt
Post by Tobias Mayer
have even heard statements such as: the most advanced implementations
of
Post by Daniel Wildt
Post by Tobias Mayer
Agile use real time estimates, because it offers the most powerful
benefits.
Post by Tobias Mayer
It intrigued me, so I wrote a blog about it: Estimation: Time or Size?
Has anyone on this list found that real time estimation is useful in
an
Post by Daniel Wildt
Post by Tobias Mayer
Agile context (actually, in any context)? I'd be very interested to
hear
Post by Daniel Wildt
Post by Tobias Mayer
about it. Thanks.
Tobias Mayer
HYPERLINK "HYPERLINK "http://agilethinking.net"
http://agilethinkin-g.net"HYPERLINK
"http://agilethinkin-g.net"http://agilethinkin--g.net
Post by Daniel Wildt
Post by Tobias Mayer
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]
No virus found in this incoming message.
Checked by AVG Free Edition.
21/05/2007
Post by Daniel Wildt
14:01
No virus found in this outgoing message.
Checked by AVG Free Edition.
21/05/2007
Post by Daniel Wildt
14:01
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.467 / Virus Database: 269.7.6/814 - Release Date: 21/05/2007 14:01
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.467 / Virus Database: 269.7.6/814 - Release Date: 21/05/2007 14:01
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Daniel Wildt
2007-05-22 03:12:50 UTC
Permalink
Your suggestion is a pretty good one Steven. Thanks.

I use load factor only when I know the availability of developers.
And also, I like to do that when I don't have 100% of full time developers for the project.

When I have a team working 100% for a specific project, I consider working with velocity only. It is simple to manage.

And as you recommend, if I know that the team will have X points/hours available to burn, I will only estimate those X hours.
And I will update that estimate after the iteration, with the velocity.

I see a lot of papers and messages talking about load factory being not useful to projects, so I started questioning myself about
it.

I will try to work with velocity only to see how I manage that in next projects.
Sometimes is just about keeping things simple, more than they are today.

Thanks for your time.

Regards,
Daniel Wildt
HYPERLINK "http://danielwildt.blogspot.com"http://danielwildt.blogspot.com






_____

De: ***@yahoogroups.com [mailto:***@yahoogroups.com] Em nome de Steven Gordon
Enviada em: segunda-feira, 21 de maio de 2007 21:42
Para: ***@yahoogroups.com
Assunto: Re: [XP] Estimation: Time or Size?




For iteration planning, I recommend teams make a projection of how many
hours the team has available to compace to their estimation of how many
hours it will take to complete the stories the team would like to commit to
(as a sanity check before really making the commitment). This seems simpler
than what I would imagine a load factor might be (unless, of course, this is
exactly what you mean).

Using some sort of load factor in the velocity would be useless, unless you
can predict the availability of people each iteration until the next release
date. If you cannot predict that (or the prediction would be similar enough
to the mix over the set of iterations that is being used to calculate the
velocity), then the average velocity is as good a predictor as any.

Keep it simple, and then only add complications when the simple approach is
not working for you. Part of agility is the discipline to not
overcomplicate by anticipating problems and implementing solutions for them
before they actually prove to be problems.

Steve
Post by Daniel Wildt
I measure the number of functionalities inside an iteration by velocity
too, but I also use load factor calculation.
This is because I have cases where I don't have developers 100% available
to code in the project, so one can be 50% available to the
project, and other can be only focused on the project, so 100%.
Do you guys agree with the possibility to use load factor calculation?
Some of you see that practice as something useful?
Regards,
Daniel Wildt
HYPERLINK "HYPERLINK "http://danielwildt.blogspot.com"http://danielwildt.-blogspot.-com"HYPERLINK
"http://danielwildt.blogspot.com"http://danielwildt.-blogspot.-com
Post by Daniel Wildt
_____
De: HYPERLINK
<extremeprogramming-%40yahoogroups.-com>]
Post by Daniel Wildt
Em nome de Steven Gordon
Enviada em: segunda-feira, 21 de maio de 2007 19:37
Para: HYPERLINK
Assunto: Re: [XP] Estimation: Time or Size?
There is no need to translate story points to real time.
One uses velocity (the moving average of how many story points a team
completely finishes per iteration) to periodically forecast how many story
points worth of functionality is likely to get done by the next release date
in order to periodically revise the release plan (i.e., what will make it
into the release).
Steve
On 5/21/07, Daniel Wildt <HYPERLINK "mailto:dwildt% <dwildt%25>40gmail.-com
Post by Daniel Wildt
And how do you guys translate story points to the real time?
Are you guys using some kind of load factor calculation?
ideal hours x load factor = expected time
Regards,
Daniel Wildt
HYPERLINK "HYPERLINK "HYPERLINK "http://danielwildt.blogspot.com"http://danielwildt.-blogspot.-com"
HYPERLINK "http://danielwildt.-blogspot.-com"http://danielwildt.--blogspot.--com"HYPERLINK
"HYPERLINK "http://danielwildt.blogspot.com"http://danielwildt.-blogspot.-com"HYPERLINK
"http://danielwildt.-blogspot.-com"http://danielwildt.--blogspot.--com
Post by Daniel Wildt
Post by Daniel Wildt
_____
De: HYPERLINK
"mailto:extremeprog-ramming%40yahoog-roups.com
Post by Daniel Wildt
HYPERLINK "mailto:extremeprog-ramming%40yahoog-roups.com
<extremeprogramming--%40yahoogroups.--com>]
Post by Daniel Wildt
Em nome de Steven Gordon
Enviada em: segunda-feira, 21 de maio de 2007 15:04
Para: HYPERLINK
"mailto:extremeprog-ramming%40yahoog-roups.com
Post by Daniel Wildt
Assunto: Re: [XP] Estimation: Time or Size?
I have been recommending that teams obtain the best advantages of both real
time and abstract estimation by using story points for release planning
(
Post by Daniel Wildt
i.e.,
the product backlog) and real time estimation for sprint/iteration planning
(i.e., the task board).
This allows for long-term calibration of story points to avoid
continuous
Post by Daniel Wildt
re-estimation of stories and support a meaningful interpretation of evolving
velocities. It also allows for improving real time estimation of what
can
Post by Daniel Wildt
be finished on a sprint by sprint basis.
Steve Gordon
On 5/21/07, Tobias Mayer <HYPERLINK "mailto:tobyanon% <tobyanon%25>-<tobyanon%-25>
Post by Tobias Mayer
I have recently come across a few people in the Agile field who prefer
estimating in "real time" over estimating in size (e.g. story points);
I
Post by Daniel Wildt
Post by Tobias Mayer
have even heard statements such as: the most advanced implementations
of
Post by Daniel Wildt
Post by Tobias Mayer
Agile use real time estimates, because it offers the most powerful
benefits.
Post by Tobias Mayer
It intrigued me, so I wrote a blog about it: Estimation: Time or Size?
Has anyone on this list found that real time estimation is useful in
an
Post by Daniel Wildt
Post by Tobias Mayer
Agile context (actually, in any context)? I'd be very interested to
hear
Post by Daniel Wildt
Post by Tobias Mayer
about it. Thanks.
Tobias Mayer
HYPERLINK "HYPERLINK "HYPERLINK "http://agilethinking.net"http://agilethinkin-g.net"
HYPERLINK "http://agilethinkin-g.net"http://agilethinkin--g.net"HYPERLINK
"HYPERLINK "http://agilethinkin-g.net"http://agilethinkin--g.net"HYPERLINK "http://agilethinkin--g.net"http://agilethinkin---g.net
Post by Daniel Wildt
Post by Tobias Mayer
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]
No virus found in this incoming message.
Checked by AVG Free Edition.
21/05/2007
Post by Daniel Wildt
14:01
No virus found in this outgoing message.
Checked by AVG Free Edition.
21/05/2007
Post by Daniel Wildt
14:01
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.467 / Virus Database: 269.7.6/814 - Release Date: 21/05/2007 14:01
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.467 / Virus Database: 269.7.6/814 - Release Date: 21/05/2007 14:01
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]






No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.467 / Virus Database: 269.7.6/814 - Release Date: 21/05/2007 14:01



No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.467 / Virus Database: 269.7.6/814 - Release Date: 21/05/2007 14:01



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



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Ron Jeffries
2007-05-22 02:05:08 UTC
Permalink
Post by Daniel Wildt
I measure the number of functionalities inside an iteration by
velocity too, but I also use load
factor calculation.
This is because I have cases where I don't have developers 100%
available to code in the project, so
one can be 50% available to the
project, and other can be only focused on the project, so 100%.
Do you guys agree with the possibility to use load factor calculation?
Some of you see that practice as something useful?
I used to like load factor. My feeling now is that, as simple as it
is, it is more than is needed, and probably less accurate than it
would need to be to be really useful. I could be wrong of course ...

Ron Jeffries
www.XProgramming.com
The rules are ways of thinking, not ways to avoid thinking.



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Daniel Wildt
2007-05-22 02:45:25 UTC
Permalink
Hi Ron,

I'm thinking about using only velocity in next projects, so I can measure how I manage that without considering load factor.

Sometimes it's difficult to have 100% full time developers on the project, so I always go for load factor calculation to help me.
It works for me pretty well, but as you said in other message, let's try to make it simple.

Regards,
Daniel Wildt
HYPERLINK "http://danielwildt.blogspot.com"http://danielwildt.blogspot.com






_____

De: ***@yahoogroups.com [mailto:***@yahoogroups.com] Em nome de Ron Jeffries
Enviada em: segunda-feira, 21 de maio de 2007 23:05
Para: ***@yahoogroups.com
Assunto: Re: RES: [XP] Estimation: Time or Size?
Post by Daniel Wildt
I measure the number of functionalities inside an iteration by
velocity too, but I also use load
factor calculation.
This is because I have cases where I don't have developers 100%
available to code in the project, so
one can be 50% available to the
project, and other can be only focused on the project, so 100%.
Do you guys agree with the possibility to use load factor calculation?
Some of you see that practice as something useful?
I used to like load factor. My feeling now is that, as simple as it
is, it is more than is needed, and probably less accurate than it
would need to be to be really useful. I could be wrong of course ...

Ron Jeffries
www.XProgramming.-com
The rules are ways of thinking, not ways to avoid thinking.






No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.467 / Virus Database: 269.7.6/814 - Release Date: 21/05/2007 14:01



No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.467 / Virus Database: 269.7.6/814 - Release Date: 21/05/2007 14:01



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



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Paul Campbell
2007-05-22 12:30:10 UTC
Permalink
Post by Daniel Wildt
I measure the number of functionalities inside an iteration by
velocity too, but I also use load factor calculation.
Post by Daniel Wildt
This is because I have cases where I don't have developers 100%
available to code in the project, so one can be 50% available to the
Post by Daniel Wildt
project, and other can be only focused on the project, so 100%.
Do you guys agree with the possibility to use load factor calculation?
Some of you see that practice as something useful?
Regards,
Daniel Wildt
Using a load factor seems reasonable in this case. Or you can scale the
velocity up or down by the same proportion as the resource availibity
change e.g. if your a 4 man team and one of your devs gets 50%
allocated to another project then youve effectively lost 1/8th of your
velocity. Still I guess it amounts to the same thing really.

However all these approaches to dynamic resourcing have the same
pitfalls such as not taking into account the "thrashing" overhead of
someone attempting to work on two projects, overhead of a new person on
the team etc etc to the point where its sometimes easiest to just
ignore small changes in resourcing between iterations and just assume
they will average out i.e. revert back to a plain old velocity
calculation.

Paul.






To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
dnicolet99
2007-05-22 12:45:43 UTC
Permalink
Post by Daniel Wildt
Post by Daniel Wildt
I measure the number of functionalities inside an iteration by
velocity too, but I also use load factor calculation.
Post by Daniel Wildt
This is because I have cases where I don't have developers 100%
available to code in the project, so one can be 50% available to the
Post by Daniel Wildt
project, and other can be only focused on the project, so 100%.
Do you guys agree with the possibility to use load factor calculation?
Some of you see that practice as something useful?
Regards,
Daniel Wildt
Using a load factor seems reasonable in this case. Or you can scale the
velocity up or down by the same proportion as the resource availibity
change e.g. if your a 4 man team and one of your devs gets 50%
allocated to another project then youve effectively lost 1/8th of your
velocity. Still I guess it amounts to the same thing really.
I see what you mean, but I guess I'm still sort of stalled on the idea
of having a developer assigned to multiple projects concurrently.
Scaling the velocity figure sounds more like a band-aid for that
problem than a useful way to track progress. Wouldn't it all be
simpler if you could get a dedicated team for the project?
Post by Daniel Wildt
However all these approaches to dynamic resourcing have the same
pitfalls such as not taking into account the "thrashing" overhead of
someone attempting to work on two projects, overhead of a new person on
the team etc etc to the point where its sometimes easiest to just
ignore small changes in resourcing between iterations and just assume
they will average out i.e. revert back to a plain old velocity
calculation.
Paul.
I think that's on the right track. When I've been in situations where
management assigned developers to multiple projects, I would track
velocity as per normal, and when variances occurred as a result of
people (not "resources") being shifted to other work I would try to
shine a spotlight on that to demonstrate that things really move along
better when you have dedicated teams.

IOW rather than trying to make the velocity look as smooth as possible
under the circumstances, I would let the circumstances drive extreme
variances in velocity as a means to show the effect of splitting
people's time across projects. The real solution is to teach
management that people shouldn't be assigned to multiple projects
concurrently. Otherwise, we'll just have the same problem over and
over again.

Dave




To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
dnicolet99
2007-05-21 23:39:19 UTC
Permalink
+1.

I've observed teams that are relatively new to agile methods tend to
"want" to convert points to time; they seem to be pulled naturally in
that direction. I suspect it's because they've been estimating in
terms of time for so long it feels odd to them to use a different
approach.

Dave
Post by Steven Gordon
There is no need to translate story points to real time.
One uses velocity (the moving average of how many story points a team
completely finishes per iteration) to periodically forecast how many story
points worth of functionality is likely to get done by the next release date
in order to periodically revise the release plan (i.e., what will make it
into the release).
Steve
Post by Daniel Wildt
And how do you guys translate story points to the real time?
Are you guys using some kind of load factor calculation?
ideal hours x load factor = expected time
Regards,
Daniel Wildt
HYPERLINK
"http://danielwildt.blogspot.com"http://danielwildt.blogspot.com
Post by Steven Gordon
Post by Daniel Wildt
_____
<extremeprogramming%40yahoogroups.com>]
Post by Steven Gordon
Post by Daniel Wildt
Em nome de Steven Gordon
Enviada em: segunda-feira, 21 de maio de 2007 15:04
Assunto: Re: [XP] Estimation: Time or Size?
I have been recommending that teams obtain the best advantages of both real
time and abstract estimation by using story points for release planning (
i.e.,
the product backlog) and real time estimation for sprint/iteration planning
(i.e., the task board).
This allows for long-term calibration of story points to avoid continuous
re-estimation of stories and support a meaningful interpretation of evolving
velocities. It also allows for improving real time estimation of what can
be finished on a sprint by sprint basis.
Steve Gordon
On 5/21/07, Tobias Mayer <HYPERLINK "mailto:tobyanon% <tobyanon%25>
Post by Tobias Mayer
I have recently come across a few people in the Agile field who prefer
estimating in "real time" over estimating in size (e.g. story points); I
have even heard statements such as: the most advanced
implementations of
Post by Steven Gordon
Post by Daniel Wildt
Post by Tobias Mayer
Agile use real time estimates, because it offers the most powerful
benefits.
Post by Tobias Mayer
It intrigued me, so I wrote a blog about it: Estimation: Time or Size?
Has anyone on this list found that real time estimation is
useful in an
Post by Steven Gordon
Post by Daniel Wildt
Post by Tobias Mayer
Agile context (actually, in any context)? I'd be very interested to hear
about it. Thanks.
Tobias Mayer
HYPERLINK "http://agilethinking.net"http://agilethinkin-g.net
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]
No virus found in this incoming message.
Checked by AVG Free Edition.
21/05/2007
Post by Steven Gordon
Post by Daniel Wildt
14:01
No virus found in this outgoing message.
Checked by AVG Free Edition.
21/05/2007
Post by Steven Gordon
Post by Daniel Wildt
14:01
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]
To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Daniel Wildt
2007-05-21 23:55:30 UTC
Permalink
I agree with you Dave.

But you follow that approach even if your developers does not have 100% of their time available to the project?
In my current situation, some developers are not fully assigned to the project having only 4 hours (50%) per day to work.

If I set 5 hours as an estimate, the developer it will take 2 days for the developer to finish that task.

Using load factor I feel more confortable to measure time available to setup the iteration.

Do you still think it is useful to use simple story points for that? How do you work with that kind of situation?

Regards,
Daniel Wildt
HYPERLINK "http://danielwildt.blogspot.com"http://danielwildt.blogspot.com





_____

De: ***@yahoogroups.com [mailto:***@yahoogroups.com] Em nome de dnicolet99
Enviada em: segunda-feira, 21 de maio de 2007 20:39
Para: ***@yahoogroups.com
Assunto: Re: [XP] Estimation: Time or Size?



+1.

I've observed teams that are relatively new to agile methods tend to
"want" to convert points to time; they seem to be pulled naturally in
that direction. I suspect it's because they've been estimating in
terms of time for so long it feels odd to them to use a different
approach.

Dave
Post by Steven Gordon
There is no need to translate story points to real time.
One uses velocity (the moving average of how many story points a team
completely finishes per iteration) to periodically forecast how many story
points worth of functionality is likely to get done by the next release date
in order to periodically revise the release plan (i.e., what will make it
into the release).
Steve
Post by Daniel Wildt
And how do you guys translate story points to the real time?
Are you guys using some kind of load factor calculation?
ideal hours x load factor = expected time
Regards,
Daniel Wildt
HYPERLINK
"HYPERLINK "http://danielwildt.blogspot.com"http://danielwildt.-blogspot.-com"HYPERLINK
"http://danielwildt.blogspot.com"http://danielwildt.-blogspot.-com
Post by Steven Gordon
Post by Daniel Wildt
_____
HYPERLINK
<extremeprogramming-%40yahoogroups.-com>]
Post by Steven Gordon
Post by Daniel Wildt
Em nome de Steven Gordon
Enviada em: segunda-feira, 21 de maio de 2007 15:04
Assunto: Re: [XP] Estimation: Time or Size?
I have been recommending that teams obtain the best advantages of both real
time and abstract estimation by using story points for release planning (
i.e.,
the product backlog) and real time estimation for sprint/iteration planning
(i.e., the task board).
This allows for long-term calibration of story points to avoid continuous
re-estimation of stories and support a meaningful interpretation of evolving
velocities. It also allows for improving real time estimation of what can
be finished on a sprint by sprint basis.
Steve Gordon
On 5/21/07, Tobias Mayer <HYPERLINK "mailto:tobyanon% <tobyanon%25>
Post by Tobias Mayer
I have recently come across a few people in the Agile field who prefer
estimating in "real time" over estimating in size (e.g. story points); I
have even heard statements such as: the most advanced
implementations of
Post by Steven Gordon
Post by Daniel Wildt
Post by Tobias Mayer
Agile use real time estimates, because it offers the most powerful
benefits.
Post by Tobias Mayer
It intrigued me, so I wrote a blog about it: Estimation: Time or Size?
Has anyone on this list found that real time estimation is
useful in an
Post by Steven Gordon
Post by Daniel Wildt
Post by Tobias Mayer
Agile context (actually, in any context)? I'd be very interested to hear
about it. Thanks.
Tobias Mayer
HYPERLINK "HYPERLINK "http://agilethinking.net"http://agilethinkin-g.net"HYPERLINK
"http://agilethinkin-g.net"http://agilethinkin--g.net
Post by Steven Gordon
Post by Daniel Wildt
Post by Tobias Mayer
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]
No virus found in this incoming message.
Checked by AVG Free Edition.
21/05/2007
Post by Steven Gordon
Post by Daniel Wildt
14:01
No virus found in this outgoing message.
Checked by AVG Free Edition.
21/05/2007
Post by Steven Gordon
Post by Daniel Wildt
14:01
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.467 / Virus Database: 269.7.6/814 - Release Date: 21/05/2007 14:01



No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.467 / Virus Database: 269.7.6/814 - Release Date: 21/05/2007 14:01



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



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
dnicolet99
2007-05-22 00:00:51 UTC
Permalink
Post by Daniel Wildt
I agree with you Dave.
But you follow that approach even if your developers does not have
100% of their time available to the project?
Post by Daniel Wildt
In my current situation, some developers are not fully assigned to
the project having only 4 hours (50%) per day to work.

IMO that's a separate problem. It's something I would call a "process
smell." Developers should not be assigned to multiple projects
concurrently. That's one of the fundamental errors in traditional
project management.

In fact, I think this is a more fundamental problem than the question
of whether to use points or time. The latter question is sort of a
refinement of agile practices. The former question is a prerequisite
to agile practices. First things first.

Dave
Post by Daniel Wildt
If I set 5 hours as an estimate, the developer it will take 2 days
for the developer to finish that task.
Post by Daniel Wildt
Using load factor I feel more confortable to measure time available to setup the iteration.
Do you still think it is useful to use simple story points for that?
How do you work with that kind of situation?
Post by Daniel Wildt
Regards,
Daniel Wildt
HYPERLINK
"http://danielwildt.blogspot.com"http://danielwildt.blogspot.com
Post by Daniel Wildt
_____
Enviada em: segunda-feira, 21 de maio de 2007 20:39
Assunto: Re: [XP] Estimation: Time or Size?
+1.
I've observed teams that are relatively new to agile methods tend to
"want" to convert points to time; they seem to be pulled naturally in
that direction. I suspect it's because they've been estimating in
terms of time for so long it feels odd to them to use a different
approach.
Dave
--- In HYPERLINK
"mailto:extremeprogramming%40yahoogroups.com"***@...,
"Steven Gordon"
Post by Daniel Wildt
Post by Steven Gordon
There is no need to translate story points to real time.
One uses velocity (the moving average of how many story points a team
completely finishes per iteration) to periodically forecast how many
story
Post by Steven Gordon
points worth of functionality is likely to get done by the next
release date
Post by Steven Gordon
in order to periodically revise the release plan (i.e., what will
make it
Post by Steven Gordon
into the release).
Steve
Post by Daniel Wildt
And how do you guys translate story points to the real time?
Are you guys using some kind of load factor calculation?
ideal hours x load factor = expected time
Regards,
Daniel Wildt
HYPERLINK
"HYPERLINK
"http://danielwildt.blogspot.com"http://danielwildt.-blogspot.-com"HYPERLINK
Post by Daniel Wildt
"http://danielwildt.blogspot.com"http://danielwildt.-blogspot.-com
Post by Steven Gordon
Post by Daniel Wildt
_____
HYPERLINK
Post by Steven Gordon
Post by Daniel Wildt
HYPERLINK
<extremeprogramming-%40yahoogroups.-com>]
Post by Steven Gordon
Post by Daniel Wildt
Em nome de Steven Gordon
Enviada em: segunda-feira, 21 de maio de 2007 15:04
HYPERLINK
Post by Steven Gordon
Post by Daniel Wildt
Assunto: Re: [XP] Estimation: Time or Size?
I have been recommending that teams obtain the best advantages
of both
Post by Daniel Wildt
Post by Steven Gordon
Post by Daniel Wildt
real
time and abstract estimation by using story points for release
planning (
Post by Steven Gordon
Post by Daniel Wildt
i.e.,
the product backlog) and real time estimation for sprint/iteration planning
(i.e., the task board).
This allows for long-term calibration of story points to avoid
continuous
Post by Steven Gordon
Post by Daniel Wildt
re-estimation of stories and support a meaningful interpretation of evolving
velocities. It also allows for improving real time estimation of
what can
Post by Steven Gordon
Post by Daniel Wildt
be finished on a sprint by sprint basis.
Steve Gordon
On 5/21/07, Tobias Mayer <HYPERLINK "mailto:tobyanon% <tobyanon%25>
Post by Tobias Mayer
I have recently come across a few people in the Agile field who
prefer
Post by Steven Gordon
Post by Daniel Wildt
Post by Tobias Mayer
estimating in "real time" over estimating in size (e.g. story
points); I
Post by Steven Gordon
Post by Daniel Wildt
Post by Tobias Mayer
have even heard statements such as: the most advanced
implementations of
Post by Steven Gordon
Post by Daniel Wildt
Post by Tobias Mayer
Agile use real time estimates, because it offers the most powerful
benefits.
Post by Tobias Mayer
It intrigued me, so I wrote a blog about it: Estimation: Time or
Size?
Post by Steven Gordon
Post by Daniel Wildt
Post by Tobias Mayer
Has anyone on this list found that real time estimation is
useful in an
Post by Steven Gordon
Post by Daniel Wildt
Post by Tobias Mayer
Agile context (actually, in any context)? I'd be very interested
to hear
Post by Steven Gordon
Post by Daniel Wildt
Post by Tobias Mayer
about it. Thanks.
Tobias Mayer
HYPERLINK "HYPERLINK
"http://agilethinking.net"http://agilethinkin-g.net"HYPERLINK
Post by Daniel Wildt
"http://agilethinkin-g.net"http://agilethinkin--g.net
Post by Steven Gordon
Post by Daniel Wildt
Post by Tobias Mayer
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]
No virus found in this incoming message.
Checked by AVG Free Edition.
21/05/2007
Post by Steven Gordon
Post by Daniel Wildt
14:01
No virus found in this outgoing message.
Checked by AVG Free Edition.
21/05/2007
Post by Steven Gordon
Post by Daniel Wildt
14:01
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]
No virus found in this incoming message.
Checked by AVG Free Edition.
21/05/2007 14:01
Post by Daniel Wildt
No virus found in this outgoing message.
Checked by AVG Free Edition.
21/05/2007 14:01
Post by Daniel Wildt
[Non-text portions of this message have been removed]
To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Daniel Wildt
2007-05-22 03:21:50 UTC
Permalink
I agree with you again, maybe it's a process smell,
but with load factor calculation it is working fine
for me. I need to adapt the whole thing to my
current state to help the management process.

But as I said in other message, I will try to change
and use only velocity calculation to measure.

I need to make things simpler than they are
currently. This could be the first thing to
try.

Regards,
Daniel Wildt
HYPERLINK "http://danielwildt.blogspot.com"http://danielwildt.blogspot.com






_____

De: ***@yahoogroups.com [mailto:***@yahoogroups.com] Em nome de dnicolet99
Enviada em: segunda-feira, 21 de maio de 2007 21:01
Para: ***@yahoogroups.com
Assunto: Re: RES: [XP] Estimation: Time or Size?
Post by Daniel Wildt
I agree with you Dave.
But you follow that approach even if your developers does not have
100% of their time available to the project?
Post by Daniel Wildt
In my current situation, some developers are not fully assigned to
the project having only 4 hours (50%) per day to work.

IMO that's a separate problem. It's something I would call a "process
smell." Developers should not be assigned to multiple projects
concurrently. That's one of the fundamental errors in traditional
project management.

In fact, I think this is a more fundamental problem than the question
of whether to use points or time. The latter question is sort of a
refinement of agile practices. The former question is a prerequisite
to agile practices. First things first.

Dave
Post by Daniel Wildt
If I set 5 hours as an estimate, the developer it will take 2 days
for the developer to finish that task.
Post by Daniel Wildt
Using load factor I feel more confortable to measure time available to setup the iteration.
Do you still think it is useful to use simple story points for that?
How do you work with that kind of situation?
Post by Daniel Wildt
Regards,
Daniel Wildt
HYPERLINK
"HYPERLINK "http://danielwildt.blogspot.com"http://danielwildt.-blogspot.-com"HYPERLINK
"http://danielwildt.blogspot.com"http://danielwildt.-blogspot.-com
Post by Daniel Wildt
_____
Enviada em: segunda-feira, 21 de maio de 2007 20:39
Assunto: Re: [XP] Estimation: Time or Size?
+1.
I've observed teams that are relatively new to agile methods tend to
"want" to convert points to time; they seem to be pulled naturally in
that direction. I suspect it's because they've been estimating in
terms of time for so long it feels odd to them to use a different
approach.
Dave
--- In HYPERLINK
"mailto:extremeprog-ramming%40yahoog-roups.com"-extremeprogrammi-***@...,
"Steven Gordon"
Post by Daniel Wildt
Post by Steven Gordon
There is no need to translate story points to real time.
One uses velocity (the moving average of how many story points a team
completely finishes per iteration) to periodically forecast how many
story
Post by Steven Gordon
points worth of functionality is likely to get done by the next
release date
Post by Steven Gordon
in order to periodically revise the release plan (i.e., what will
make it
Post by Steven Gordon
into the release).
Steve
Post by Daniel Wildt
And how do you guys translate story points to the real time?
Are you guys using some kind of load factor calculation?
ideal hours x load factor = expected time
Regards,
Daniel Wildt
HYPERLINK
"HYPERLINK
"HYPERLINK "http://danielwildt.blogspot.com"http://danielwildt.-blogspot.-com"HYPERLINK
"http://danielwildt.-blogspot.-com"http://danielwildt.--blogspot.--com"HYPERLINK
Post by Daniel Wildt
"HYPERLINK "http://danielwildt.blogspot.com"http://danielwildt.-blogspot.-com"HYPERLINK
"http://danielwildt.-blogspot.-com"http://danielwildt.--blogspot.--com
Post by Daniel Wildt
Post by Steven Gordon
Post by Daniel Wildt
_____
HYPERLINK
Post by Steven Gordon
Post by Daniel Wildt
HYPERLINK
<extremeprogramming--%40yahoogroups.--com>]
Post by Steven Gordon
Post by Daniel Wildt
Em nome de Steven Gordon
Enviada em: segunda-feira, 21 de maio de 2007 15:04
HYPERLINK
Post by Steven Gordon
Post by Daniel Wildt
Assunto: Re: [XP] Estimation: Time or Size?
I have been recommending that teams obtain the best advantages
of both
Post by Daniel Wildt
Post by Steven Gordon
Post by Daniel Wildt
real
time and abstract estimation by using story points for release
planning (
Post by Steven Gordon
Post by Daniel Wildt
i.e.,
the product backlog) and real time estimation for sprint/iteration planning
(i.e., the task board).
This allows for long-term calibration of story points to avoid
continuous
Post by Steven Gordon
Post by Daniel Wildt
re-estimation of stories and support a meaningful interpretation of evolving
velocities. It also allows for improving real time estimation of
what can
Post by Steven Gordon
Post by Daniel Wildt
be finished on a sprint by sprint basis.
Steve Gordon
On 5/21/07, Tobias Mayer <HYPERLINK "mailto:tobyanon% <tobyanon%25>
Post by Tobias Mayer
I have recently come across a few people in the Agile field who
prefer
Post by Steven Gordon
Post by Daniel Wildt
Post by Tobias Mayer
estimating in "real time" over estimating in size (e.g. story
points); I
Post by Steven Gordon
Post by Daniel Wildt
Post by Tobias Mayer
have even heard statements such as: the most advanced
implementations of
Post by Steven Gordon
Post by Daniel Wildt
Post by Tobias Mayer
Agile use real time estimates, because it offers the most powerful
benefits.
Post by Tobias Mayer
It intrigued me, so I wrote a blog about it: Estimation: Time or
Size?
Post by Steven Gordon
Post by Daniel Wildt
Post by Tobias Mayer
Has anyone on this list found that real time estimation is
useful in an
Post by Steven Gordon
Post by Daniel Wildt
Post by Tobias Mayer
Agile context (actually, in any context)? I'd be very interested
to hear
Post by Steven Gordon
Post by Daniel Wildt
Post by Tobias Mayer
about it. Thanks.
Tobias Mayer
HYPERLINK "HYPERLINK
"HYPERLINK "http://agilethinking.net"http://agilethinkin-g.net"HYPERLINK
"http://agilethinkin-g.net"http://agilethinkin--g.net"HYPERLINK
Post by Daniel Wildt
"HYPERLINK "http://agilethinkin-g.net"http://agilethinkin--g.net"HYPERLINK "http://agilethinkin--g.net"http://agilethinkin---g.net
Post by Steven Gordon
Post by Daniel Wildt
Post by Tobias Mayer
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]
No virus found in this incoming message.
Checked by AVG Free Edition.
21/05/2007
Post by Steven Gordon
Post by Daniel Wildt
14:01
No virus found in this outgoing message.
Checked by AVG Free Edition.
21/05/2007
Post by Steven Gordon
Post by Daniel Wildt
14:01
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]
No virus found in this incoming message.
Checked by AVG Free Edition.
21/05/2007 14:01
Post by Daniel Wildt
No virus found in this outgoing message.
Checked by AVG Free Edition.
21/05/2007 14:01
Post by Daniel Wildt
[Non-text portions of this message have been removed]
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.467 / Virus Database: 269.7.6/814 - Release Date: 21/05/2007 14:01



No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.467 / Virus Database: 269.7.6/814 - Release Date: 21/05/2007 14:01



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



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Manuel Klimek
2007-05-22 05:53:34 UTC
Permalink
Daniel,

in the "Hours vs. Points" thread the conclusion was (at least
for me) that it's very good to use real time estimates, if you're
able to /commit/ to real time estimates. This means that your
estimates are so good that you don't have a big standard
deviation.

If you're bad at estimating and the probability is small that
you get any better anytime soon (for example, if your new tasks
differ a lot from what you already did) than I'd prefer
estimating in points. It resolved a few issues at the shop I work at.

I wrote a short blog entry about time estimates:
http://klimek.box4.net/blog/2007/05/16/the-perfect-engineering-lie/

Cheers,
Manuel
Post by Daniel Wildt
I agree with you again, maybe it's a process smell,
but with load factor calculation it is working fine
for me. I need to adapt the whole thing to my
current state to help the management process.
But as I said in other message, I will try to change
and use only velocity calculation to measure.
I need to make things simpler than they are
currently. This could be the first thing to
try.
Regards,
Daniel Wildt
HYPERLINK "http://danielwildt.blogspot.com"http://danielwildt.blogspot.com
_____
Enviada em: segunda-feira, 21 de maio de 2007 21:01
Assunto: Re: RES: [XP] Estimation: Time or Size?
Post by Daniel Wildt
I agree with you Dave.
But you follow that approach even if your developers does not have
100% of their time available to the project?
Post by Daniel Wildt
In my current situation, some developers are not fully assigned to
the project having only 4 hours (50%) per day to work.
IMO that's a separate problem. It's something I would call a "process
smell." Developers should not be assigned to multiple projects
concurrently. That's one of the fundamental errors in traditional
project management.
In fact, I think this is a more fundamental problem than the question
of whether to use points or time. The latter question is sort of a
refinement of agile practices. The former question is a prerequisite
to agile practices. First things first.
Dave
Post by Daniel Wildt
If I set 5 hours as an estimate, the developer it will take 2 days
for the developer to finish that task.
Post by Daniel Wildt
Using load factor I feel more confortable to measure time available
to setup the iteration.
Post by Daniel Wildt
Do you still think it is useful to use simple story points for that?
How do you work with that kind of situation?
Post by Daniel Wildt
Regards,
Daniel Wildt
HYPERLINK
"HYPERLINK "http://danielwildt.blogspot.com"http://danielwildt.-blogspot.-com"HYPERLINK
"http://danielwildt.blogspot.com"http://danielwildt.-blogspot.-com
Post by Daniel Wildt
_____
Enviada em: segunda-feira, 21 de maio de 2007 20:39
Assunto: Re: [XP] Estimation: Time or Size?
+1.
I've observed teams that are relatively new to agile methods tend to
"want" to convert points to time; they seem to be pulled naturally in
that direction. I suspect it's because they've been estimating in
terms of time for so long it feels odd to them to use a different
approach.
Dave
--- In HYPERLINK
"Steven Gordon"
Post by Daniel Wildt
Post by Steven Gordon
There is no need to translate story points to real time.
One uses velocity (the moving average of how many story points a team
completely finishes per iteration) to periodically forecast how many
story
Post by Steven Gordon
points worth of functionality is likely to get done by the next
release date
Post by Steven Gordon
in order to periodically revise the release plan (i.e., what will
make it
Post by Steven Gordon
into the release).
Steve
Post by Daniel Wildt
And how do you guys translate story points to the real time?
Are you guys using some kind of load factor calculation?
ideal hours x load factor = expected time
Regards,
Daniel Wildt
HYPERLINK
"HYPERLINK
"HYPERLINK "http://danielwildt.blogspot.com"http://danielwildt.-blogspot.-com"HYPERLINK
"http://danielwildt.-blogspot.-com"http://danielwildt.--blogspot.--com"HYPERLINK
Post by Daniel Wildt
"HYPERLINK "http://danielwildt.blogspot.com"http://danielwildt.-blogspot.-com"HYPERLINK
"http://danielwildt.-blogspot.-com"http://danielwildt.--blogspot.--com
Post by Daniel Wildt
Post by Steven Gordon
Post by Daniel Wildt
_____
HYPERLINK
Post by Steven Gordon
Post by Daniel Wildt
HYPERLINK
<extremeprogramming--%40yahoogroups.--com>]
Post by Steven Gordon
Post by Daniel Wildt
Em nome de Steven Gordon
Enviada em: segunda-feira, 21 de maio de 2007 15:04
HYPERLINK
Post by Steven Gordon
Post by Daniel Wildt
Assunto: Re: [XP] Estimation: Time or Size?
I have been recommending that teams obtain the best advantages
of both
Post by Daniel Wildt
Post by Steven Gordon
Post by Daniel Wildt
real
time and abstract estimation by using story points for release
planning (
Post by Steven Gordon
Post by Daniel Wildt
i.e.,
the product backlog) and real time estimation for sprint/iteration planning
(i.e., the task board).
This allows for long-term calibration of story points to avoid
continuous
Post by Steven Gordon
Post by Daniel Wildt
re-estimation of stories and support a meaningful interpretation of evolving
velocities. It also allows for improving real time estimation of
what can
Post by Steven Gordon
Post by Daniel Wildt
be finished on a sprint by sprint basis.
Steve Gordon
On 5/21/07, Tobias Mayer <HYPERLINK "mailto:tobyanon% <tobyanon%25>
Post by Tobias Mayer
I have recently come across a few people in the Agile field who
prefer
Post by Steven Gordon
Post by Daniel Wildt
Post by Tobias Mayer
estimating in "real time" over estimating in size (e.g. story
points); I
Post by Steven Gordon
Post by Daniel Wildt
Post by Tobias Mayer
have even heard statements such as: the most advanced
implementations of
Post by Steven Gordon
Post by Daniel Wildt
Post by Tobias Mayer
Agile use real time estimates, because it offers the most powerful
benefits.
Post by Tobias Mayer
It intrigued me, so I wrote a blog about it: Estimation: Time or
Size?
Post by Steven Gordon
Post by Daniel Wildt
Post by Tobias Mayer
Has anyone on this list found that real time estimation is
useful in an
Post by Steven Gordon
Post by Daniel Wildt
Post by Tobias Mayer
Agile context (actually, in any context)? I'd be very interested
to hear
Post by Steven Gordon
Post by Daniel Wildt
Post by Tobias Mayer
about it. Thanks.
Tobias Mayer
HYPERLINK "HYPERLINK
"HYPERLINK "http://agilethinking.net"http://agilethinkin-g.net"HYPERLINK
"http://agilethinkin-g.net"http://agilethinkin--g.net"HYPERLINK
Post by Daniel Wildt
"HYPERLINK "http://agilethinkin-g.net"http://agilethinkin--g.net"HYPERLINK "http://agilethinkin--g.net"http://agilethinkin---g.net
Post by Steven Gordon
Post by Daniel Wildt
Post by Tobias Mayer
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]
No virus found in this incoming message.
Checked by AVG Free Edition.
21/05/2007
Post by Steven Gordon
Post by Daniel Wildt
14:01
No virus found in this outgoing message.
Checked by AVG Free Edition.
21/05/2007
Post by Steven Gordon
Post by Daniel Wildt
14:01
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]
No virus found in this incoming message.
Checked by AVG Free Edition.
21/05/2007 14:01
Post by Daniel Wildt
No virus found in this outgoing message.
Checked by AVG Free Edition.
21/05/2007 14:01
Post by Daniel Wildt
[Non-text portions of this message have been removed]
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.467 / Virus Database: 269.7.6/814 - Release Date: 21/05/2007 14:01
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.467 / Virus Database: 269.7.6/814 - Release Date: 21/05/2007 14:01
[Non-text portions of this message have been removed]
--
http://klimek.box4.net


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Ron Jeffries
2007-05-22 13:44:08 UTC
Permalink
Post by Manuel Klimek
in the "Hours vs. Points" thread the conclusion was (at least
for me) that it's very good to use real time estimates, if you're
able to /commit/ to real time estimates. This means that your
estimates are so good that you don't have a big standard
deviation.
If you're bad at estimating and the probability is small that
you get any better anytime soon (for example, if your new tasks
differ a lot from what you already did) than I'd prefer
estimating in points. It resolved a few issues at the shop I work at.
It seems to me that one can commit in either format. The important
thing is to recognize that an estimate /is supposed to be/ a range
of dates or feature counts, and a commitment is a point in time or
count. So one would commit, I suppose, toward the pessimistic side
of the estimate.

Ron Jeffries
www.XProgramming.com
You can observe a lot by watching. --Yogi Berra



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Manuel Klimek
2007-05-22 19:20:43 UTC
Permalink
Ron,
Post by Ron Jeffries
Post by Manuel Klimek
in the "Hours vs. Points" thread the conclusion was (at least
for me) that it's very good to use real time estimates, if you're
able to /commit/ to real time estimates. This means that your
estimates are so good that you don't have a big standard
deviation.
If you're bad at estimating and the probability is small that
you get any better anytime soon (for example, if your new tasks
differ a lot from what you already did) than I'd prefer
estimating in points. It resolved a few issues at the shop I work at.
It seems to me that one can commit in either format. The important
thing is to recognize that an estimate /is supposed to be/ a range
of dates or feature counts, and a commitment is a point in time or
count. So one would commit, I suppose, toward the pessimistic side
of the estimate.
Hm. Kent and Chris both said in the other thread that for them
time is just time, so no load factor involved. IIRC they both said
that they don't think there's much randomness involved in the
process.
If you want to keep the "time is time" commitment than you
don't have a load factor. All that could be used to account
for randomness in this case is some slack. But if I use enough
slack to avoid missing dates I would commit to very
pessimistic dates.
On the other hand if I use points and the law of big numbers to
make up for my randomness, I only have to be good at estimating
expected values, and I'll get pretty good commitments. Of course
you can do this with both points and "perfect time", but I have
problems communicating two different "time scales" (and other
reasons to prefer points if "perfect time" is not the same as
"real time")

Cheers,
Manuel
--
http://klimek.box4.net


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Ron Jeffries
2007-05-29 22:09:03 UTC
Permalink
Post by Manuel Klimek
Post by Ron Jeffries
It seems to me that one can commit in either format. The important
thing is to recognize that an estimate /is supposed to be/ a range
of dates or feature counts, and a commitment is a point in time or
count. So one would commit, I suppose, toward the pessimistic side
of the estimate.
Hm. Kent and Chris both said in the other thread that for them
time is just time, so no load factor involved. IIRC they both said
that they don't think there's much randomness involved in the
process.
Yes. And both used two different times in their description:
1. I will work four hours on this;
2. I will give it to you by Tuesday.

#2 = #1 * Load Factor. If you want to predict a batch of stories, I
think load factor is a valuable way to do it, because I find that
people are not very good at estimating the actual duration of a lare
chunk of work.

Now mind you, I'm all for committing "I'll give it to you by
Tuesday," and I personally estimate everything I do in actual time.

Unlike those two individuals, however, I find that my estimates of
how long something will take in work time are quite often wrong. If
they are saying that they are rarely wrong about work time to do
things, then I am impressed and would like to know how they do it.
Post by Manuel Klimek
If you want to keep the "time is time" commitment than you
don't have a load factor. All that could be used to account
for randomness in this case is some slack. But if I use enough
slack to avoid missing dates I would commit to very
pessimistic dates.
I'm not sure whether I understand what you're saying here. If I do,
I think I don't agree with it. Please try to make the point somewhat
differently if you think it's worth exploring.
Post by Manuel Klimek
On the other hand if I use points and the law of big numbers to
make up for my randomness, I only have to be good at estimating
expected values, and I'll get pretty good commitments. Of course
you can do this with both points and "perfect time", but I have
problems communicating two different "time scales" (and other
reasons to prefer points if "perfect time" is not the same as
"real time")
That's why I prefer points to "perfect time". Note that Chris and
Kent do not use either points or perfect time. It works for them,
and that's good with me. I find the report that it works to be
interesting, and the apparent moral lessons that to my ears go with
it to be a bit less so.

I am very much in favor of commitment to getting the work done on
time, and in favor of transparency. However, I do not think that
commitment is as good a way to /manage/ a project as is sizing all
the stories and measuring actual progress. I think this is
particularly true when there's more than one person involved in the
project.

I could, of course, be wrong.

Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide whether it's true for you.



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Manuel Klimek
2007-06-16 21:19:41 UTC
Permalink
Ron,

somehow my brain never stopped pondering over this thread. Now
that Dale pointed to his blog entry about commitment vs. estimates
(http://www.dhemery.com/cwd/2003/08/estimates_are_not_commitments.html)
I think I understand the conflicting points of view a little better.

I think that we agree that in reality my predictions about the future
involve some risk. When I try to find out when I will be done with a feature
I predict the future: I try to imagine all those little things I have to do
to complete the task and sum up.

Since I can't really predict the future, there will always be a probability
that I am wrong. And when I sum up a lot of random values I most
probably get something somewhat normally distributed. So what
I get from my prediction is a graph of a probability distribution. If I
have done similar things before the variance will be rather small, but
if there is a lot new ground to cover the variance may be very big.

The question is how to communicate this distribution to management
or the customer. There are two basic ways:
- Estimate: Use the expectation.
There's a 50% chance that you'll be done earlier, and a 50% chance
that you're done later.
- Commitment: Use a value for which the chance that you're wrong
is sufficiently small (for example 1%)

Depending on the variance the estimate and commitment may
differ a lot (big variance) or very little (small variance).

The next step is to view a whole release. A release consists of
a whole lot of features. For each of those features I have an expectation
estimate and a "commitment estimate". A expectation for the
release would be to sum up all the expectation estimates of features
for the release. A commitment can be made by summing up all
the "commitment estimates". The problem I see is that the
sum of commitment estimates can be a lot more restrictive than
every single commitment estimates was initially, thus introducing
more slack in my commitment for the release than needed.

I try to build up an example. I hope that I don't totally mess up the
theory of probability:

1 feature to estimate yields:
days / probability
1 0.25
2 0.5
3 0.25

Let's take a look at the expectation estimate and a commitment based
on a 0.25 level of "risk"
estimate: 2 days
commitment (0.25): 3 days

Now there is a release plan for two features that have exactly the
probability distribution of the 1 feature example. The probabilities
for the release plan are:
days / probability / hopefully correct calculation ;-)
2 0.0625 = 0.25 * 0.25
3 0.25 = 0.5 * 0.25 + 0.25 * 0.5
4 0.375 = 0.5 * 0.5 + 0.25 * 0.25 + 0.25 * 0.25
5 0.25 = 0.5 * 0.25 + 0.25 * 0.5
6 0.0625 = 0.25 * 0.25

The estimate is the same as the sum of the expectation estimates:
estimate: 4 days
sum of estimates: 4 days

But the sum of commitment estimates differs from a commitment
based on the same "risk level":
commitment (0.25): ~5 days
sum of commitments: 6 days

So when I get commitments instead of estimates for release planning
I mustn't simply sum them up. But what should you do instead?
Of course the whole dilemma can simply be resolved if your variance
of estimates is small enough. But is it really transparent?

If I really wanted to be transparent I'd probably vote for communicating
both values to the manager / customer and communicate the
probabilistic implications.

For iteration planning I think that estimates are more useful, since
your commitments will be as often as nearly 50% wrong (in a good way,
of course), but does that help for the iteration? I don't think so,
for the very reasons I mentioned at the beginning of this thread.

I'm still trying to figure out a way how to improve the estimation
transparency from what I learned. Perhaps add a variance a.k.a.
risk factor next to the score on the story card? Use a
real time estimate in combination with a risk factor? What
about other concerns about real time estimates like artificially
adapting the velocity when estimates improve?

Cheers,
Manuel
--
http://klimek.box4.net


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Steven Gordon
2007-06-17 00:34:41 UTC
Permalink
There has been a lot of work on applying statistics to task estimations,
mostly under big-planning-up-front methodologies (for example,the PERT
method http://www.google.com/search?q=%22pert+method%22 ).

In an agile project, the time and effort to do more rigorous estimations and
analyze them statistically is wasted because it only provides a false level
of precision to the customer. The bottom line is that:
1. the team is going to complete what it is going to complete and any time
wasted on making estimates more precise will be time not spent getting stuff
done, and
2. team velocity patterns calibrated and observed over the recent past
provide a good indication of what is likely to be completed by any given
release date without conveying any false precision.

On the commitment side of the ledger, commitment is what the team believes
it can commit to doing. It is from the heart, not from statistical
calculations. It is useful for creating focus and building morale and
trust, but when it comes to predicting what a team will actually deliver,
I'll take the recent velocity history every time.

Steve
Post by Manuel Klimek
Ron,
somehow my brain never stopped pondering over this thread. Now
that Dale pointed to his blog entry about commitment vs. estimates
(http://www.dhemery.com/cwd/2003/08/estimates_are_not_commitments.html)
I think I understand the conflicting points of view a little better.
I think that we agree that in reality my predictions about the future
involve some risk. When I try to find out when I will be done with a feature
I predict the future: I try to imagine all those little things I have to do
to complete the task and sum up.
Since I can't really predict the future, there will always be a probability
that I am wrong. And when I sum up a lot of random values I most
probably get something somewhat normally distributed. So what
I get from my prediction is a graph of a probability distribution. If I
have done similar things before the variance will be rather small, but
if there is a lot new ground to cover the variance may be very big.
The question is how to communicate this distribution to management
- Estimate: Use the expectation.
There's a 50% chance that you'll be done earlier, and a 50% chance
that you're done later.
- Commitment: Use a value for which the chance that you're wrong
is sufficiently small (for example 1%)
Depending on the variance the estimate and commitment may
differ a lot (big variance) or very little (small variance).
The next step is to view a whole release. A release consists of
a whole lot of features. For each of those features I have an expectation
estimate and a "commitment estimate". A expectation for the
release would be to sum up all the expectation estimates of features
for the release. A commitment can be made by summing up all
the "commitment estimates". The problem I see is that the
sum of commitment estimates can be a lot more restrictive than
every single commitment estimates was initially, thus introducing
more slack in my commitment for the release than needed.
I try to build up an example. I hope that I don't totally mess up the
days / probability
1 0.25
2 0.5
3 0.25
Let's take a look at the expectation estimate and a commitment based
on a 0.25 level of "risk"
estimate: 2 days
commitment (0.25): 3 days
Now there is a release plan for two features that have exactly the
probability distribution of the 1 feature example. The probabilities
days / probability / hopefully correct calculation ;-)
2 0.0625 = 0.25 * 0.25
3 0.25 = 0.5 * 0.25 + 0.25 * 0.5
4 0.375 = 0.5 * 0.5 + 0.25 * 0.25 + 0.25 * 0.25
5 0.25 = 0.5 * 0.25 + 0.25 * 0.5
6 0.0625 = 0.25 * 0.25
estimate: 4 days
sum of estimates: 4 days
But the sum of commitment estimates differs from a commitment
commitment (0.25): ~5 days
sum of commitments: 6 days
So when I get commitments instead of estimates for release planning
I mustn't simply sum them up. But what should you do instead?
Of course the whole dilemma can simply be resolved if your variance
of estimates is small enough. But is it really transparent?
If I really wanted to be transparent I'd probably vote for communicating
both values to the manager / customer and communicate the
probabilistic implications.
For iteration planning I think that estimates are more useful, since
your commitments will be as often as nearly 50% wrong (in a good way,
of course), but does that help for the iteration? I don't think so,
for the very reasons I mentioned at the beginning of this thread.
I'm still trying to figure out a way how to improve the estimation
transparency from what I learned. Perhaps add a variance a.k.a.
risk factor next to the score on the story card? Use a
real time estimate in combination with a risk factor? What
about other concerns about real time estimates like artificially
adapting the velocity when estimates improve?
Cheers,
Manuel
--
http://klimek.box4.net
[Non-text portions of this message have been removed]



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Manuel Klimek
2007-06-17 11:20:42 UTC
Permalink
Steven,

I agree. I don't want to use statistics to actually predict a date. I just
used statistics to make a point. Just as a reminder: I am for simple
points based estimates and velocity based scheduling. Kent
and Chris are not, and I try to understand why and how I can
learn from it.

Using the velocity for release planning is an expectation based
process. This means the chance that you're later than that
is 50%. This is why I don't want to talk to marketing guys about
estimates in "real time". They usually skipped the statistics courses
at university and don't want to learn about probabilities. This
is why I use points to communicate estimates.

Kent and Chris on the other hand seem to talk solely of
commitments, not of estimates. If you only talk about commitments
than it's no problem to use "real time", because the probability
that it takes you longer is small.

My point in using statistics was that if you use real time
commitments, you can't simply sum them up for release planning.
This is why I want to use estimates, too, especially for
iteration planning.

Cheers,
Manuel
Post by Steven Gordon
There has been a lot of work on applying statistics to task estimations,
mostly under big-planning-up-front methodologies (for example,the PERT
method http://www.google.com/search?q=%22pert+method%22 ).
In an agile project, the time and effort to do more rigorous estimations and
analyze them statistically is wasted because it only provides a false level
1. the team is going to complete what it is going to complete and any time
wasted on making estimates more precise will be time not spent getting stuff
done, and
2. team velocity patterns calibrated and observed over the recent past
provide a good indication of what is likely to be completed by any given
release date without conveying any false precision.
On the commitment side of the ledger, commitment is what the team believes
it can commit to doing. It is from the heart, not from statistical
calculations. It is useful for creating focus and building morale and
trust, but when it comes to predicting what a team will actually deliver,
I'll take the recent velocity history every time.
Steve
Post by Manuel Klimek
Ron,
somehow my brain never stopped pondering over this thread. Now
that Dale pointed to his blog entry about commitment vs. estimates
(http://www.dhemery.com/cwd/2003/08/estimates_are_not_commitments.html)
I think I understand the conflicting points of view a little better.
I think that we agree that in reality my predictions about the future
involve some risk. When I try to find out when I will be done with a feature
I predict the future: I try to imagine all those little things I have to do
to complete the task and sum up.
Since I can't really predict the future, there will always be a probability
that I am wrong. And when I sum up a lot of random values I most
probably get something somewhat normally distributed. So what
I get from my prediction is a graph of a probability distribution. If I
have done similar things before the variance will be rather small, but
if there is a lot new ground to cover the variance may be very big.
The question is how to communicate this distribution to management
- Estimate: Use the expectation.
There's a 50% chance that you'll be done earlier, and a 50% chance
that you're done later.
- Commitment: Use a value for which the chance that you're wrong
is sufficiently small (for example 1%)
Depending on the variance the estimate and commitment may
differ a lot (big variance) or very little (small variance).
The next step is to view a whole release. A release consists of
a whole lot of features. For each of those features I have an expectation
estimate and a "commitment estimate". A expectation for the
release would be to sum up all the expectation estimates of features
for the release. A commitment can be made by summing up all
the "commitment estimates". The problem I see is that the
sum of commitment estimates can be a lot more restrictive than
every single commitment estimates was initially, thus introducing
more slack in my commitment for the release than needed.
I try to build up an example. I hope that I don't totally mess up the
days / probability
1 0.25
2 0.5
3 0.25
Let's take a look at the expectation estimate and a commitment based
on a 0.25 level of "risk"
estimate: 2 days
commitment (0.25): 3 days
Now there is a release plan for two features that have exactly the
probability distribution of the 1 feature example. The probabilities
days / probability / hopefully correct calculation ;-)
2 0.0625 = 0.25 * 0.25
3 0.25 = 0.5 * 0.25 + 0.25 * 0.5
4 0.375 = 0.5 * 0.5 + 0.25 * 0.25 + 0.25 * 0.25
5 0.25 = 0.5 * 0.25 + 0.25 * 0.5
6 0.0625 = 0.25 * 0.25
estimate: 4 days
sum of estimates: 4 days
But the sum of commitment estimates differs from a commitment
commitment (0.25): ~5 days
sum of commitments: 6 days
So when I get commitments instead of estimates for release planning
I mustn't simply sum them up. But what should you do instead?
Of course the whole dilemma can simply be resolved if your variance
of estimates is small enough. But is it really transparent?
If I really wanted to be transparent I'd probably vote for communicating
both values to the manager / customer and communicate the
probabilistic implications.
For iteration planning I think that estimates are more useful, since
your commitments will be as often as nearly 50% wrong (in a good way,
of course), but does that help for the iteration? I don't think so,
for the very reasons I mentioned at the beginning of this thread.
I'm still trying to figure out a way how to improve the estimation
transparency from what I learned. Perhaps add a variance a.k.a.
risk factor next to the score on the story card? Use a
real time estimate in combination with a risk factor? What
about other concerns about real time estimates like artificially
adapting the velocity when estimates improve?
Cheers,
Manuel
--
http://klimek.box4.net
[Non-text portions of this message have been removed]
--
http://klimek.box4.net


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Gary Brown
2007-06-17 12:48:48 UTC
Permalink
Post by Manuel Klimek
Steven,
I agree. I don't want to use statistics to actually predict a date. I just
used statistics to make a point. Just as a reminder: I am for simple
points based estimates and velocity based scheduling. Kent
and Chris are not, and I try to understand why and how I can
learn from it.
Using the velocity for release planning is an expectation based
process. This means the chance that you're later than that
is 50%. This is why I don't want to talk to marketing guys about
estimates in "real time". They usually skipped the statistics courses
at university and don't want to learn about probabilities. This
is why I use points to communicate estimates.
Kent and Chris on the other hand seem to talk solely of
commitments, not of estimates. If you only talk about commitments
than it's no problem to use "real time", because the probability
that it takes you longer is small.
My point in using statistics was that if you use real time
commitments, you can't simply sum them up for release planning.
This is why I want to use estimates, too, especially for
iteration planning.
Cheers,
Manuel
I haven't followed this very closely, because I have grown weary of
the debate, but maybe I can help you. From what I see, your
statistics and probability example is missing two important ideas.
Velocity isn't random, it is a historical fact, based on what a team
can actualy deliver. Team's tend to mis-estimate consistently. Some
teams are optimistic and tend to underestimate. Some teams are
pessimistic and tend to overestimate.

What is important is that we give our Customer the ability to plan.
It turns out that the simplest way to do that is have the team
estimate some work, do it, and see how long it takes. Then we can use
that fact to estimate the next block of work. Yesterday's Weather.

I don't recall what Kent had to say about this, but I think Chris
talked about giving an estimate for one thing, concluding that it
would be done next Wednesday. That's fine for estimating one thing,
but my Customers come with 100 things that need to be done in four
months by a team of six.

We need to have a way to quickly look at each thing, provide an
estimate, and an expected delivery date. When I say quickly, I mean
in a few hours, because while we are burning time on this estimate,
we're not working on things that we promised for this week.

Admittedly, my organization has a lot of experience with this
estimation method, but we do this all the time on 2, 4, and 6 month
projects, and consistently hit our promised delivery dates. I don't
remember the last time we missed an delivery date. This is extremely
important to everyone in our company, because each project comes with
a revenue plan, behind that is a marketing plan, behind that is a
sales plan. When we deliver on time, we have an opportunity to reach
our revenue goals, which drive profits, a very generous part of which
is returned to employees through profit sharing.

GB.





To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Manuel Klimek
2007-06-17 16:26:14 UTC
Permalink
Gary,

if you always finish before the committed date for a 6 month project,
how often do you finish 1 week early? 1 month early? 2 months? Do you use
the formula features * (iterationTime / velocity) to commit to release
dates, or do you use some "safety factor"?

Past Velocity isn't random, but future velocity is. Our company has
quite some variation at the moment. Yesterday's weather may be the
best prediction of today's weather, but, as all those ads for capital
investments say in the fine print "past performance is no guarantee
of future results" :-)

I don't think it's transparent or even professional of a banker to
try to guide my investment decision based solely on past
performance of an investment. I want to be told about risk, too.
Even if, in the end, I don't have anything else to decide on but
past performance.

Cheers,
Manuel
Post by Gary Brown
Post by Manuel Klimek
Steven,
I agree. I don't want to use statistics to actually predict a date. I
just
Post by Manuel Klimek
used statistics to make a point. Just as a reminder: I am for simple
points based estimates and velocity based scheduling. Kent
and Chris are not, and I try to understand why and how I can
learn from it.
Using the velocity for release planning is an expectation based
process. This means the chance that you're later than that
is 50%. This is why I don't want to talk to marketing guys about
estimates in "real time". They usually skipped the statistics courses
at university and don't want to learn about probabilities. This
is why I use points to communicate estimates.
Kent and Chris on the other hand seem to talk solely of
commitments, not of estimates. If you only talk about commitments
than it's no problem to use "real time", because the probability
that it takes you longer is small.
My point in using statistics was that if you use real time
commitments, you can't simply sum them up for release planning.
This is why I want to use estimates, too, especially for
iteration planning.
Cheers,
Manuel
I haven't followed this very closely, because I have grown weary of
the debate, but maybe I can help you. From what I see, your
statistics and probability example is missing two important ideas.
Velocity isn't random, it is a historical fact, based on what a team
can actualy deliver. Team's tend to mis-estimate consistently. Some
teams are optimistic and tend to underestimate. Some teams are
pessimistic and tend to overestimate.
What is important is that we give our Customer the ability to plan.
It turns out that the simplest way to do that is have the team
estimate some work, do it, and see how long it takes. Then we can use
that fact to estimate the next block of work. Yesterday's Weather.
I don't recall what Kent had to say about this, but I think Chris
talked about giving an estimate for one thing, concluding that it
would be done next Wednesday. That's fine for estimating one thing,
but my Customers come with 100 things that need to be done in four
months by a team of six.
We need to have a way to quickly look at each thing, provide an
estimate, and an expected delivery date. When I say quickly, I mean
in a few hours, because while we are burning time on this estimate,
we're not working on things that we promised for this week.
Admittedly, my organization has a lot of experience with this
estimation method, but we do this all the time on 2, 4, and 6 month
projects, and consistently hit our promised delivery dates. I don't
remember the last time we missed an delivery date. This is extremely
important to everyone in our company, because each project comes with
a revenue plan, behind that is a marketing plan, behind that is a
sales plan. When we deliver on time, we have an opportunity to reach
our revenue goals, which drive profits, a very generous part of which
is returned to employees through profit sharing.
GB.
--
http://klimek.box4.net


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



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Steven Gordon
2007-06-17 17:38:17 UTC
Permalink
Taking it one step further, if a team never fails to meet its goals, that
/could/ be an indication of:
1. Underestimation,
2. Team complacency, and/or
3. Not taking on enough risk.

Not taking on enough risk is also a form of complacency, but at the business
level. Depending on the business, its market and its competition, this kind
of complacency could be sowing the seeds of a slow descent.

An agile business should try to be as close to the edge of chaos as
possible. Not complacently comfortable, but not thrashing either.
Sustainable, but still taking on enough risk to innovate and drive
improvement. This concept is sometimes referred to as chaordic -
http://www.google.com/search?q=chaordic.

Steve
Post by Manuel Klimek
Gary,
if you always finish before the committed date for a 6 month project,
how often do you finish 1 week early? 1 month early? 2 months? Do you use
the formula features * (iterationTime / velocity) to commit to release
dates, or do you use some "safety factor"?
Past Velocity isn't random, but future velocity is. Our company has
quite some variation at the moment. Yesterday's weather may be the
best prediction of today's weather, but, as all those ads for capital
investments say in the fine print "past performance is no guarantee
of future results" :-)
I don't think it's transparent or even professional of a banker to
try to guide my investment decision based solely on past
performance of an investment. I want to be told about risk, too.
Even if, in the end, I don't have anything else to decide on but
past performance.
Cheers,
Manuel
Post by Gary Brown
Post by Manuel Klimek
Steven,
I agree. I don't want to use statistics to actually predict a date. I
just
Post by Manuel Klimek
used statistics to make a point. Just as a reminder: I am for simple
points based estimates and velocity based scheduling. Kent
and Chris are not, and I try to understand why and how I can
learn from it.
Using the velocity for release planning is an expectation based
process. This means the chance that you're later than that
is 50%. This is why I don't want to talk to marketing guys about
estimates in "real time". They usually skipped the statistics courses
at university and don't want to learn about probabilities. This
is why I use points to communicate estimates.
Kent and Chris on the other hand seem to talk solely of
commitments, not of estimates. If you only talk about commitments
than it's no problem to use "real time", because the probability
that it takes you longer is small.
My point in using statistics was that if you use real time
commitments, you can't simply sum them up for release planning.
This is why I want to use estimates, too, especially for
iteration planning.
Cheers,
Manuel
I haven't followed this very closely, because I have grown weary of
the debate, but maybe I can help you. From what I see, your
statistics and probability example is missing two important ideas.
Velocity isn't random, it is a historical fact, based on what a team
can actualy deliver. Team's tend to mis-estimate consistently. Some
teams are optimistic and tend to underestimate. Some teams are
pessimistic and tend to overestimate.
What is important is that we give our Customer the ability to plan.
It turns out that the simplest way to do that is have the team
estimate some work, do it, and see how long it takes. Then we can use
that fact to estimate the next block of work. Yesterday's Weather.
I don't recall what Kent had to say about this, but I think Chris
talked about giving an estimate for one thing, concluding that it
would be done next Wednesday. That's fine for estimating one thing,
but my Customers come with 100 things that need to be done in four
months by a team of six.
We need to have a way to quickly look at each thing, provide an
estimate, and an expected delivery date. When I say quickly, I mean
in a few hours, because while we are burning time on this estimate,
we're not working on things that we promised for this week.
Admittedly, my organization has a lot of experience with this
estimation method, but we do this all the time on 2, 4, and 6 month
projects, and consistently hit our promised delivery dates. I don't
remember the last time we missed an delivery date. This is extremely
important to everyone in our company, because each project comes with
a revenue plan, behind that is a marketing plan, behind that is a
sales plan. When we deliver on time, we have an opportunity to reach
our revenue goals, which drive profits, a very generous part of which
is returned to employees through profit sharing.
GB.
--
http://klimek.box4.net
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Gary Brown
2007-06-18 03:12:52 UTC
Permalink
Post by Steven Gordon
Taking it one step further, if a team never fails to meet its goals, that
1. Underestimation,
2. Team complacency, and/or
3. Not taking on enough risk.
They could also be working hard and hitting their marks every week.

GB.




To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Gary Brown
2007-06-18 03:05:43 UTC
Permalink
Post by Manuel Klimek
Gary,
if you always finish before the committed date for a 6 month project,
how often do you finish 1 week early? 1 month early? 2 months? Do you use
the formula features * (iterationTime / velocity) to commit to release
dates, or do you use some "safety factor"?
We never finish early. If we did, we would call the Customer and made
sure that we didn't miss something.
Post by Manuel Klimek
Past Velocity isn't random, but future velocity is. Our company has
quite some variation at the moment. Yesterday's weather may be the
best prediction of today's weather, but, as all those ads for capital
investments say in the fine print "past performance is no guarantee
of future results" :-)
We're not doing capital investments. We're working hard every day
creating value for our Customers. No one will be perfect, but we
think that our past performance is a very strong indicator of future
results.
Post by Manuel Klimek
I don't think it's transparent or even professional of a banker to
try to guide my investment decision based solely on past
performance of an investment. I want to be told about risk, too.
Even if, in the end, I don't have anything else to decide on but
past performance.
Again, we're not doing that. When our Customer asks us to work on a
high risk story, we tell them it's high risk, and put a large sizing
on it. We have an agreement with our Customers, that they can't
assign a story larger than 4 to an iteration. If they really want us
to work on it, we sit with them and figure out how to get some useful
part(s) down to 4 or less. We have full senior management support for
this procedure, because we have lots of evidence what happens when we
don't.

It's like so many things Manuel. It's a lot easier to sit on the side
lines and figure out why something won't work. It takes a little
effort to give it a try and figure out how to make it work.

Peace, out!

GB.





To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Manuel Klimek
2007-06-18 18:36:36 UTC
Permalink
Gary,
Post by Gary Brown
It's like so many things Manuel. It's a lot easier to sit on the side
lines and figure out why something won't work. It takes a little
effort to give it a try and figure out how to make it work.
I don't sit on the side lines and figure out why something won't work.
I am struggling to introduce exactly the practices you describe in
my daily work environment, getting better at it every day. That
doesn't mean that I don't think about different view points. I am
really thankful for your replies and I know that I'm sometimes a little
"sticky", but that's the only way for me to learn - sometimes it takes
a little longer.

I read from your reply that you use the XP way of negotiating scope.
I'm trying to learn how negotiating scope aligns with commitments,
especially with regards to story estimates. Since Kent and Chris
both argued in favor of "real time commitments" instead of "point
estimates", and I regard their opinion highly and often need help to
understand their reasoning, I ask these questions in order to get
some insight into the overall picture.

I think the basic question is "why do I need real time commitments
if I can negotiate scope based on point estimates?". But right now
I'm not even sure that this /is/ the right question...

Cheers,
Manuel
--
http://klimek.box4.net


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Dale Emery
2007-06-17 19:50:09 UTC
Permalink
Hi Gary,
Post by Gary Brown
We need to have a way to quickly look at each thing, provide an
estimate, and an expected delivery date. When I say quickly, I mean
in a few hours, because while we are burning time on this estimate,
we're not working on things that we promised for this week.
That seems like something to watch for: Holding to your previous promisise
even when the customer asks for additional work (the estimate).

Dale

--
Dale Emery, Consultant
Inspiring Leadership for Software People
Web: http://www.dhemery.com
Weblog: http://www.dhemery.com/cwd





To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Daniel Wildt
2007-05-23 04:51:58 UTC
Permalink
Hey Manuel, great post!

Ron, I decided to keep things simple and try to work with three deliverables I'm already using:
- Estimation in hours (it works the same way for me as points).
- Velocity Calculation
- Big charts! :-) I use Burn Down chart which is great.

And no more load factor calculation!

I was talking to a friend about load factor calculation (the way I manage in agile projects) and alocation percentage for resource
planning (it is how he manages in ms project). We didn't get into any conclusion about that being really useful and we find out
that's only another way to try to predict the future. After saying that, total silence in the room... :-)

Regarding dates, estimations and big charts, we have two great resources from Ron:

Making the Date and Q&A Ron Jeffries
HYPERLINK "http://video.google.com/videoplay?docid=8118639938813043270"http://video.google.com/videoplay?docid=8118639938813043270
Big Visible Charts
HYPERLINK "http://www.xprogramming.com/xpmag/BigVisibleCharts.htm"http://www.xprogramming.com/xpmag/BigVisibleCharts.htm

Regards,
Daniel Wildt
HYPERLINK "http://danielwildt.blogspot.com"http://danielwildt.blogspot.com





_____

De: ***@yahoogroups.com [mailto:***@yahoogroups.com] Em nome de Ron Jeffries
Enviada em: terça-feira, 22 de maio de 2007 10:44
Para: ***@yahoogroups.com
Assunto: Re: RES: [XP] Estimation: Time or Size?
Post by Manuel Klimek
in the "Hours vs. Points" thread the conclusion was (at least
for me) that it's very good to use real time estimates, if you're
able to /commit/ to real time estimates. This means that your
estimates are so good that you don't have a big standard
deviation.
If you're bad at estimating and the probability is small that
you get any better anytime soon (for example, if your new tasks
differ a lot from what you already did) than I'd prefer
estimating in points. It resolved a few issues at the shop I work at.
It seems to me that one can commit in either format. The important
thing is to recognize that an estimate /is supposed to be/ a range
of dates or feature counts, and a commitment is a point in time or
count. So one would commit, I suppose, toward the pessimistic side
of the estimate.

Ron Jeffries
www.XProgramming.-com
You can observe a lot by watching. --Yogi Berra






No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.467 / Virus Database: 269.7.6/815 - Release Date: 22/05/2007 15:49



No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.467 / Virus Database: 269.7.6/815 - Release Date: 22/05/2007 15:49



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



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Paul Campbell
2007-05-22 12:44:36 UTC
Permalink
Post by dnicolet99
+1.
I've observed teams that are relatively new to agile methods tend to
"want" to convert points to time; they seem to be pulled naturally in
that direction. I suspect it's because they've been estimating in
terms of time for so long it feels odd to them to use a different
approach.
Dave
Yes I concur. It isnt a fatal flaw though and will often be "small
beer" for a team wrestling with a transition to agile.

Paul.




To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Ron Jeffries
2007-05-22 02:03:26 UTC
Permalink
Post by Daniel Wildt
And how do you guys translate story points to the real time?
Are you guys using some kind of load factor calculation?
ideal hours x load factor = expected time
What I like is pretty simple:
Do a few stories.
Observe how long they take.
Do the arithmetic for the rest.

Ron Jeffries
www.XProgramming.com
What is your dream? And knowing this, what have you
done to work towards realizing it today? -- Les Brown



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Seyit Caglar Abbasoglu
2007-05-21 21:48:02 UTC
Permalink
Post by Tobias Mayer
Time or Size?
This argument always confuses me.

By calling 'size', do you mean 'relative time', such as 'the time needed to
complete a unit story'? Or while using size (story points) do you use some
different measure from time?


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



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
William Pietri
2007-05-22 10:11:07 UTC
Permalink
I mentioned this to Tobias in person, but I thought I'd say something
here, too.
Post by Tobias Mayer
Has anyone on this list found that real time estimation is useful in an Agile context (actually, in any context)? I'd be very interested to hear about it. Thanks.
I've heard of teams that can estimate well in real time, but I have
never seen it in practice.

With points, on the other hand, I've seen a number of teams reach eerily
steady velocities, and a very good record of finishing the work they've
taken on. I expect that process of reaching stability to take eight
weeks, plus or minus.

My theory is that a lot of the magic of points-based estimation is in
what questions it dodges. The biggest one is the eternal, "If you got 12
hours of work done last week, what did you do with the other 28 hours we
were paying you for?"

A big bonus is that hours-based estimation seems to encourage people to
do a lot of ridiculously unsupportable math. The classic version is the
theory that nine women can make a baby in a month. The no less popular
version is that if you work twice as many hours, you'll get twice as
much work done. But there are a host of others.


Personally, I don't bother estimating tasks. I like doing task
breakdowns a lot, and once an iteration's stories are tasked I think
it's worth pausing a bit to see if people still feel we took on the
right amount of work.

Hoping that helps,

William


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
dnicolet99
2007-05-22 10:20:15 UTC
Permalink
William,

I like the approach you describe, and I've had similar observations of
the time it take teams to stabilize.

Dave
Post by William Pietri
I mentioned this to Tobias in person, but I thought I'd say something
here, too.
Post by Tobias Mayer
Has anyone on this list found that real time estimation is useful
in an Agile context (actually, in any context)? I'd be very
interested to hear about it. Thanks.
Post by William Pietri
I've heard of teams that can estimate well in real time, but I have
never seen it in practice.
With points, on the other hand, I've seen a number of teams reach eerily
steady velocities, and a very good record of finishing the work they've
taken on. I expect that process of reaching stability to take eight
weeks, plus or minus.
My theory is that a lot of the magic of points-based estimation is in
what questions it dodges. The biggest one is the eternal, "If you got 12
hours of work done last week, what did you do with the other 28 hours we
were paying you for?"
A big bonus is that hours-based estimation seems to encourage people to
do a lot of ridiculously unsupportable math. The classic version is the
theory that nine women can make a baby in a month. The no less popular
version is that if you work twice as many hours, you'll get twice as
much work done. But there are a host of others.
Personally, I don't bother estimating tasks. I like doing task
breakdowns a lot, and once an iteration's stories are tasked I think
it's worth pausing a bit to see if people still feel we took on the
right amount of work.
Hoping that helps,
William
To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Micron Engineering
2007-05-22 10:35:21 UTC
Permalink
Post by William Pietri
I mentioned this to Tobias in person, but I thought I'd say something
here, too.
....
Personally, I don't bother estimating tasks. I like doing task
breakdowns a lot, and once an iteration's stories are tasked I think
it's worth pausing a bit to see if people still feel we took on the
right amount of work.
What type of estimate and management plan do you propose to a customer
asking to have its software before an exact day?
Suppose that your team can't be larger then 6 sw engineers can you
explain me how can you make an estimation to predict the end of work for
a 1000 points sw starting today supposing 25 hours for week working time
for all 6 engineers?
Post by William Pietri
Hoping that helps,
William
------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.467 / Virus Database: 269.7.6/814 - Release Date: 21/05/2007 14.01
[Non-text portions of this message have been removed]



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Ron Jeffries
2007-05-22 11:18:54 UTC
Permalink
Hello, Micron. (Odd name you have! :) ) On Tuesday, May 22, 2007, at
Post by Micron Engineering
What type of estimate and management plan do you propose to a customer
asking to have its software before an exact day?
Suppose that your team can't be larger then 6 sw engineers can you
explain me how can you make an estimation to predict the end of work for
a 1000 points sw starting today supposing 25 hours for week working time
for all 6 engineers?
To begin with, it seems to me to be imprudent, whether one estimates
in real time, ideal time, points, or any other means, to imagine
that we can accurately predict how long the project will take. Few
of us are that good. (If you can do that now, I'd like to hear how.)

Second, my experience is that the customer already knows what the
day is when she wants the product. Therefore our job is first to
predict how much work we can get done, and second, steer the project
for delivery on that day, //even though we will get a different
amount of work done than we predicted//. (We will probably also get
different work done entirely, because of learning during the project
changing what the customer wants.)

I prefer estimates in points followed by measurement of velocity to
see how many points we can do in a week. This process should be
repeated every iteration, and the results drawn up in some form such
as a burn chart:
http://www.xprogramming.com/xpmag/BigVisibleCharts.htm#N190

If I understand what Kent has been saying, he prefers estimation
(and /commitment/) in actual time. The difference, I imagine, is
that to commit to a specific moment of delivery for a story, one
needs to add slack into one's estimate:

I estimate that I need four hours;
I estimate that I'll get two hours a day;
I estimate that I can grab some extra time if things run long;
I commit to be done at the end of the second day.
(Or something like that.)

Either way, predicting the end of a whole series of stories is much
more difficult, as is predicting just how many will get done.

But to me, the essence of doing all this is not in predicting, or
committing to far-away amounts of time and features, but in steering
the project to deliver the best possible product by the desired
date. To do that, a reasonable estimate of difficulty and velocity
is sufficient to get a rough idea of what will happen. I'd prefer
point estimates plus established velocity, but also believe that
estimates in perfect days, multiplied by three, is a decent rough
rough estimate.

Ron Jeffries
www.XProgramming.com
Those who believe complexity is elegant or required don't understand
the problem. -- John Streiff



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Micron Engineering
2007-05-22 12:37:45 UTC
Permalink
Post by Ron Jeffries
Hello, Micron. (Odd name you have! :) ) On Tuesday, May 22, 2007, at
it was the 1st company common email address
Post by Ron Jeffries
Post by Micron Engineering
What type of estimate and management plan do you propose to a customer
asking to have its software before an exact day?
Suppose that your team can't be larger then 6 sw engineers can you
explain me how can you make an estimation to predict the end of work for
a 1000 points sw starting today supposing 25 hours for week working time
for all 6 engineers?
To begin with, it seems to me to be imprudent, whether one estimates
in real time, ideal time, points, or any other means, to imagine
that we can accurately predict how long the project will take. Few
of us are that good. (If you can do that now, I'd like to hear how.)
Ron, if I have to develop a software to sell (internal product) actually
I/we are using an approach that isn't pure XP and isn't pure traditional
(we started about 6 years ago with a pure PSP process that evolved).
In this case our phases are:
1. Idea definition and presentation
2. Marketing study
3. Application definition
4. Requirements and risk analisys (use cases and stories are written at
this stage)
5. Master planning (estimates are done here, mostly using files,
classes, classes-methods, screens/windows/forms, reports, database
tables, LOCs as unit of measures as appropriate for every module)
6. Development
7. Delivery
8. Maintenance
9. Phase out

Development phase is made with a cycle process that may be specifically
tailored; we don't use pair programming but we use inspections and
continuous testing. In any case it is a cycle that in the more complex
situation can be:
a. high level design (not so detailed) mostly using UML diagrams
b. prototyping (little code blocks to test unknown pieces of code due to
a new library, development tool, algorithm and so on).
c. validate prototyping
d. source code modules development, documentation and test
e. source code modules integration, documentation and tests

the cycle a...e is made for every module, we can use a priority
scheduling to deliver modules that have higher priority.
We can adjust our estimate at every cycle end. In practice a cycle may
take 1 week on little projects and 4 weeks in the others; in this case
last week is all reserved to integration, documentation and test without
regard to modules completion (may be that some one is on delay but the
engineer have to write their modules to don't propagate the delay to the
modules of other engineers).
Delivery, maintenance and phase-out are more simpler steps, only
maintenance uses the same cycle of development.

In a customer-project we have to make estimates at the very beginning
and we need some accuracy because to don't loose money and to don't
underestimate our effort. We also have schedules where the same engineer
already knows the next project to start after he completes the previous
so we can't have to much delay from one project to its successor.

In this situation we make estimates not using points or use cases; we
made estimations with a unit of measure that is more significant for
that module or for the complete application. So it is difficult for me
translate #db_tables to points, # reports to points and so on.

Second, my experience is that the customer already knows what the
day is when she wants the product. Therefore our job is first to
predict how much work we can get done, and second, steer the project
for delivery on that day, //even though we will get a different
amount of work done than we predicted//. (We will probably also get
different work done entirely, because of learning during the project
changing what the customer wants.)

P.S. I made some cut and paste because for some strange reasons I am not
always able to quote yahoo group emails.
Normally our customers ask to us an estimate in terms of money and time
and giving us a delivery date. It is quite common also to pay some fees
if we finish on delay.

Either way, predicting the end of a whole series of stories is much
more difficult, as is predicting just how many will get done.

Actually we have good estimates for a set of applications that we
previously developed; not because some sw is already done but mainly
because we know the problems we had. We are searching a best way to make
estimates on radically new applications or for applications where the
prototyping phase may take 50% or more of the development effort (we
made also 70% estimate time/effort error for prototypeing phases).

But to me, the essence of doing all this is not in predicting, or
committing to far-away amounts of time and features, but in steering
the project to deliver the best possible product by the desired
date. To do that, a reasonable estimate of difficulty and velocity
is sufficient to get a rough idea of what will happen. I'd prefer
point estimates plus established velocity, but also believe that
estimates in perfect days, multiplied by three, is a decent rough
rough estimate.

I can understand your idea but how can help me to make accurate
estimates at the very beginning of a new commitment?
Actually this is our best problem.
Post by Ron Jeffries
I prefer estimates in points followed by measurement of velocity to
see how many points we can do in a week. This process should be
repeated every iteration, and the results drawn up in some form such
http://www.xprogramming.com/xpmag/BigVisibleCharts.htm#N190
<http://www.xprogramming.com/xpmag/BigVisibleCharts.htm#N190>
If I understand what Kent has been saying, he prefers estimation
(and /commitment/) in actual time. The difference, I imagine, is
that to commit to a specific moment of delivery for a story, one
I estimate that I need four hours;
I estimate that I'll get two hours a day;
I estimate that I can grab some extra time if things run long;
I commit to be done at the end of the second day.
(Or something like that.)
Either way, predicting the end of a whole series of stories is much
more difficult, as is predicting just how many will get done.
But to me, the essence of doing all this is not in predicting, or
committing to far-away amounts of time and features, but in steering
the project to deliver the best possible product by the desired
date. To do that, a reasonable estimate of difficulty and velocity
is sufficient to get a rough idea of what will happen. I'd prefer
point estimates plus established velocity, but also believe that
estimates in perfect days, multiplied by three, is a decent rough
rough estimate.
Ron Jeffries
www.XProgramming.com
Those who believe complexity is elegant or required don't understand
the problem. -- John Streiff
------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.467 / Virus Database: 269.7.6/814 - Release Date: 21/05/2007 14.01
[Non-text portions of this message have been removed]



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Ron Jeffries
2007-05-22 13:39:35 UTC
Permalink
Hello, Micron. May I call you Mic, or do you have an actual name
that could be used to sign your emails? I'd try to use it, though my
macros are so powerful that I can't guarantee it. :)
Post by Micron Engineering
I can understand your idea but how can help me to make accurate
estimates at the very beginning of a new commitment?
Actually this is our best problem.
It's everyone's problem. I believe that the right answer, most
commonly, is "we can't make accurate estimates at the beginning of a
new commitment." The reason is that we know less at that moment than
any other time in the project, so that everything that is to come
will surely improve our estimates.

Now if an estimate means a //range// of dates or scope, it is
possible to do that. Clearly we could say "We can deliver between
one and ten thousand features by your date." Now we are discussing
how to refine that estimate to a narrower range (maybe 2-5,000?),
and the techniques described in this thread will work for that.

As I mentioned before, I would prefer to estimate all the stories in
perfect days, use history or a rough guess (3-5) to relate perfect
days to real days, and use that to get a rough date. Invert that to
a particular date, and you get a range of features.

For 100 features, needing 300 perfect days:

300 perfect days, 3-5 real/perfect: 900-1500 real days;

1000 days available, 3-5 real/perfect, 200-333 perfect days, for
66-111 possible features.

For me, that's as good as estimation ever gets ... and the real way
to succeed is not to estimate better, but to steer well over the
course of the project.

Ron Jeffries
www.XProgramming.com
[S]oftware engineering ... "How to program if you cannot." -- Edsger Dijkstra



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Micron Engineering
2007-05-22 14:15:09 UTC
Permalink
Hello, Micron. May I call you Mic, or do you have an actual name that
could be used to sign your emails? I'd try to use it, though my
macros are so powerful that I can't guarantee it. :)
My name is Massimo Manca, actually my working email is
***@micronengineering.it, this old one I use only for yahoo
groups.
Post by Micron Engineering
I can understand your idea but how can help me to make accurate
estimates at the very beginning of a new commitment? Actually this
is our best problem.
It's everyone's problem. I believe that the right answer, most
commonly, is "we can't make accurate estimates at the beginning of a
new commitment." The reason is that we know less at that moment than
any other time in the project, so that everything that is to come
will surely improve our estimates.
I perfectly agree but here in Italy is quite difficult to find customers
that may accept this. If they exists... are not mine.
Now if an estimate means a //range// of dates or scope, it is
possible to do that.
This is exactly what we need in a +/- 25% range.

Clearly we could say "We can deliver between one
and ten thousand features by your date." Now we are discussing how to
refine that estimate to a narrower range (maybe 2-5,000?), and the
techniques described in this thread will work for that.
As I mentioned before, I would prefer to estimate all the stories in
perfect days, use history or a rough guess (3-5) to relate perfect
days to real days, and use that to get a rough date. Invert that to a
particular date, and you get a range of features.
300 perfect days, 3-5 real/perfect: 900-1500 real days;
1000 days available, 3-5 real/perfect, 200-333 perfect days, for
66-111 possible features.
For me, that's as good as estimation ever gets ... and the real way
to succeed is not to estimate better, but to steer well over the
course of the project.
Ok, this has a lot of meaning for me. May you give me a suggestion to
translate our actually and old "statistics" in points or features? Just
as an example: I have these real data for a db application where there
are 46 tables, 12 queries, 23 reports and 19 forms (working with db
"objects") for 14532 LOCs (developed in C++ Builder, I don't count LOCs
of forms files generated by the ide). We developed it in 685 real hours
considering requirements, coding, test and documentation. We have a
productivity rate (historically data) from 19 to 26 LOCs/hour from
requirements to delivery, (from 24 to 32 only during development cycle)
it is an aggregate data because it takes care also of non sw activities
(requirements are doc documents); taking care of them we developed it in
538 hours for 27 LOCs/hour.
Our initial guess was -15% then the final one, we correct it during the
development to +5%. Our initial estimate was wrong of about 9% that for
me was a success. For db applications now we have data to define a
complexity level taking care of the number of tables, queries, reports,
stored procedures and forms and their complexity (1 to 5). Accuracy is
about the same then without but we can make an initial estimate in
minutes (after know the numbers) and this is an interesting result.
The problem is still how much time we need to know the application from
the db point of view.
Ron Jeffries www.XProgramming.com [S]oftware engineering ... "How to
program if you cannot." -- Edsger Dijkstra
arial,helvetica,clean,sans-serif;*font-size:small;*font:x-small;}
#ygrp-mlmsg table {font-size:inherit;font:100%;} #ygrp-mlmsg select,
input, textarea {font:99% arial,helvetica,clean,sans-serif;}
#ygrp-mlmsg pre, code {font:115% monospace;*font-size:100%;}
#ygrp-mlmsg * {line-height:1.22em;} #ygrp-text{ font-family: Georgia;
Verdana; font-size: 77%; margin: 0; } #ygrp-vitnav a{ padding: 0 1px;
} #ygrp-actbar{ clear: both; margin: 25px 0; white-space:nowrap;
color: #666; text-align: right; } #ygrp-actbar .left{ float: left;
white-space:nowrap; } .bld{font-weight:bold;} #ygrp-grft{
font-family: Verdana; font-size: 77%; padding: 15px 0; } #ygrp-ft{
font-family: verdana; font-size: 77%; border-top: 1px solid #666;
padding: 5px 0; } #ygrp-mlmsg #logo{ padding-bottom: 10px; }
Verdana; font-weight: bold; color: #333; text-transform: uppercase; }
#ygrp-vital ul{ padding: 0; margin: 2px 0; } #ygrp-vital ul li{
list-style-type: none; clear: both; border: 1px solid #e0ecee; }
right; width: 2em; text-align:right; padding-right: .5em; }
#ygrp-vital ul li .cat{ font-weight: bold; } #ygrp-vital a {
underline; } #ygrp-sponsor #hd{ color: #999; font-size: 77%; }
#ygrp-sponsor #ov{ padding: 6px 13px; background-color: #e0ecee;
margin-bottom: 20px; } #ygrp-sponsor #ov ul{ padding: 0 0 0 8px;
none; font-size: 130%; } #ygrp-sponsor #nc { background-color: #eee;
bold; color: #628c2a; font-size: 100%; line-height: 122%; }
#ygrp-sponsor .ad a{ text-decoration: none; } #ygrp-sponsor .ad
0; } o {font-size: 0; } .MsoNormal { margin: 0 0 0 0; } #ygrp-text
tt{ font-size: 120%; } blockquote{margin: 0 0 0 4px;} .replbq
{margin:4} -->
-------------------------
No virus found in this incoming message. Checked by AVG Free Edition.
Version: 7.5.467 / Virus Database: 269.7.6/814 - Release Date: 21/05/2007 14.01
[Non-text portions of this message have been removed]



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Steven Gordon
2007-05-22 14:54:57 UTC
Permalink
Post by Micron Engineering
The problem is still how much time we need to know the application from
the db point of view.
This is the crux of the estimation problem no matter what estimation
or development process you use: You need to know the application's
final requirements before an estimation can be made based on the size
of the implementation (number of tables, forms, ...). Yet, you will
not know the application's final requirements until you are well into
the project.

This contradiction drives us to an iterative process. What would be
the response if you said to the potential customer:
1. We charge X every month.
2. We will deliver working software at the end of every month with
additional features for you to examine and use if you like.
3. You can accept that software, pay us X, and help define what we
will deliver the next month, OR you can not pay us, keep the source
code so far and cancel if you believe that what we delivered is not
worth X.

I suggest collecting X as a down payment on the project so that the
customer does not have to pay for the last month's work if they ever
choose to cancel.

How can a customer turn that down if X represents the going rate for
software development in your market? They cannot ever be cheated
because they get to see what it is they are paying for and can walk
away without paying any time. Furthermore, they can change the
requirements any month, so they can get what they want even if what
they want changes. Yet, you also benefit because you do not have to
risk your skin on fixed price bids without knowing what the final
requirements will be, nor do you have to waste lots of unpaid time on
up front analysis to support those bids.

Steve


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Micron Engineering
2007-05-22 15:22:34 UTC
Permalink
Post by Steven Gordon
Post by Micron Engineering
The problem is still how much time we need to know the application
from the db point of view.
This is the crux of the estimation problem no matter what estimation
or development process you use: You need to know the application's
final requirements before an estimation can be made based on the size
of the implementation (number of tables, forms, ...). Yet, you will
not know the application's final requirements until you are well into
the project.
Of course, but an early estimate help the customer and us with some
grade of confidence to start or not to work.
Post by Steven Gordon
This contradiction drives us to an iterative process. What would be
the response if you said to the potential customer: 1. We charge X
every month. 2. We will deliver working software at the end of every
month with additional features for you to examine and use if you
like. 3. You can accept that software, pay us X, and help define what
we will deliver the next month, OR you can not pay us, keep the
source code so far and cancel if you believe that what we delivered
is not worth X.
1. I had only a big customer some years ago that ask us for a r&d
development where he admitted to didn't know where the project could go
so he proposed to develop and pay every week (in practice we defined
every week what to do and what to change and he pid every end of month
counting weekly hours).
2. If I work for a customer is the customer that have to put care to
say what he needs and we (my group) have to implement what he needs also
proposing practical solutions. So we can't accept a policy "try before
buy" every month.
Also we can't accept to start a new project that can be interrupted
every week or month; in this case we simply accept a different project
from a different customer (actually we are in the situation that we have
more work then we can make).
Post by Steven Gordon
I suggest collecting X as a down payment on the project so that the
customer does not have to pay for the last month's work if they ever
choose to cancel.
Sure, could be ok for the customer but not for us, also because a month
of 1 engineer could be done, a month of 6 engineers can't be done.
Post by Steven Gordon
How can a customer turn that down if X represents the going rate for
software development in your market? They cannot ever be cheated
because they get to see what it is they are paying for and can walk
away without paying any time. Furthermore, they can change the
requirements any month, so they can get what they want even if what
they want changes.
Also now he can change and then choose to have an estimate for the
change or simply accepts an over charge.
Yet, you also benefit because you do not have to
Post by Steven Gordon
risk your skin on fixed price bids without knowing what the final
requirements will be, nor do you have to waste lots of unpaid time on
up front analysis to support those bids.
Steve, we don't write down 1 row of code if the customer doesn't agree
an accepting test procedure to say if the sw is ok or not. We write the
procedure with the customer in a way that he can say if the test is
passed or failed unambiguously.
We agree with the customer what we have to do, how it will be accepted
and defined, how much it will pay and how much time it will take to
develop (+/- 25-35% normally) and we adjust early estimations about
every 2 weeks.
Post by Steven Gordon
Steve
arial,helvetica,clean,sans-serif;*font-size:small;*font:x-small;}
#ygrp-mlmsg table {font-size:inherit;font:100%;} #ygrp-mlmsg select,
input, textarea {font:99% arial,helvetica,clean,sans-serif;}
#ygrp-mlmsg pre, code {font:115% monospace;*font-size:100%;}
#ygrp-mlmsg * {line-height:1.22em;} #ygrp-text{ font-family: Georgia;
Verdana; font-size: 77%; margin: 0; } #ygrp-vitnav a{ padding: 0 1px;
} #ygrp-actbar{ clear: both; margin: 25px 0; white-space:nowrap;
color: #666; text-align: right; } #ygrp-actbar .left{ float: left;
white-space:nowrap; } .bld{font-weight:bold;} #ygrp-grft{
font-family: Verdana; font-size: 77%; padding: 15px 0; } #ygrp-ft{
font-family: verdana; font-size: 77%; border-top: 1px solid #666;
padding: 5px 0; } #ygrp-mlmsg #logo{ padding-bottom: 10px; }
Verdana; font-weight: bold; color: #333; text-transform: uppercase; }
#ygrp-vital ul{ padding: 0; margin: 2px 0; } #ygrp-vital ul li{
list-style-type: none; clear: both; border: 1px solid #e0ecee; }
right; width: 2em; text-align:right; padding-right: .5em; }
#ygrp-vital ul li .cat{ font-weight: bold; } #ygrp-vital a {
underline; } #ygrp-sponsor #hd{ color: #999; font-size: 77%; }
#ygrp-sponsor #ov{ padding: 6px 13px; background-color: #e0ecee;
margin-bottom: 20px; } #ygrp-sponsor #ov ul{ padding: 0 0 0 8px;
none; font-size: 130%; } #ygrp-sponsor #nc { background-color: #eee;
bold; color: #628c2a; font-size: 100%; line-height: 122%; }
#ygrp-sponsor .ad a{ text-decoration: none; } #ygrp-sponsor .ad
0; } o {font-size: 0; } .MsoNormal { margin: 0 0 0 0; } #ygrp-text
tt{ font-size: 120%; } blockquote{margin: 0 0 0 4px;} .replbq
{margin:4} -->
-------------------------
No virus found in this incoming message. Checked by AVG Free Edition.
Version: 7.5.467 / Virus Database: 269.7.6/814 - Release Date: 21/05/2007 14.01
[Non-text portions of this message have been removed]



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Ron Jeffries
2007-05-29 22:10:04 UTC
Permalink
Hello, Steven. Very nice. I wonder why more people don't do this. On
Post by Steven Gordon
This is the crux of the estimation problem no matter what estimation
or development process you use: You need to know the application's
final requirements before an estimation can be made based on the size
of the implementation (number of tables, forms, ...). Yet, you will
not know the application's final requirements until you are well into
the project.
This contradiction drives us to an iterative process. What would be
1. We charge X every month.
2. We will deliver working software at the end of every month with
additional features for you to examine and use if you like.
3. You can accept that software, pay us X, and help define what we
will deliver the next month, OR you can not pay us, keep the source
code so far and cancel if you believe that what we delivered is not
worth X.
I suggest collecting X as a down payment on the project so that the
customer does not have to pay for the last month's work if they ever
choose to cancel.
How can a customer turn that down if X represents the going rate for
software development in your market? They cannot ever be cheated
because they get to see what it is they are paying for and can walk
away without paying any time. Furthermore, they can change the
requirements any month, so they can get what they want even if what
they want changes. Yet, you also benefit because you do not have to
risk your skin on fixed price bids without knowing what the final
requirements will be, nor do you have to waste lots of unpaid time on
up front analysis to support those bids.
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



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
George Dinwiddie
2007-05-22 14:33:22 UTC
Permalink
Post by Ron Jeffries
To begin with, it seems to me to be imprudent, whether one estimates
in real time, ideal time, points, or any other means, to imagine
that we can accurately predict how long the project will take. Few
of us are that good. (If you can do that now, I'd like to hear how.)
Unless, of course, we vary the scope instead of the duration.
--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Ron Jeffries
2007-05-22 15:02:59 UTC
Permalink
Hello, George. On Tuesday, May 22, 2007, at 10:33:22 AM, you
Post by George Dinwiddie
Post by Ron Jeffries
To begin with, it seems to me to be imprudent, whether one estimates
in real time, ideal time, points, or any other means, to imagine
that we can accurately predict how long the project will take. Few
of us are that good. (If you can do that now, I'd like to hear how.)
Unless, of course, we vary the scope instead of the duration.
Yes. In which case it is imprudent to imagine that we can accurately
predict how many features we'll have done. Thanks for the ping: I
should have said that.

Ron Jeffries
www.XProgramming.com
Everything elegant is simple, not everything simple is elegant and
nothing complex is ever elegant. --John Streiff



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
dnicolet99
2007-05-22 11:45:26 UTC
Permalink
There seems to be a certain category of questions that comes up in
threads about specific agile practices; in this case, using points to
size stories instead of estimating in terms of time.

The category consists of questions in which the frame of reference is
altered such that the environment in which the project operates is
fundamentally non-agile. Then, the questioner demands to know how the
particular agile practice could possibly work in that environment.

The short answer is, it wouldn't (necessarily) work at all, or it
wouldn't work very well. We need to address the fundamental problems
first.

Here we have a customer who insists on two things: (1) A specific
delivery date, and (2) a specific team size. It sounds like a customer
who thinks of IT projects in the traditional way.

I think it represents a starting point for discussion about what can
be delivered and when it can be delivered. The customer may come to an
understanding of fixed timelines with variable scope, or some other
variation. But I don't think it would be productive to accept the
terms (1) and (2) without any clarification or negotiation.

Ideally, this discussion would take place before the project even
started. If it is already too late for that, then it seems to me the
discussion should occur as soon as possible. That way, we could cut
our losses and "reset" on a better track. Otherwise, the parameters
(1) and (2) sound pretty risky to me.

Dave
Post by Micron Engineering
Post by William Pietri
I mentioned this to Tobias in person, but I thought I'd say something
here, too.
....
Personally, I don't bother estimating tasks. I like doing task
breakdowns a lot, and once an iteration's stories are tasked I think
it's worth pausing a bit to see if people still feel we took on the
right amount of work.
What type of estimate and management plan do you propose to a customer
asking to have its software before an exact day?
Suppose that your team can't be larger then 6 sw engineers can you
explain me how can you make an estimation to predict the end of work for
a 1000 points sw starting today supposing 25 hours for week working time
for all 6 engineers?
Post by William Pietri
Hoping that helps,
William
------------------------------------------------------------------------
Post by Micron Engineering
Post by William Pietri
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.467 / Virus Database: 269.7.6/814 - Release Date: 21/05/2007 14.01
[Non-text portions of this message have been removed]
To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
William Pietri
2007-05-22 12:49:42 UTC
Permalink
Post by Micron Engineering
What type of estimate and management plan do you propose to a customer
asking to have its software before an exact day?
Suppose that your team can't be larger then 6 sw engineers can you
explain me how can you make an estimation to predict the end of work for
a 1000 points sw starting today supposing 25 hours for week working time
for all 6 engineers?
I tell them that for a new team, I've never seen anybody make useful
predictions. There are too many unknowns.

If they want software before an exact day, then we should start
development and build the highest priority things first. They can then
adjust scope to meet their exact day.

They aren't always exactly happy with that, but I would rather have them
be unhappy now then unhappy when, as with so many projects, the initial
"estimates" are exposed for the fiction they are.

William


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Jim
2007-05-22 12:26:58 UTC
Permalink
Estimating in points is new to me. We always estimated in perfect
engineering hours (and used delphi to get the estimate) for each
task within a story. To manage this process, we used an excel
spreadsheet - Define the list of stories that the customer wants for
the iteration, create tasks that will tell that story, estimate PE
hours, assign risk factor (H, M, L - how confident is your estimate -
group consensus) and get the loaded estimate. The spreadsheet is
nice because it can give you a running total for the number of
engineering hours you have in the iteration and we would do a mail
merge with MS Word to generate a task card for each task to hang on
the iteration wall gantt.

The trick was assigning the load factor/risk factor values. At the
beginning of the project - without any velocity measurements/data
present - it was a WAG. Fortunately, our team was used to working
together and we'd get pretty close. After the first couple
iterations, the load factors stabilized. Estimates became more and
more accurate.

I might consider using story points. But I'd feel more comfortable
seeing this technique in practice first. I'd probably be concerned
in changing a particular team's estimation practice from one to the
other - once you get into a groove, why change it. If the estimates
are consistently off, low or high, then load factors adjust/correct
to a more reasonable estimate.

time based estimations worked for me in the past. I will say that
the up front planning and management of the math of time based task
estimation can seem over engineered, but it worked for us.

That said, I might be convinced that we used story point estimations
for RFPs. We'd do a discovery session to get enough information to
assemble user stories, estimate using delphi and throw those
estimates into a proprietary tool/algorithm for final macro estimate
of the total effort. (Yeah, we were "forced" into doing this - the
client had a due date and a budget. We had to re-inforce that these
were estimates and not promises. Turns out our estimates were
eerily accurate at a critical phase of the project.)

Jim
Post by William Pietri
I mentioned this to Tobias in person, but I thought I'd say
something
Post by William Pietri
here, too.
Post by Tobias Mayer
Has anyone on this list found that real time estimation is
useful in an Agile context (actually, in any context)? I'd be very
interested to hear about it. Thanks.
Post by William Pietri
I've heard of teams that can estimate well in real time, but I
have
Post by William Pietri
never seen it in practice.
With points, on the other hand, I've seen a number of teams reach eerily
steady velocities, and a very good record of finishing the work they've
taken on. I expect that process of reaching stability to take
eight
Post by William Pietri
weeks, plus or minus.
My theory is that a lot of the magic of points-based estimation
is in
Post by William Pietri
what questions it dodges. The biggest one is the eternal, "If you got 12
hours of work done last week, what did you do with the other 28 hours we
were paying you for?"
A big bonus is that hours-based estimation seems to encourage
people to
Post by William Pietri
do a lot of ridiculously unsupportable math. The classic version is the
theory that nine women can make a baby in a month. The no less
popular
Post by William Pietri
version is that if you work twice as many hours, you'll get twice as
much work done. But there are a host of others.
Personally, I don't bother estimating tasks. I like doing task
breakdowns a lot, and once an iteration's stories are tasked I
think
Post by William Pietri
it's worth pausing a bit to see if people still feel we took on the
right amount of work.
Hoping that helps,
William
To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Micron Engineering
2007-05-22 12:58:10 UTC
Permalink
Estimating in points is new to me. We always estimated in perfect
engineering hours (and used delphi to get the estimate) for each
task within a story. To manage this process, we used an excel
spreadsheet - Define the list of stories that the customer wants for
the iteration, create tasks that will tell that story, estimate PE
hours, assign risk factor (H, M, L - how confident is your estimate -
group consensus) and get the loaded estimate. The spreadsheet is
nice because it can give you a running total for the number of
engineering hours you have in the iteration and we would do a mail
merge with MS Word to generate a task card for each task to hang on
the iteration wall gantt.
is it possible to have a copy of that spreadsheet?
The trick was assigning the load factor/risk factor values. At the
beginning of the project - without any velocity measurements/data
present - it was a WAG. Fortunately, our team was used to working
together and we'd get pretty close. After the first couple
iterations, the load factors stabilized. Estimates became more and
more accurate.
I might consider using story points. But I'd feel more comfortable
seeing this technique in practice first. I'd probably be concerned
in changing a particular team's estimation practice from one to the
other - once you get into a groove, why change it. If the estimates
are consistently off, low or high, then load factors adjust/correct
to a more reasonable estimate.
time based estimations worked for me in the past. I will say that
the up front planning and management of the math of time based task
estimation can seem over engineered, but it worked for us.
That said, I might be convinced that we used story point estimations
for RFPs. We'd do a discovery session to get enough information to
assemble user stories, estimate using delphi and throw those
estimates into a proprietary tool/algorithm for final macro estimate
of the total effort. (Yeah, we were "forced" into doing this - the
client had a due date and a budget. We had to re-inforce that these
were estimates and not promises. Turns out our estimates were
eerily accurate at a critical phase of the project.)
Jim
<mailto:extremeprogramming%40yahoogroups.com>, William Pietri
Post by William Pietri
I mentioned this to Tobias in person, but I thought I'd say
something
Post by William Pietri
here, too.
Post by Tobias Mayer
Has anyone on this list found that real time estimation is
useful in an Agile context (actually, in any context)? I'd be very
interested to hear about it. Thanks.
Post by William Pietri
I've heard of teams that can estimate well in real time, but I
have
Post by William Pietri
never seen it in practice.
With points, on the other hand, I've seen a number of teams reach
eerily
Post by William Pietri
steady velocities, and a very good record of finishing the work
they've
Post by William Pietri
taken on. I expect that process of reaching stability to take
eight
Post by William Pietri
weeks, plus or minus.
My theory is that a lot of the magic of points-based estimation
is in
Post by William Pietri
what questions it dodges. The biggest one is the eternal, "If you
got 12
Post by William Pietri
hours of work done last week, what did you do with the other 28
hours we
Post by William Pietri
were paying you for?"
A big bonus is that hours-based estimation seems to encourage
people to
Post by William Pietri
do a lot of ridiculously unsupportable math. The classic version
is the
Post by William Pietri
theory that nine women can make a baby in a month. The no less
popular
Post by William Pietri
version is that if you work twice as many hours, you'll get twice
as
Post by William Pietri
much work done. But there are a host of others.
Personally, I don't bother estimating tasks. I like doing task
breakdowns a lot, and once an iteration's stories are tasked I
think
Post by William Pietri
it's worth pausing a bit to see if people still feel we took on
the
Post by William Pietri
right amount of work.
Hoping that helps,
William
------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.467 / Virus Database: 269.7.6/814 - Release Date: 21/05/2007 14.01
[Non-text portions of this message have been removed]



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Chris Wheeler
2007-05-26 00:54:28 UTC
Permalink
Post by William Pietri
My theory is that a lot of the magic of points-based estimation is in
what questions it dodges. The biggest one is the eternal, "If you got 12
hours of work done last week, what did you do with the other 28 hours we
were paying you for?"
I've written before that I've had the most success when I've 'estimated'
(I'd rather call them commitments) using the method Kent describes, namely
'this will take me 5 hours and I'll be done by Wednesday'. It's clear
language that requires no translation and is completely honest.

The reason I like it is because it invites the question, 'If you have 24
hours between Monday and Wednesday, why will it take you that long to do 5
hours worth of work?'. I want to be able to account for my time to those
who are paying me and have them determine if I am spending their time and
money in a way that is consistent with what they see as valuable.

Chris.


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



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Steven Gordon
2007-05-26 01:22:10 UTC
Permalink
Post by Chris Wheeler
Post by William Pietri
My theory is that a lot of the magic of points-based estimation is in
what questions it dodges. The biggest one is the eternal, "If you got 12
hours of work done last week, what did you do with the other 28 hours we
were paying you for?"
I've written before that I've had the most success when I've 'estimated'
(I'd rather call them commitments) using the method Kent describes, namely
'this will take me 5 hours and I'll be done by Wednesday'. It's clear
language that requires no translation and is completely honest.
The reason I like it is because it invites the question, 'If you have 24
hours between Monday and Wednesday, why will it take you that long to do 5
hours worth of work?'. I want to be able to account for my time to those
who are paying me and have them determine if I am spending their time and
money in a way that is consistent with what they see as valuable.
Chris.
Just because estimates in hours is appropriate for short-term
commitments during the iterations does not imply that the estimates of
stories in the product backlog must or should also be in hours. Doing
so requires frequent revisions of estimates as the team gets faster
(or slower) and gives the customer a false precision that will lead to
frequent disappointment and miscommunication.

It is at this macro level where story points allows iterative
calibration via the team's changing velocity to adjust the long-term
level planning to reality without costly reestimation and gives the
customer the appropriate level of precision for long term planning.

Steve


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Kent Beck
2007-05-29 18:22:25 UTC
Permalink
Steve,

Accountability and transparency remain important concepts at larger scales
of estimation, so time-based or money-based estimates are still appropriate.
As the scale increases you may want to increase the units, estimating in
days, weeks, or months as appropriate. In practice I haven't found the cost
of re-estimation to be significant. Quite the opposite. Periodically
re-estimating the remaining work is a valuable opportunity to step back and
examine everything you might want to do in the future and become aware of
how certain kinds of work have become easier or harder.

Regards,

Kent Beck
Three Rivers Institute

_____

From: ***@yahoogroups.com
[mailto:***@yahoogroups.com] On Behalf Of Steven Gordon
Sent: Friday, May 25, 2007 6:22 PM
To: ***@yahoogroups.com
Subject: Re: [XP] Estimation: Time or Size?




Just because estimates in hours is appropriate for short-term
commitments during the iterations does not imply that the estimates of
stories in the product backlog must or should also be in hours. Doing
so requires frequent revisions of estimates as the team gets faster
(or slower) and gives the customer a false precision that will lead to
frequent disappointment and miscommunication.

It is at this macro level where story points allows iterative
calibration via the team's changing velocity to adjust the long-term
level planning to reality without costly reestimation and gives the
customer the appropriate level of precision for long term planning.

Steve


Recent Activity

*

26
New
<http://groups.yahoo.com/group/extremeprogramming/members;_ylc=X3oDMTJmYWdsa
XBvBF9TAzk3MzU5NzE0BGdycElkAzE1MDU0MDkEZ3Jwc3BJZAMxNzA3Mjc2NzE4BHNlYwN2dGwEc
2xrA3ZtYnJzBHN0aW1lAzExODAxNDMxMzQ-> Members

Visit
<http://groups.yahoo.com/group/extremeprogramming;_ylc=X3oDMTJlZzVmMTg3BF9TA
zk3MzU5NzE0BGdycElkAzE1MDU0MDkEZ3Jwc3BJZAMxNzA3Mjc2NzE4BHNlYwN2dGwEc2xrA3Zna
HAEc3RpbWUDMTE4MDE0MzEzNA--> Your Group
Yahoo! Finance

It's
<http://us.ard.yahoo.com/SIG=12jqdrmce/M=493064.10729649.11333340.8674578/D=
groups/S=1707276718:NC/Y=YAHOO/EXP=1180150334/A=4507179/R=0/SIG=12de4rskk/*h
ttp://us.rd.yahoo.com/evt=50284/*http://finance.yahoo.com/personal-finance>
Now Personal

Guides, news,

advice & more.

Ads on Yahoo!

Learn
<http://us.ard.yahoo.com/SIG=12jcc25l1/M=493064.10729656.11333347.8674578/D=
groups/S=1707276718:NC/Y=YAHOO/EXP=1180150334/A=3848643/R=0/SIG=131q47hek/*h
ttp://searchmarketing.yahoo.com/arp/srchv2.php?o=US2005&cmp=Yahoo&ctv=Groups
4&s=Y&s2=&s3=&b=50> more now.

Reach customers

searching for you.

Yahoo! Groups

Take
<http://us.ard.yahoo.com/SIG=12juer1ru/M=493064.10771301.11374985.8674578/D=
groups/S=1707276718:NC/Y=YAHOO/EXP=1180150334/A=4609192/R=0/SIG=11n05oee3/*h
ttp://www.myfeedback.cfigroup.com/launch/svy307.html> a Survey

express your ideas

share your opinion

.

<http://geo.yahoo.com/serv?s=97359714/grpId=1505409/grpspId=1707276718/msgId
=129597/stime=1180143134/nc1=4507179/nc2=3848643/nc3=4609192>



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



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
William Pietri
2007-05-26 03:09:59 UTC
Permalink
Post by Chris Wheeler
Post by William Pietri
My theory is that a lot of the magic of points-based estimation is in
what questions it dodges. The biggest one is the eternal, "If you got 12
hours of work done last week, what did you do with the other 28 hours we
were paying you for?"
[...]
The reason I like it is because it invites the question, 'If you have 24
hours between Monday and Wednesday, why will it take you that long to do 5
hours worth of work?'. I want to be able to account for my time to those
who are paying me and have them determine if I am spending their time and
money in a way that is consistent with what they see as valuable.
I think if you have a strong relationship with a boss who has both time
and inclination to explore the interesting question of where the time
goes, that can be lots of fun.

If you are at the beginning of a relationship, if the relationship is
currently rocky, if the customer is pretty busy, or if they are mainly
interested in what you can produce rather than how you produce it, then
approaching it that way can cause a very large amount of entirely
needless trouble.

I think it's important for everybody to be willing to be transparent.
But I think one should, by default, give the simplest interface possible
to the customer. If they ask to peek behind that, go wild. But until
they ask, why force the quotidian details upon them?

William



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Chris Wheeler
2007-05-26 04:46:31 UTC
Permalink
Post by William Pietri
If you are at the beginning of a relationship, if the relationship is
currently rocky, if the customer is pretty busy, or if they are mainly
interested in what you can produce rather than how you produce it, then
approaching it that way can cause a very large amount of entirely
needless trouble.
What kind of trouble have you experienced or do you anticipate experiencing?


I think it's important for everybody to be willing to be transparent.
Post by William Pietri
But I think one should, by default, give the simplest interface possible
to the customer. If they ask to peek behind that, go wild. But until
they ask, why force the quotidian details upon them?
There are two pieces of information I'm giving: when to expect the feature,
and how long I'll spend on it. In lean terms, I'm sharing the cycle time
divided into touch time (value added time) and delay time (non-value added
time). I don't think that's too much information. Here's why.

When I want to build a trust relationship with someone, the first thing I'm
going to do is show them I'm worthy of trust. That means I'll make a
commitment and my delivery will meet or exceed expectations. The next thing
I'm going to do (or rather, at the same time) is make sure that I show that
I think that the other party is worthy of my trust by sharing information
with them. What I've found happens is that the other party will show
interest ('tell me why there's so much wasted time'), I'll tell them ('well,
I have a daily status meeting for an hour, and each Tuesday we've got the
weekly con call that all dev's need to go to, and then there is the hour
long ISO training this afternoon...'), and the other party will either
understand and accept it, or they will become your champion and help to
remove barriers that they feel will help get more touch-time on their
feature.

So, I'm not entirely convinced that the best approach is to assume a stance
of 'don't ask don't tell'; rather, start with a stance of 'I trust you, and
you'll have to do a lot to lose my trust'.

Chris.


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



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Tim Ottinger
2007-05-23 02:24:20 UTC
Permalink
I would use division. If we are running 10 +/- 1 story points per iteration, then a story point is one tenth of an iteration (right now). Likewise, if I have 180 story points to complete my project/product, then it will be 18 iterations more (180/10) if nothing changes.

And if next iteration is 12 points, then one point is 1/12th of an iteration in time, and we'll need only 15 more iterations to complete the project.

I may be ignorant, but I don't know why that's not enough. I can estimate, graph, and work with it. And, of course, if you dictate velocity rather than measuring it, then there is no way to convert between the velocity and actual time, because it's just multiplying a lie by a fantasy.

All the normal arguments against "xxxx days" and "xxxx hours" will apply.


----- Original Message ----
From: Daniel Wildt <***@gmail.com>
To: ***@yahoogroups.com
Sent: Monday, May 21, 2007 5:28:27 PM
Subject: RES: [XP] Estimation: Time or Size?

And how do you guys translate story points to the real time?

Are you guys using some kind of load factor calculation?

I like to estimate using ideal hours, so the formula goes like:
ideal hours x load factor = expected time

Regards,
Daniel Wildt
HYPERLINK "http://danielwildt.blogspot.com"http://danielwildt.blogspot.com






_____

De: ***@yahoogroups.com [mailto:***@yahoogroups.com] Em nome de Steven Gordon
Enviada em: segunda-feira, 21 de maio de 2007 15:04
Para: ***@yahoogroups.com
Assunto: Re: [XP] Estimation: Time or Size?




I have been recommending that teams obtain the best advantages of both real
time and abstract estimation by using story points for release planning (i.e.,
the product backlog) and real time estimation for sprint/iteration planning
(i.e., the task board).

This allows for long-term calibration of story points to avoid continuous
re-estimation of stories and support a meaningful interpretation of evolving
velocities. It also allows for improving real time estimation of what can
be finished on a sprint by sprint basis.

Steve Gordon
Post by Tobias Mayer
I have recently come across a few people in the Agile field who prefer
estimating in "real time" over estimating in size (e.g. story points); I
have even heard statements such as: the most advanced implementations of
Agile use real time estimates, because it offers the most powerful benefits.
It intrigued me, so I wrote a blog about it: Estimation: Time or Size?
Has anyone on this list found that real time estimation is useful in an
Agile context (actually, in any context)? I'd be very interested to hear
about it. Thanks.
Tobias Mayer
HYPERLINK "http://agilethinking.net"http://agilethinkin-g.net
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]






No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.467 / Virus Database: 269.7.6/814 - Release Date: 21/05/2007 14:01



No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.467 / Virus Database: 269.7.6/814 - Release Date: 21/05/2007 14:01



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



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

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











____________________________________________________________________________________Yahoo! oneSearch: Finally, mobile search
that gives answers, not web links.
http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC

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



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Kent Beck
2007-05-25 16:44:42 UTC
Permalink
Tobias,

I don't know about "most advanced", but real time estimating certainly has
some advantages. In particular, it is immediately understandable to
anyone--"this will take me six working hours and you'll have it Wednesday".
I've heard of people estimating in money, which emphasizes a different side
of accountability.

Real-time estimation has been explored and written about by Francesco
Cirillo in his pomodoro papers. I found one by Piergiuliano Bossi on google
books.

Regards,

Kent Beck
Three Rivers Institute

_____

From: ***@yahoogroups.com
[mailto:***@yahoogroups.com] On Behalf Of Tobias Mayer
Sent: Monday, May 21, 2007 9:43 AM
To: ***@yahoogroups.com
Subject: [XP] Estimation: Time or Size?



I have recently come across a few people in the Agile field who prefer
estimating in "real time" over estimating in size (e.g. story points); I
have even heard statements such as: the most advanced implementations of
Agile use real time estimates, because it offers the most powerful benefits.

It intrigued me, so I wrote a blog about it: Estimation: Time or Size?

Has anyone on this list found that real time estimation is useful in an
Agile context (actually, in any context)? I'd be very interested to hear
about it. Thanks.

Tobias Mayer
<http://agilethinking.net> http://agilethinking.net

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






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



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Loading...