Re: [scrumdevelopment] Critical Chain estimating
- I don't think it's antithetical to Scrum. Goldratt's "The Goal" is even
listed in the bibliography to the Schwaber/Beedle book. I suspect it's there
for a reason.
Author of User Stories Applied for Agile Software Development
On 7/4/05 1:49 PM, "Steven Gordon" <sagordon@...> 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 Critical
> Chain, but, as you have shown, it is quite valuable as an independent
> The most characteristic aspect of Critical Chain, using task dependencies to
> plan in detail in what order resources should be applied to which tasks in
> order to complete the project as early as possible with the given resources,
> is antithetical to Scrum, at least according to my understanding of both.
> -----Original Message-----
> From: email@example.com on behalf of Kevin Rutherford
> Sent: Mon 7/4/2005 11:19 AM
> To: firstname.lastname@example.org; email@example.com
> 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 particular
> project, just over a month ago, I decided to try an experiment. Our process
> involves taking user stories and breaking them down into small development
> tasks which, being small, should be relatively easy to estimate. But iteration
> after iteration we were squeezed at the finish post because some tasks had
> 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. Things just
> drifted along.
> So just before the next iteration's planning meeting we had a team workshop. I
> explained the critical chain view of estimates
> <http://www.focusedperformance.com/articles/ccrisk2.html#2e_estimates> , and
> 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 us create
> estimates that were universally over at the 90-100% end of the range of
> possibilities for each task. That is, each estimate created a 90-100% chance
> of "being right", of finishing within the estimated time. So we had stacked
> each iteration with 15-20 small tasks, each of which had only a small chance
> of being late. And each time, one or two were indeed late. No-one knew why,
> and yet those few late tasks ate up the iteration's slack. Every time.
> 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 were amazing,
> and have been repeated now over three iterations:
> Most tasks are now finished by the 50% point (partly because the developers
> 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 the project
> 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 effect of
> Parkinson's Law and simultaneously created a sense of urgency.
> I'd love to know whether this works or has worked for other software teams.
> To Post a message, send it to: scrumdevelopment@...
> To Unsubscribe, send a blank message to:
> Yahoo! Groups Links
- 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