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

estimation advice

Expand Messages
  • robotnik23@yahoo.com
    hi, My company is trying to adopt XP, and we have our first planning game meeting this week. I have a few questions about estimation: 1) how do you account
    Message 1 of 2 , Dec 4, 2000
    • 0 Attachment
      hi,

      My company is trying to adopt XP, and we have our first planning game
      meeting this week. I have a few questions about estimation:

      1) how do you account for customers who are not used to really
      specifying things out in advance, but who wish to give a vague
      direction "build a login screen", and then critique it iteratively
      until they like it? my developers tend to estimate only the time it
      would take to implement the first reviewable code, and then we get
      hammered on all the follow-up requests/changes/scope creep.. any
      suggestions? we could pad our estimates to account for this, or
      increase the load factor?


      2) at the end of each iteration you adjust your load factor. how do
      you know that it was the load factor that was wrong, instead of
      simply being a matter of under-estimation? is it simply a matter of
      asking the developers "did it take longer because you were always
      getting dragged off to support calls and other stuff, or because it
      was harder than you thought it'd be?"


      thanks!

      -- James
    • Kevin Smith
      ... It seems prudent to factor expected rework into your estimates. I wouldn t call it padding. As someone else said, this is a great case for XP. If the
      Message 2 of 2 , Dec 4, 2000
      • 0 Attachment
        On Mon, 04 Dec 2000 09:55:55 +0000 <robotnik23@...> wrote:

        > hi,
        >
        > My company is trying to adopt XP, and we have our first planning game
        > meeting this week. I have a few questions about estimation:
        >
        > 1) how do you account for customers who are not used to really
        > specifying things out in advance, but who wish to give a vague
        > direction "build a login screen", and then critique it iteratively
        > until they like it? my developers tend to estimate only the time it
        > would take to implement the first reviewable code, and then we get
        > hammered on all the follow-up requests/changes/scope creep.. any
        > suggestions? we could pad our estimates to account for this, or
        > increase the load factor?

        It seems prudent to factor expected rework into your
        estimates. I wouldn't call it padding. As someone else said,
        this is a great case for XP. If the customer is involved
        frequently during development, you maximize the chances of
        ending up with a happy customer on the first delivery, with
        minimal rework.

        > 2) at the end of each iteration you adjust your load factor. how do
        > you know that it was the load factor that was wrong, instead of
        > simply being a matter of under-estimation? is it simply a matter of
        > asking the developers "did it take longer because you were always
        > getting dragged off to support calls and other stuff, or because it
        > was harder than you thought it'd be?"

        As someone else mentioned, velocity takes care of that.
        "Yesterday's weather" is the requisite XP soundbite. You
        might think productivity was low this iteration because of
        extra meetings, or vactions, or the flu. But odds are,
        something will cause a similar effect next iteration.

        If not, you can take on some extra tasks with that "found"
        time, and your velocity will automatically be higher going
        into the next iteration.

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