## Estimating w/pretty sures

Expand Messages
• We are estimating stories with 50% and 90% confidence points. And then calculating the themes with squareRoot( sumAllStoriesInTheme( 90% point - 50% point ) ^
Message 1 of 9 , Jun 21, 2009
• 0 Attachment
We are estimating stories with 50% and 90% confidence points. And then calculating the themes with squareRoot( sumAllStoriesInTheme( 90% point - 50% point ) ^ 2). From this formula we say that, it is very low probability that everthing will go bad. But, a few of them may go bad.

But, we are committing to each theme w/90% confidence points. Because, if we don't do that so the management can say that it's a failure. They want exact numbers.

What do you think, is this monkey business? What could we do better to improve communication? Giving estimations in range doesn't work here.
• Yes, it s monkey business, but you are dealing with monkeys, unfortunately. Frankly, I think sacrificing some chickens at midnight on Sunday, especially if
Message 2 of 9 , Jun 21, 2009
• 0 Attachment
Yes, it's monkey business, but you are dealing with monkeys, unfortunately.

Frankly, I think sacrificing some chickens at midnight on Sunday, especially if there is a full moon, and dripping the blood on the head of the PO would be just as good an estimation method (a little less humane, perhaps).

But I see your predicament (apart from the lack of chickens ).  Your management somehow thinks that you can prophecy the future with complete accuracy. This sort of fortune telling and soothsaying is actually illegal in some countries, especially if you do it for money. Some countries consider it as fraud, to claim to be able to foretell the future. Perhaps you can investigate this, and tell the managers that they are in danger of acting illegally, by aiding and abetting a crime. That may change their ideas.

Regards,
Roy Morien

To: scrumdevelopment@yahoogroups.com
From: inanc.gumus@...
Date: Sun, 21 Jun 2009 17:07:52 +0000
Subject: [scrumdevelopment] Estimating w/pretty sures

We are estimating stories with 50% and 90% confidence points. And then calculating the themes with squareRoot( sumAllStoriesInThem e( 90% point - 50% point ) ^ 2). From this formula we say that, it is very low probability that everthing will go bad. But, a few of them may go bad.

But, we are committing to each theme w/90% confidence points. Because, if we don't do that so the management can say that it's a failure. They want exact numbers.

What do you think, is this monkey business? What could we do better to improve communication? Giving estimations in range doesn't work here.

Make ninemsn your homepage! Get the latest news, goss and sport
• Hi - We do this all the time in engineering - the real problem is risk & inherent uncertainty, but we instead turn it into a technical problem and devise
Message 3 of 9 , Jun 21, 2009
• 0 Attachment
Hi -

We do this all the time in engineering - the real problem is risk &
inherent uncertainty, but we instead turn it into a "technical" problem
and devise technical solutions, like attempting to quantify our
uncertainty.

Our work is complex and carries some amount of risk that no amount of
estimation effort can ever remove. When one group has power over another
(e.g. in fixed price contracts), they often will try to force the weaker
party to bear all the burden of risk. When it is risk that neither party
has effective control over, then both sides lose. The weaker party has
to charge a risk premium in some form (maybe as padded estimates, or as
explicit insurance if the transaction is between companies), but that
does not reduce the probability the risk will materialize.

Once you're doing the practical things that can control for risks
(continuous integration, good unit tests, etc) the rest is a power game
where the stronger party is trying to make the weaker one own the risk.
Good management involves recognizing these dysfunctions and owning the
risks at the proper levels.

BTW, quantifying our uncertainty can be useful in lots of cases. I'm
not saying don't do that. Just that you cannot remove risk by doing that.

- njv

inanc_gumus wrote:
> We are estimating stories with 50% and 90% confidence points. And then calculating the themes with squareRoot( sumAllStoriesInTheme( 90% point - 50% point ) ^ 2). From this formula we say that, it is very low probability that everthing will go bad. But, a few of them may go bad.
>
> But, we are committing to each theme w/90% confidence points. Because, if we don't do that so the management can say that it's a failure. They want exact numbers.
>
> What do you think, is this monkey business? What could we do better to improve communication? Giving estimations in range doesn't work here.
>
>
>
> ------------------------------------
>
> To Post a message, send it to: scrumdevelopment@...
> To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links
>
>
>
>
>

--
............................................
Nancy Van Schooenderwoert, Lean-Agile Partners Inc.

781 301 1822 US mobile
nancyv@...

http://www.leanagilepartners.com

Specialties: Agile coaching for Embedded Systems, for Data Migrations,
and for leadership of Lean-Agile change organization wide
............................................
• Estimation has a lot of similarities to economics, fortune telling and religion. First you have to believe in it and also believe that what you believe is only
Message 4 of 9 , Jun 21, 2009
• 0 Attachment
Estimation has a lot of similarities to economics, fortune telling and religion. First you have to believe in it and also believe that what you believe is only partially right. Second you have to be convinced there is an answer and that you will recognize it as it sneaks by you. Finally you need some form of evolving ceremony that you are convinced you can learn to perform perfectly once and finally get it right.

The other option is to have faith that you can incremental improve and thus be less wrong than the last time. I favor the latter

Sent via BlackBerry by AT&T

From: Nancy Van Schooenderwoert
Date: Sun, 21 Jun 2009 16:44:32 -0400
To: <scrumdevelopment@yahoogroups.com>
Subject: Re: [scrumdevelopment] Estimating w/pretty sures

Hi -

We do this all the time in engineering - the real problem is risk &
inherent uncertainty, but we instead turn it into a "technical" problem
and devise technical solutions, like attempting to quantify our
uncertainty.

Our work is complex and carries some amount of risk that no amount of
estimation effort can ever remove. When one group has power over another
(e.g. in fixed price contracts), they often will try to force the weaker
party to bear all the burden of risk. When it is risk that neither party
has effective control over, then both sides lose. The weaker party has
to charge a risk premium in some form (maybe as padded estimates, or as
explicit insurance if the transaction is between companies), but that
does not reduce the probability the risk will materialize.

Once you're doing the practical things that can control for risks
(continuous integration, good unit tests, etc) the rest is a power game
where the stronger party is trying to make the weaker one own the risk.
Good management involves recognizing these dysfunctions and owning the
risks at the proper levels.

BTW, quantifying our uncertainty can be useful in lots of cases. I'm
not saying don't do that. Just that you cannot remove risk by doing that.

- njv

inanc_gumus wrote:

> We are estimating stories with 50% and 90% confidence points. And then calculating the themes with squareRoot( sumAllStoriesInThem e( 90% point - 50% point ) ^ 2). From this formula we say that, it is very low probability that everthing will go bad. But, a few of them may go bad.
>
> But, we are committing to each theme w/90% confidence points. Because, if we don't do that so the management can say that it's a failure. They want exact numbers.
>
> What do you think, is this monkey business? What could we do better to improve communication? Giving estimations in range doesn't work here.
>
>
>
> ------------ --------- --------- ------
>
> To Post a message, send it to: scrumdevelopment@ eGroups.com
> To Unsubscribe, send a blank message to: scrumdevelopment- unsubscribe@ eGroups.comYahoo! Groups Links
>
>
>
>
>

--
............ ......... ......... ......... .....
Nancy Van Schooenderwoert, Lean-Agile Partners Inc.

781 301 1822 US mobile
nancyv@leanagilepar tners.com

http://www.leanagil epartners. com

Specialties: Agile coaching for Embedded Systems, for Data Migrations,
and for leadership of Lean-Agile change organization wide
............ ......... ......... ......... .....

• Playing with numbers won t help. Fix the real problem , don t hide it behind numbers and percentages.
Message 5 of 9 , Jun 21, 2009
• 0 Attachment
Playing with numbers won't help.
Fix the real problem , don't hide it behind numbers and percentages.

On Sun, Jun 21, 2009 at 8:07 PM, inanc_gumus<inanc.gumus@...> wrote:
>
>
> We are estimating stories with 50% and 90% confidence points. And then
> calculating the themes with squareRoot( sumAllStoriesInTheme( 90% point -
> 50% point ) ^ 2). From this formula we say that, it is very low probability
> that everthing will go bad. But, a few of them may go bad.
>
> But, we are committing to each theme w/90% confidence points. Because, if we
> don't do that so the management can say that it's a failure. They want exact
> numbers.
>
> What do you think, is this monkey business? What could we do better to
> improve communication? Giving estimations in range doesn't work here.
>
>
• Hi - new to this group, but adding my .02 I agree with all comments. I work for an integrator and we are ritually defending why estimates are estimates , not
Message 6 of 9 , Jun 23, 2009
• 0 Attachment
Hi - new to this group, but adding my .02

I agree with all comments. I work for an integrator and we are ritually defending why estimates are "estimates", not "actuals".

First, you need an estimating methodology that gives you the highest confidence and lowest risk possible, under the circumstances of what you know. Then, you have to go back to your management (perhaps your direct manager first one-on-one) and get them to understand what an estimate is and how you arrive at it. You have to sell it, and if they don't buy it's because they are choosing to be ignorant about the fundamental problem of predicting the future.

Hey, if I (or someone I knew on my team) could accurately predict the future, I'd be making money in the stock market, not running projects! :)

cheers-
Kevin
• You don t have an estimation problem, you have a communication problem. I would sit down with management and ask them what their goal is here. Focus on what
Message 7 of 9 , Jun 23, 2009
• 0 Attachment
You don't have an estimation problem, you have a communication problem. I would sit down with management and ask them what their goal is here. Focus on what problem they're trying to solve. If they say "knowing when we will be done", ask why or what wil they gain from that. Keep asking questions until you find their underlying issue. Then help them reframe the problem in a way that works for them. Telling the team to measure better just doesn't work.

Cheers
Mark
 Mark Levison - Agile/Lean Transition Coach || Agile Editor @ InfoQ ||
 613-862-2538 (cell) || Twitter || Blog Recent Entries:
 Agile Mailing Lists a Survey || Do You Suspect You Have a Less than Productive Person on Your Team?
• Sounds like you d be better served with using the principles of Velocity as opposed to trying to figure out a new formula. Average the amount of user stories
Message 8 of 9 , Jun 23, 2009
• 0 Attachment
Sounds like you'd be better served with using the principles of Velocity as opposed to trying to figure out a new formula.

Average the amount of user stories that were COMPLETED on the past 3 sprints. This gives you your "Velocity" then you can see each "theme" or "Release" has X amount of Effort estimated to them. Simply divide the theme by the velocity to get an estimate of how many iterations it will take to complete the theme/release.

• ... My view: If they say knowing when we will be done , ask for a reasonable date to be done, and then manage scope to be done on that day. After all, you re
Message 9 of 9 , Jun 23, 2009
• 0 Attachment
Hello, Mark. On Tuesday, June 23, 2009, at 3:05:31 PM, you wrote:

> You don't have an estimation problem, you have a communication problem. I
> would sit down with management and ask them what their goal is here. Focus
> on what problem they're trying to solve. If they say "knowing when we will
> be done", ask why or what wil they gain from that. Keep asking questions
> until you find their underlying issue. Then help them reframe the problem in
> a way that works for them. Telling the team to measure better just doesn't
> work.

My view: If they say "knowing when we will be done", ask for a
reasonable date to be done, and then manage scope to be done on that
day. After all, you're done at the end of every Sprint. Just ship
it.

Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
You do ill if you praise, but worse if you censure,
what you do not understand. --Leonardo da Vinci
Your message has been successfully submitted and would be delivered to recipients shortly.