2003RE: [scrumdevelopment] What's wrong with tracking estimates vs. actuals?
- Oct 12, 2003I have worked on many projects in the past where the elimination of labor was considered a significant benefit, if not the greatest benefit of the resulting process and/or product.
Why would the elimination of unnecessary management labor not be a benefit to a client? Maybe, the case needs to be made further up the food chain?
From: Ken Schwaber [mailto:ken.schwaber@...]
Sent: Sun 10/12/2003 4:03 AM
Subject: RE: [scrumdevelopment] What's wrong with tracking estimates vs. actuals?
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
From: Mike Cohn [mailto:mike@...]
Sent: Sunday, October 05, 2003 9:57 AM
Subject: RE: [scrumdevelopment] What's wrong with tracking estimates vs.
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.
> -----Original Message-----To Post a message, send it to: scrumdevelopment@...
> From: Daniel Gackle [mailto:gackle@...]
> Sent: Sunday, October 05, 2003 12:35 AM
> To: firstname.lastname@example.org
> Subject: [scrumdevelopment] What's wrong with tracking estimates vs.
> At my company, some managers believe in tracking estimates vs. actuals.
> like what my team is doing with Scrum, but they'd like it better if we
> them a spreadsheet every month matching the estimate for each task with
> 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
> 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
> 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
> model is very tightly defined.
> To Post a message, send it to: scrumdevelopment@...
> To Unsubscribe, send a blank message to: scrumdevelopment-
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
To Unsubscribe, send a blank message to:
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Yahoo! Groups Sponsor
Click Here! <http://rd.yahoo.com/M=244522.3707890.4968055.1261774/D=egroupweb/S=1707209021:HM/A=1595054/R=0/SIG=124ukap9t/*http://ashnin.com/clk/muryutaitakenattogyo?YH=3707890&yhad=1595054>
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 the Yahoo! Terms of Service <http://docs.yahoo.com/info/terms/> .
- << Previous post in topic Next post in topic >>