RE: [scrumdevelopment] Re: Critical Chain estimating
- Alistair wrote:> ... One of the core elements of the Critical Chain as written is micro-detailing of tasks and micro-analyzing inter-task dependencies. That is definitely against Scrum's way of working.I think you've misunderstood Critical Chain just a little Alistair. Goldratt specifically says not to break tasks down into micro-detail. He recommends keeping them at a high level.Three things ---
From: firstname.lastname@example.org [mailto:email@example.com] On Behalf Of aacockburn
Sent: 04 July 2005 22:33
Subject: [scrumdevelopment] Re: Critical Chain estimating
First, I agree with Steven. Kevin is using the Buffer Management
practice extractd from Critical Chain. One of the core elements of
the Critical Chain as written is micro-detailing of tasks and micro-
analyzing inter-task dependencies. That is definitely against Scrum's
way of working.
So what Kevin demonstrated is interesting, that the Buffer Management
idea from Critical Chain can be applied under a completely separate
set of rules, i.e., skip the baton-handoff task dependency stuff, and
just watch the buffer.
Second, as Laurent questioned, the 50% probability mark isn't the 50%
time mark. I'm curious as to whether it makes any difference which
you use, but Kevin used the 50% time mark (if I got that correctly
from his posting).
For those who haven't read Critical Chain, you halve all the
estimates per task, and take all those second halves of each estimate
and keep them in a big pool, called the buffer. According to
Goldratt's theory, you should probably eat about 1/2 way into that
buffer by the end of the period.
Therefore, you watch the buffer and watch the rate at which you eat
VERY IMPORTANT POINT THAT MANY MANAGERS MISS: You are indeed supposed
to eat into that buffer! If you do not eat into that buffer, then
there is something else wrong somewhere and you are supposed to go
and find it! DO NOT MISS THIS POINT.
It is indeed a hazard (and in my project interviews I found it,
exactly on cue) that the manager drives people to not eat into that
buffer, by forcing overtime work onto them --- and then measuring
work time in weeks (not even days), instead of hours. ... and showing
crowing about how much work time they saved.
This gets me to my third point, and the one I really wanted to post
about ... the potential for abuse of this technique. In this forum,
and with Kevin's experience, I think there is a really good
opportunity to experiment with it.
So, Kevin, here's the question --- did you measure time in worked
hours or worked days/weeks? Did anyone work overtime?
And here's the reason for the question.
If nobody is working overtime (or you measure in hours so that
overtime work shows up properly), and you indeed found that you
didn't eat into all of the buffer, then indeed you have found
something very interesting and I think you should examine it more
closely and write up a short paper on it.
If they are working overtime and you didn't measure in hours, then
please either stop the overtime or do measure in hours and say what
the result is then.
I see the estimation/buffer management aspect of Critical Chain as
one that is incredibly easy to misuse, to the detriment of the team.
The team suckers up for honest estimates and cuts them in half, then
are held to those estimates by management. A few projects later, the
team, being not complete idiots, doubles all their estimates because
they are tired of getting beaten up and working overtime. i.e., the
technique backfires on itsel.
You didn't report on anything that sounded that way, Kevin, which is
why I find your post so interesting, and am requesting more
Both from a morale standpoint, and the absence of micro-analyzing the
tasks (per Scrum), this was an interesting experiment with an
interesting result. I look forward to your replies,
--- In firstname.lastname@example.org, Mike Cohn <mike@m...> wrote:
> I don't think it's antithetical to Scrum. Goldratt's "The Goal" is
> listed in the bibliography to the Schwaber/Beedle book. I suspect
> for a reason.
> Mike Cohn
> Author of User Stories Applied for Agile Software Development
> On 7/4/05 1:49 PM, "Steven Gordon" <sagordon@a...> wrote:
> > I believe what you are talking about is "Buffer Management",
which is just one
> > aspect of Critical Chain. I am not sure whether it is unique to
> > Chain, but, as you have shown, it is quite valuable as an
> > technique.
> > The most characteristic aspect of Critical Chain, using task
> > plan in detail in what order resources should be applied to which
> > order to complete the project as early as possible with the given
> > is antithetical to Scrum, at least according to my understanding
> > -----Original Message-----
> > From: email@example.com on behalf of Kevin
> > Sent: Mon 7/4/2005 11:19 AM
> > To: firstname.lastname@example.org; email@example.com
> > Cc:
> > Subject: [scrumdevelopment] Critical Chain estimating
> > Hi all,
> > I know it's been covered a number of times before, but I just
wanted to report
> > on a real-life experience of Critical Chain estimating. On this
> > project, just over a month ago, I decided to try an experiment.
> > involves taking user stories and breaking them down into small
> > tasks which, being small, should be relatively easy to estimate.
> > after iteration we were squeezed at the finish post because some
> > taken way too long. I had no idea what the cause might be, but in
my mind I
> > coupled it with the team's overall apparent lack of urgency.
> > drifted along.
> > So just before the next iteration's planning meeting we had a
team workshop. I
> > explained the critical chain view of estimates
> > we decided to give it a go. The team recognised that historically
all of its
> > task estimates had been conservative. Fear of being late had made
> > estimates that were universally over at the 90-100% end of the
> > possibilities for each task. That is, each estimate created a 90-
> > of "being right", of finishing within the estimated time. So we
> > each iteration with 15-20 small tasks, each of which had only a
> > of being late. And each time, one or two were indeed late. No-one
> > and yet those few late tasks ate up the iteration's slack. Every
> > So we removed the pressure on any individual task to be brought
in "on time",
> > and we switched to estimating every task at the 50% point. That
is, we did our
> > usual conservative estimates and then halved them! The results
> > and have been repeated now over three iterations:
> > Most tasks are now finished by the 50% point (partly because the
> > treat the estimate as a timebox - "I'll do what I can in that
amount of time,
> > and then see where we are.") And those that go over just eat into
> > buffer a little. In fact, we're now getting a whole load more
tasks done in
> > the same time. Critical chain estimating has eliminated the
> > Parkinson's Law and simultaneously created a sense of urgency.
> > I'd love to know whether this works or has worked for other
> > Cheers,
> > Kevin
> > --
> > http://silkandspinach.net
> > http://agilenorth.org.uk
> > _____
> > To Post a message, send it to: scrumdevelopment@e...
> > To Unsubscribe, send a blank message to:
> > scrumdevelopment-unsubscribe@e...
> > Yahoo! Groups Links
To Post a message, send it to: scrumdevelopment@...
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...
- On Wednesday, July 6, 2005, at 5:03:19 PM, Simon Baker wrote:
> The situation you describe is indeed similar. I was both the coachYes. I think I should have gone above them all, to the CIO. That
> and acting scrummaster. My difficulty was, i couldn't escalate to
> management because, sadly, they really didn't want to know. They had
> bigger issues deciding on strategies and company direction. It was a
> huge time of flux. As i intimated, in the situation a decision had
> to be made given the bigger picture, and unfortunately i was the
> only one inline to make it. Ultimately, scrum did fail in this
> environment because of the politics.
would have brought the situation to a head, one way or another.
> As an independent coach, the biggest challenges i encounter usuallyThat's interesting ... how about a new thread on that?
> relate to product owners.
It is not because things are difficult that we do not dare,
it is because we do not dare that they are difficult. --Seneca