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

Re: [XP] Re: Which is the best way to see the progress of project?

Expand Messages
  • Steven Gordon
    ... The external customer should be fully engaged in product backlog estimates and what they are likely to get at the end of every iteration (as well as
    Message 1 of 12 , Jan 31, 2007
    • 0 Attachment
      On 1/31/07, sergei.andrz <sergei.andrz@...> wrote:
      >
      > Steve,
      >
      > I think you made a very good note: what's better – to estimate work
      > and then freeze the original estimation trying to reach it or to allow
      > re-estimation during the development. I believe both ways have plusses
      > and minuses. We use the first way with the following exceptions: in
      > case of significant underestimation we correct it by introduction of
      > change request; in case of significant overestimation we correct it by
      > changing of the original estimation. We believe medium and small
      > deviations are statistically compensated and covered by XP Load Factor.
      >
      > Why do we believe first way is better for out specific situation?
      >
      > 1. We have an external customer which would like to have responsible
      > estimation before the development for XP iteration. Customer would
      > like to get commitment from us about iteration duration to calculate
      > expected project budget.

      The external customer should be fully engaged in product backlog
      estimates and what they are likely to get at the end of every
      iteration (as well as feedback on the intent of requirements and the
      acceptability of the working software being delivered). I believe
      that intimate involvement in task estimates is crossing the line.

      > 2. Re-estimation as a rule instead of re-estimation as an exception
      > slightly relaxes team during the Planning Game: developers know they
      > can re-estimate any time later why they should think too long to
      > estimate correctly? It also relaxes team during the development: 'I
      > should work hard today to finish the task, OK let's double the task
      > estimation and I go home now.'

      There is no such thing as correct estimates in software development.
      Since estimates are never accurate in software development, the idea
      is to waste less time trying to make perfect estimates and allow the
      calibration of velocity to compensate over time.

      What we need are consistent estimates, not ones with false precision.
      The time you spend trying to accurately estimate is not going to
      change how much time it will actually take, so it delivers more value
      to spend that time getting work done.

      This is why I and many others recommend using an abstract measure like
      story points for the stories instead of hours (ideal or otherwise).
      While real hours are recommended for helping the team self-organize
      around the work of each iteration, it still is more agile to make a
      rough guess and update as more knowledge is available during the work
      than to waste much time trying to guess better up front.

      > 3. Accurate estimation skill works as additional motivation for our XP
      > team. Will you play darts if you know you can move target closer to
      > arrow after a throw? :)

      If moving the target would allow me to eventually become a better
      player after I move the target back, then yes I would move the target
      closer at first and gradually move it back to the regulation distance.

      An important difference between darts and software development is that
      in software development that target always moves, so fixating too much
      on where the target is today is wasteful. Pick the highest priority
      part of the target, try to hit that part in two weeks (knowing even it
      is moving a little), and have everyone learn from that iteration to do
      better next iteration, and repeat. As long as you continue to deliver
      value, learn, and get better, there is no need to let false precision
      get in the way.

      Steve

      >
      > Sergei Andrzeevski.
      >
      > --- In extremeprogramming@yahoogroups.com, "Steven Gordon"
      > <sgordonphd@...> wrote:
      > >
      > > Sergei,
      > >
      > > In other words, you are tracking only the estimated remaining time on
      > > tasks, as is consistent with normal Scrum and XP practice.
      > >
      > > You are not tracking actual effort expended, which I believe was the
      > > essence of the original question. Not explicitly tracking effort
      > > expended is also consistent with normal Scrum and XP practice.
      > >
      > > I hope you were not implying to your client that your billable hours
      > > for day N was the difference between estimated time left on day N and
      > > the estimated time left on day N-1, unless your contract explicitly
      > > stated that what they were paying for was estimated hours of progress
      > > rather than actual hours worked.
      > >
      > > Steve
    Your message has been successfully submitted and would be delivered to recipients shortly.