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

2001RE: [scrumdevelopment] What's wrong with tracking estimates vs. actuals?

Expand Messages
  • Ken Schwaber
    Oct 12, 2003
    • 0 Attachment
      In some instances we're going to be stuck with tracking actuals. Mel Pullen
      pointed out that this may be a symptom of displaced management trying to
      figure out how they are adding value, and relying on what they have used in
      the past to add that value. They have always tried to improve predictabity
      in the past, let's try to do it in the future.

      I've always tried to get management to do another job. I've tried to get
      them to see how well or badly a team does, what it can produce Sprint by
      Sprint. Then I ask them to actually do the job of management - figure out
      what to do based on what the team has been able to build. Should release
      dates be changed? Should the project be decommissioned? Should functionality
      be dropped from this release? Should the team's expertise be improved in
      some areas? To me, these are all reasonable areas of management expertise,
      not throwing the problem back on the team by saying, "improve your
      estimates."

      Ken

      -----Original Message-----
      From: Mike Cohn [mailto:mike@...]
      Sent: Sunday, October 05, 2003 9:57 AM
      To: scrumdevelopment@yahoogroups.com
      Subject: RE: [scrumdevelopment] What's wrong with tracking estimates vs.
      actuals?


      I'd say you shouldn't do it because it doesn't add value commensurate with
      its cost. Don't argue with your bosses that it "adds no value" because
      comparing what you originally thought a task would take with what it did
      take can help make you a better estimator.

      But, it can be time-consuming to track actuals, especially for a full team
      where some on the team are probably already decent estimators.

      Because Scrum already has solid mechanisms for monitoring whether all the
      work gets done in a sprint (high team commitment, daily burndown charts,
      daily scrum, and so on), Scrum does not have the same reliance on early and
      accurating estimating that a predictive or waterfall approach does.

      So--the cost to gather actuals is the same in Scrum or waterfall. The
      benefit in Scrum is greatly reduced.

      --Mike



      > -----Original Message-----
      > From: Daniel Gackle [mailto:gackle@...]
      > Sent: Sunday, October 05, 2003 12:35 AM
      > To: scrumdevelopment@yahoogroups.com
      > Subject: [scrumdevelopment] What's wrong with tracking estimates vs.
      > actuals?
      >
      > At my company, some managers believe in tracking estimates vs. actuals.
      > They
      > like what my team is doing with Scrum, but they'd like it better if we
      > gave
      > them a spreadsheet every month matching the estimate for each task with
      > the
      > hours actually spent on that task.
      >
      > I feel bad about this and don't want to do it. It feels contrary to the
      > spirit of self-organizing teams, like someone is looking over our
      > shoulder.
      > Yet I can't fully articulate what's wrong with it.
      >
      > Can anyone help me get clearer on this?
      >
      > - Daniel
      >
      > -----Original Message-----
      > From: "Gamble, Ken" <ken.gamble@...>
      > Subject: New Scrum Article Available
      >
      > No matter how well someone measures past estimates against actuals even a
      > small change in the estimate can have a big effect on the outcome of a
      > chaotic/complex process no matter how good the model is or the resolution
      > of
      > the measurements.
      >
      > What this means for software development is that even though we can use
      > previous estimates as part of a process model for delivering software we
      > have to keep a sharp eye (Scrum management) on the process because it can
      > wonder off course simply because of these small values, even if the
      > process
      > model is very tightly defined.
      >
      >
      >
      > To Post a message, send it to: scrumdevelopment@...
      > To Unsubscribe, send a blank message to: scrumdevelopment-
      > unsubscribe@...
      >
      > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/




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

      Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
    • Show all 20 messages in this topic