## RE: [scrumdevelopment] Re: Estimating non-coding tasks

Expand Messages
• Yes, thank you. Measurement of risk is what I was getting at ( impossible to predict the affects... ). Risk is a helpful way to view the problem. - thx ...
Message 1 of 12 , Sep 27, 2004
• 0 Attachment
Message
Yes, thank you.  Measurement of risk is what I was getting at ("impossible to predict the affects...").  Risk is a helpful way to view the problem. - thx
-----Original Message-----
From: Deb [mailto:deborah@...]
Sent: Friday, September 24, 2004 6:15 PM
To: scrumdevelopment@yahoogroups.com
Subject: [scrumdevelopment] Re: Estimating non-coding tasks

Are you asking how to handle risk? If so, it could go like this ...

As you discuss and come up with your 8 hour estimate, someone
says "but what if x happens?". The question is: how likely is "x"? If
it's a small likelihood, ignore it. If it's a large likelihood (how
DO you spell that?) then buffer your numbers up. If it's a medium
likelihood... you get it.

It may all seem somewhat arbitrary (and in Sprint 1 it sometimes is).
However, our internal computers work waaay better than spreadsheets,
and seasoned developers will learn to trust themselves as they pull
good numbers out of the air, based on their intuition. (Intuition is
just what we call the lightning fast weighted calculations our brains
do, right?)

And we all know: the Sprint plan is obsolete on day 2 of the Sprint.
That's why we use the burndown. When your "what if" materialises,
Scrum gives you a way to handle it. If you buffered up and it doesn't
materialise, chances are that something else will instead...

--- In scrumdevelopment@yahoogroups.com, "Jeff Oberlander"
<jeff.oberlander@v...> wrote:
> Maybe.  There will be less systematic error if you estimate with the
> prediction that nothing will go wrong when applying the software
such
> as:

> 1.  Install service pack 1h
> 2.  Reconfigure 1h
> 3.  Regression test entire application 6h

> But what if after step 3, there are 5 new bugs - 1 takes an
escalation
> to the vendor and takes a week to resolve, 3 are minor configuration
> fixes, but 1 uncovers a design flaw that will require 2 weeks of
> refactoring?

> I'm saying, is it realistic to give an 8 hour estimate in sprint
> planning to a task that has a high likelihood of being some factor
> higher - and then isn't it more responsible to estimate to a higher
> number - and then back to my question - how to accurately guess that
> higher number which such a high degree of unpredictability until you
> actually do the task.  Do you see what I'm getting at?

>
> -----Original Message-----
> From: Mike Cohn [mailto:mike@m...]
> Sent: Thursday, September 23, 2004 1:45 PM
> To: scrumdevelopment@yahoogroups.com
> Subject: RE: [scrumdevelopment] Estimating non-coding tasks
>
>
>
> Why? From my experience a sprint like this is MORE predictable than
one
> of purely programming tasks. There is little systematic error in the
> estimates of the tasks below. That is, being long on one doesn't
> necessarily make you long on the others, like it often does with
> programming tasks. I suspect the estimation errors will balance out
far
> more than if they were all programming tasks. I include tasks like
these
> in almost all my sprints.
>

>
> --Mike Cohn
>
> Author of User Stories Applied for Agile Software Development
>
> www.mountaingoatsoftware.com
>
> www.userstories.com
>
>
>   _____
>
>
> From: Jeff Oberlander [mailto:jeff.oberlander@v...]
> Sent: Thursday, September 23, 2004 2:34 PM
> To: scrumdevelopment@yahoogroups.com
> Subject: RE: [scrumdevelopment] Estimating non-coding tasks
>

>
> Well thats all an estimate is is a guess right?  But I think this
is a
> pretty simplistic answer.  I could guess 1 day or I could guess 5
days -
> multiply that by 15 other similarly obscure tasks and you have a
very
> unpredictible sprint.  Sure, thats what the burndown chart and
> adjustments are for.  But in this case it gives me little help in
> determining what business features can be included in the sprint.
>

>
> Jeff
>
> -----Original Message-----
> From: Mike Cohn [mailto:mike@m...]
> Sent: Thursday, September 23, 2004 1:23 PM
> To: scrumdevelopment@yahoogroups.com
> Subject: RE: [scrumdevelopment] Estimating non-coding tasks
>
> Just take a guess. Take a guess on day 1 then start the task. If you
> find out the SP messes things up, increase the estimate on day 2.
use
> the burndown chart to keep an eye on whether you'll finish
everything or
>

>
> --Mike Cohn
>
> Author of User Stories Applied for Agile Software Development
>
>  <http://www.mountaingoatsoftware.com> www.mountaingoatsoftware.com
>
>  <http://www.userstories.com> www.userstories.com
>
>
>   _____
>
>
> From: Jeff Oberlander [mailto:jeff.oberlander@v...]
> Sent: Thursday, September 23, 2004 2:09 PM
> To: scrumdevelopment@yahoogroups.com
> Subject: [scrumdevelopment] Estimating non-coding tasks
>

>
> We're starting our first sprint and have decided that it is
primarily
> going to be a maintenance release to our recently released web
> application.  There are a lot of maintenance oriented tasks such as:
>

>
> Platform related:
>
> Upgrade App Server to Service Pack 3/test
>
> Install/test DB2 patch
>
>
> etc
>

>
> Tool related:
>
> Determine tool for automating acceptance tests
>
> Integrate acceptance test tool
>
> etc
>
> etc
>

>
> We plan on adding some business value functionality as well - but
don't
> know how much - how can you reliably estimate the amount of work the
> above tasks will take from the total time in the sprint.  They
aren't
> programming tasks, but largely installation, configuration, test,
and
> fix tasks.  The big problem I see is that it is impossible to
predict
> the affects of applying a Service Pack for an app server may have
to the
> application and where it may break it.  When we run into 3rd party
> issues, it involves opening up a service ticket with their tech
support,
> and then back and forth communication - sometimes it means getting
a hot
> fix/patch from them, which may take a day, may take a week - or
more.
> Repeat that one or two times with other issues in the 3rd party
software
> and you find yourself in a world of unpredictability.  This is very
> different from coding development and bug fixing.
>

>
> Jeff
>

>
>
>
> To Post a message, send it to:   scrumdevelopment@e...
> To Unsubscribe, send a blank message to:
> scrumdevelopment-unsubscribe@e...
>
>
>
>
>
>
> To Post a message, send it to:   scrumdevelopment@e...
> To Unsubscribe, send a blank message to:
> scrumdevelopment-unsubscribe@e...
>
>
>
>
>
> To Post a message, send it to:   scrumdevelopment@e...
> To Unsubscribe, send a blank message to:
> scrumdevelopment-unsubscribe@e...
>
>
>
>
>
>
>
> To Post a message, send it to:   scrumdevelopment@e...
> To Unsubscribe, send a blank message to:
> scrumdevelopment-unsubscribe@e...
>
>
>
>

>
<http://us.ard.yahoo.com/SIG=129ica29b/M=295196.4901138.6071305.300117
6/
>
D=groups/S=1707209021:HM/EXP=1096058749/A=2128215/R=0/SIG=10se96mf6/*h
tt

M=295196.4901138.6071305.3001176/D=group
> s/S=:HM/A=2128215/rand=335406978>
>
>
>   _____
>
>
>
> *      To visit your group on the web, go to:
> http://groups.yahoo.com/group/scrumdevelopment/
>
>
> *      To unsubscribe from this group, send an email to:
> scrumdevelopment-unsubscribe@yahoogroups.com
> <mailto:scrumdevelopment-unsubscribe@yahoogroups.com?
subject=Unsubscribe
> >
>
>
> *      Your use of Yahoo! Groups is subject to the Yahoo! Terms of
> Service <http://docs.yahoo.com/info/terms/> .

To Post a message, send it to:   scrumdevelopment@...
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...

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