Re: [scrumdevelopment] Critical Chain estimating
Re: [scrumdevelopment] Critical Chain estimatingHi Kevin--
It’s good to hear about your success with estimating this way. Your experience is similar to mine. I ask teams to estimate such that they feel they’ll beat the estimate half the time and miss it half the time. The fact that the estimates are 50% individually is considered when we do iteration planning.
I also use critical chain-style buffering when I need to give an estimate of project schedule when there’s still a great deal of project uncertainty. That’s a subject in a new book I’m about done with in fact. See Chapter 16 at www.mountaingoatsoftware.com/agileplanning.
Author of User Stories Applied for Agile Software Development
On 7/4/05 12:19 PM, "Kevin Rutherford" <silk.spinach@...> wrote:
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.
- 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