I've never had to really negotiate on every thing that gets added to the
backlog. In the past I've sold clients on the approach and the techniques. I
show them why a project will take as long as I think (normally faster or the
same as most companies would bid but sometimes undercut by companies who
lie/mis-estimate) then tell them to cut us off when we've done enough
functionality that they're happy. On something we think is 7 sprints that
could be in 5-7 sprints; or longer if they keep coming up with good ideas.

-----Original Message-----
From: Steven Gordon [mailto:sagordon@...]
Sent: Tuesday, November 18, 2003 9:31 AM
To: scrumdevelopment@yahoogroups.com
Subject: RE: [scrumdevelopment] BLOG on "How do Scrum and Critical Chain
compare? "

Mike,

I have not read your blog yet - I was just noting what I always thought was
a contradiction between the approaches.

I am under the impression that the modeling the distribution of tasks using
an average estimate and worst case estimate predates Critical Chain, and
therefore consider the distinguishing feature of Critical Chain to be the
modeling of how these distributions of task lengths (along with resource
constraints) causes dynamic changes in which path turns out to be the
functionally critical path. My impression could be wrong.

Your method certainly seems sound. I recall once seeing a statistical
justification of this type of estimation approach assuming a task length
distribution that looked normal between 0 and the mean, and skewed after the
mean.

I would add that my experience is that the tasks upon which the most other
tasks are dependent tend to be the most central tasks in the system. These
are usually of the tasks with the greatest business value, and are the ones
that allow you to most quickly deliver a skeletal system that works end to
end. So, it usually makes sense to work on these tasks first, both for
business value to your customer and to help your customer evolve their
understanding of what they really need as soon as possible.

Of course, I do not believe you can really project how the backlog will have
changed 6-7 sprints ahead; afterall, learning and adapting is a big part of
the reason you are using Scrum. So, I assume you are forced to "negotiate"
the impact of every task that gets added to the backlog during the course of
the project.

Steven Gordon



-----Original Message-----
From: Mike Cohn [mailto:mike@...]
Sent: Tue 11/18/2003 8:39 AM
To: scrumdevelopment@yahoogroups.com
Cc:
Subject: RE: [scrumdevelopment] BLOG on "How do Scrum and Critical
Chain compare? "

Steve-

You're right that this is not a full typical critical chain application but
I've never found it necessary to look into ways to consider adding feeding
buffers within a sprint. (On one large project we did use feeding buffers
when there were many scrum teams involved.)



One thing I will sometimes do differently from "by the book" Scrum is, as
you point out, look at task (story) dependencies. However, I don't do that
for critical chain planning. Rather, I do it to avoid achieving a local
optimization to the work of a sprint. Suppose a sprint includes 26 things to
do, labeled a through z. They can be done in any order except a, b, and c
must be done in order. As a ScrumMaster I train the team to look for
sequences like that and make sure they start those types of tasks as early
as possible in a sprint. There are normally very few of these in a sprint so
this is a pretty small change and it's really just how we think about the
work of a sprint. However, it helps avoid a situation where the sequential
tasks a, b, c are all left for the last day and even though there are three
developers and three days left of work we just can't do the work in one
chronological day.



This same problem can happen with any process that doesn't take a step back
and look at sequence-Scrum, XP, etc. Good developers just seem to know to
think about it and 95% of the time think about subconsciously without any
problem (e.g., we all know to finish the code on Thursday so the integration
test and some exploratory testing can happen on Friday).



Here's why I don't worry about task dependencies to determine my project
buffer. I have never convinced myself 100% that the math and logic here work
out perfectly but I think they do and in practice it works better than I
could hope for. If you can help convince me it's truly right I'll owe you
one! I assume that for a sprint everyone will be 100% busy on the sprint.
This doesn't mean ideal time = calendar time, just that we're working on
nothing but this sprint. I assume (and make sure) that tasks are small
enough and dependencies infrequent enough that some optimal solution can be
worked out such that the work the team selects for the sprint can be done in
the sprint. That is, if I wanted to I could sequence the tasks so that they
could all be completed. I assume that the team will work out that optimal
solution as the sprint progresses (that is they self-organize around that
goal). I assume that I do not need to buffer the completion dates of any
tasks in the sprint but what I need to buffer is either that sprint or, more
likely a series of sprints (a release). Given all that, I do the math
recommended by Reinertsen or Larry Leach to come up with a buffered
schedule. Here's an example. The columns are estimates in days of six items
on the product backlog. The first column is the 90% confident estimate, the
next is the 50% estimate, the final is the squared difference of the two.



90% 50% (90%-50%)^2

7 2 25

5 2 9

2 2 0

8 5 9

4 2 4

5 3 4



Sum the squared differences and get 51. Take the square root of that and get
about 7. The seven is the project buffer. Add that to the sum of the 50%
estimates (16) and get 23. So, to buffer this project to a 90% level of
confidence you should plan on 23 days, not the 16 that is the sum of the 50%
estimates or the 31 that is the sum of the 90% estimates. Naturally this
doesn't add a lot of value when there are only this many tasks. Suppose
instead though that for a larger project this process estimates 135 days of
work-that would translate into 6.75 sprints (I use 20 working days per
sprint) so I'd tell the product owner to plan on 7 sprints. If I didn't do
this process and we needed to give the product owner (typically someone
paying for outsourced development in these cases) an estimate we could have
given them (a) the sum of the 90% estimates but then we'd never get the work
and the estimate would be too high anyway (rarely does *everything* take the
longest amount of time); (b) the sum of the 50% tasks in which case we'd get
the job but we'd never finish on time (completion times are not normally
distributed and rarely would *everything* finish near it's minimum time) or
do (c) something else which for projects of this size I find typically
underestimate the work by 1-2 sprints and then the team has a huge challenge
of sticking to their quality discipline as time runs out on them.



So, it's Scrum with just a dash of TOC into the planning phase.



--Mike













-----Original Message-----
From: Steven Gordon [mailto:sagordon@...]
Sent: Monday, November 17, 2003 2:37 PM
To: scrumdevelopment@yahoogroups.com
Subject: RE: [scrumdevelopment] BLOG on "How do Scrum and Critical Chain
compare? "



Mike,



How do you obtain task dependencies? My understanding of a backlog is that
it is a flat list of tasks (or possibly a priority queue). Furthermore, if
you are using XP for your development methodology, it generally works out
that one can implement tasks in any order without much impact on development
time due to task isolation via small specific stories and stand-alone
automated unit tests and acceptance tests.



Lacking critical task dependencies, Critical Chain does not seem to offer
much over just summing up estimates.

Steven A. Gordon, Ph.D.
Manager, Software Factory
Arizona State University
PO Box 875506
Tempe, AZ 85287-9509
http://sf.asu.edu <http://sf.asu.edu/>
(480)-727-6271



-----Original Message-----
From: Mike Cohn [mailto:mike@...]
Sent: Monday, November 17, 2003 2:24 PM
To: scrumdevelopment@yahoogroups.com
Subject: RE: [scrumdevelopment] BLOG on "How do Scrum and Critical Chain
compare? "

In Clarke's message on Hal's blog he notes that he doesn't think anyone is
combining Scrum together with Critical Chain.

I've been combining the two since 1999 and agree that they are quite
synergistic. I use Critical Chain techniques to provide an upfront forecast
of how long a project will take. On our projects we collect two estimates
for each item on the backlog (our backlog is generally in the form of XP
stories). The first estimate is the "50% estimate" that represents how long
something should take to code. If the programmer coded it 100 times this
would be the time she'd take for the median. The second estimate is a 90%
estimate--this is the "worst case" but not the *worst* in that no buses run
anyone over, the source repository doesn't crash two seconds before backup
and the building doesn't burn down. It's a realistic worst case. From these
estimates we extrapolate a "project buffer". We then sum up the 50%
estimates and add to them the project buffer to come up with the number of
sprints we think something will take. It's been amazingly effective looking
as far out as 9 months. (I haven't tried anything longer and don't really
plan to.)

So, we use CC to help give our Product Owner a more informed guess at the
beginning and then once a sprint starts it's pretty much by-the-book Scrum.

--Mike



-----Original Message-----
From: Deb [mailto:deborah@...]
Sent: Monday, November 17, 2003 8:37 AM
To: scrumdevelopment@yahoogroups.com
Subject: [scrumdevelopment] BLOG on "How do Scrum and Critical Chain
compare? "

Thought some of you might be interested in this entry on Hal
Macomber's "Reforming Project Management" site:

"How Do Scrum and CCPM Compare?
This posting came from Clarke Ching, Scotland, writing in the TOC
Experts Yahoo! Group on November 10...."

see:
http://weblog.halmacomber.com/2003_11_09_archive.html#1068822436734154
87




To Post a message, send it to: scrumdevelopment@eGroups.com
To Unsubscribe, send a blank message to:
scrumdevelopment-unsubscribe@eGroups.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/



To Post a message, send it to: scrumdevelopment@eGroups.com
To Unsubscribe, send a blank message to:
scrumdevelopment-unsubscribe@eGroups.com

Your use of Yahoo! Groups is subject to the Yahoo!
<http://docs.yahoo.com/info/terms/> Terms of Service.






Yahoo! Groups Sponsor



ADVERTISEMENT

<http://rd.yahoo.com/SIG=12c1f53uv/M=243273.4156324.5364586.1261774/D=egroup
web/S=1707209021:HM/EXP=1069191460/A=1750744/R=0/*http:/servedby.advertising
.com/click/site=552006/bnum=1069105060342543> Click to learn more...



<http://us.adserver.yahoo.com/l?M=243273.4156324.5364586.1261774/D=egroupmai
l/S=:HM/A=1750744/rand=806912783>


To Post a message, send it to: scrumdevelopment@eGroups.com
To Unsubscribe, send a blank message to:
scrumdevelopment-unsubscribe@eGroups.com

Your use of Yahoo! Groups is subject to the Yahoo!
<http://docs.yahoo.com/info/terms/> Terms of Service.






To Post a message, send it to: scrumdevelopment@eGroups.com
To Unsubscribe, send a blank message to:
scrumdevelopment-unsubscribe@eGroups.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/