Loading ...
Sorry, an error occurred while loading the content.

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

Expand Messages
  • Jeff Oberlander
    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
      > Task complete

      > 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
      > not and adjust accordingly.
      >

      >
      > --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
      >
      > Upgrade JDom
      >
      > 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...
      >
      >
      >
      > Yahoo! Groups Sponsor     
      >
      > ADVERTISEMENT

      >
      <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
      > p://companion.yahoo.com> click here     

      > <http://us.adserver.yahoo.com/l?
      M=295196.4901138.6071305.3001176/D=group
      > s/S=:HM/A=2128215/rand=335406978>      
      >
      >
      >   _____ 
      >
      > Yahoo! Groups Links
      >
      >
      > *      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.