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

Re: [scrumdevelopment] Critical Chain estimating

Expand Messages
  • Mike Cohn
    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
    Message 1 of 44 , Jul 4, 2005
    • 0 Attachment
      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.

      Mike Cohn
      Author of User Stories Applied for Agile Software Development
      www.mountaingoatsoftware.com


      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
      > technique.
      >
      > 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: scrumdevelopment@yahoogroups.com on behalf of Kevin Rutherford
      > Sent: Mon 7/4/2005 11:19 AM
      > To: scrumdevelopment@yahoogroups.com; tocsoftware@yahoogroups.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 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.
      >
      > Cheers,
      > Kevin
      >
      > --
      > http://silkandspinach.net
      > http://agilenorth.org.uk
      >
      > _____
      >
      >
      >
      >
      >
      > To Post a message, send it to: scrumdevelopment@...
      > To Unsubscribe, send a blank message to:
      > scrumdevelopment-unsubscribe@...
      > Yahoo! Groups Links
      >
      >
      >
      >
    • Ron Jeffries
      ... Yes. I think I should have gone above them all, to the CIO. That would have brought the situation to a head, one way or another. ... That s interesting ...
      Message 44 of 44 , Jul 7, 2005
      • 0 Attachment
        On Wednesday, July 6, 2005, at 5:03:19 PM, Simon Baker wrote:

        > The situation you describe is indeed similar. I was both the coach
        > 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.

        Yes. I think I should have gone above them all, to the CIO. That
        would have brought the situation to a head, one way or another.

        > As an independent coach, the biggest challenges i encounter usually
        > relate to product owners.

        That's interesting ... how about a new thread on that?

        Ron Jeffries
        www.XProgramming.com
        It is not because things are difficult that we do not dare,
        it is because we do not dare that they are difficult. --Seneca
      Your message has been successfully submitted and would be delivered to recipients shortly.