#noestimates

The problem?

For example, 3 guys wrote a paper in 86 and they said that a good estimate is an estimate that’s within 25% of the original estimate, 75% of the time … so, mostly one quarter wrong .

Yikes, not a very good prospect at all.

The gist of #noestimates to determine how much scope can be delivered by a given date:

Select the most important piece of work you need to do (highest value first)

Break that piece of work down into risk-neutral chunks of work: (…) small enough that failing to deliver it at first attempt will not jeopardize the project [typically ~1 day chunks]

Develop (…) Deliver that work to a production-like environment. Work is only done when it is ready to be used by real customers.

Iterate and refactor : The first implementation can only reflect a first step in understanding what needs to be done.

Be careful to let the system stabilize before it can provide reliable averages to predict the teams’ throughput.

Symptoms of an unstable system are:

If velocity (# of storiesDone in one sprint) falls outside the control limits more than 3 times in a row (“outside limits”)

If there are 5 or more velocity points in a sequence (ascending or descending) (“Run test”)