Chris Chapman “interviews” me about #NoEstimates :)

(first published on June 15th 2013, migrated from my deprecated Wordpress site)

1. You’ve mentioned on Twitter that in your opinion, #NoEstimates = Agile + Real Options. For the curious newbie, what does this mean?

The approach I talk about is very much underpinned in Agile principles. In fact it’s what I believe Agile was intended to be at its core (although I’ve had some disagreement from the likes of Ron Jeffries and Alistair Cockburn on this point).

To summarise #NoEstimates from my point of view:

Constraints breed creativity

• Use real constraints to drive decisions, e.g. “this is how much we want to spend” or “we need something by June in time for Wimbledon”
• Arbitrary constraints (such as deadlines based on zero to low knowledge “estimates”) cause dysfunctional and ineffective behaviour
• Create mini-constraints (i.e. drip funded iterations) to promote a creative approach to what we are going to build to address the problem at hand

Build awesome teams

• Create fixed, capable teams so we know how much our time costs
• Scale up team capacity if enough positive value has emerged (by adding teams, not people to teams)
• Empower our teams to be bold and free in making solution choices, with focus on “building the right thing” and “delighting customers and stakeholders”

Keep our options open

• Cover multiple, potentially valuable options with small experiments rather than committing to one option per team for long periods
• Reassess options frequently to ensure initiative is still valuable (ignore sunken cost) and is more valuable than other options for which we could divert our team capacity
• Anything we haven’t yet built (e.g. our product backlog) is only an option — we shouldn’t assume we’ll build it and shouldn’t worry how “big” it is unless we actually want to do it now, or very soon

Put the “iterate” back into “iterations”!

• Truly iterate over the solution (holistic determination of where to take the product next) rather than just incrementing pre-determined backlog items
• Deliver early and frequently, with very small (even daily) feedback loops — this makes us predictable

Create collaborative working agreements

• Create flexible, collaborative working agreements with our customers which allow us to truly embrace change and deliver to customers’ present needs rather than their needs when we started
• Allow customer to cut the cord early if they are happy with what they have (or not happy with progress)
• Start from a position of trust rather than paranoia (which traditional contracts are based on)

Favour empiricism over guesswork

• Keep work items small and simple, and limit WIP to create a predictable system
• Slice features into simple, unambiguous stories using a heuristic rather than estimation rituals
• Price work per feature if appropriate, using empirical average cost of features to guide price rather than a deterministic estimate of individual features
• Use cycle time and throughput to make near-term prioritisation calls, not to determine release dates (there are no big releases in this approach anyway)

Shift focus away from estimation

• Create a culture of honesty by removing negative estimation culture (i.e. get rid of story points and the notion of estimates as promises or deadlines)
• Make work and project success about creative delivery of value (i.e. “what shall we do next?”) rather than “on time, on budget”, schedules, deadlines, etc.

2. Describe what you mean by a “slicing heuristic”

Essentially it’s a policy for how we break up our work. For example, “A user story must have only one acceptance test”. Rather than breaking features into stories and then estimating the stories, we can use the heuristic, measure our cycle times and then inspect and adapt the heuristic if required.

I’ve found the “1 acceptance test” heuristic to be consistently effective over different domains for creating an average story cycle time of 3 days or less.

3. How does your approach differ from that of Woody Zuill? Or, are there more similarities than differences?

I can’t speak for Woody but I feel that Woody’s approach is simpler than mine. He believes that if you follow the Agile Manifesto properly then the need for estimates dissipates.

I agree with him in principle but see systemic issues, particularly in analytic/mechanistic organisations, that I feel need to be addressed in order for #NoEstimates to strike a chord with more traditional managers and executives. At its core though, #NoEstimates is about exploring various approaches to delivering software without the use of estimates, and the commonality between our approaches seems to be the continuous delivery of small increments of high quality, valuable software.

4. Do you think any team can work without estimates? What’s the minimum “barrier to entry” ?

Any team (with the right coaching and knowledge) can embrace the slicing of work, limiting of WIP and measurement of throughput/cycle times, even if they are being asked to estimate with story points or time. #NoEstimates is not about refusing to estimate.

If you’re talking more about the overall approach from the portfolio level down, I’d say there is a minimum barrier to entry:

• Fixed team (cost)
• Allowance of variable (emerging) requirements/scope
• Small batches of stories/features
• Slicing heuristic to create roughly consistent actual/measured work unit size (“a few days”)
• Incremental & iterative delivery capability of shippable code
• Mini constraints such as weekly demo/review with customer (small, early and frequent releases)

This looks very much like any typical “Agile” team to me

5. What advantages does working without estimates provide your team over, say, a team that is using longer cadences, eg. Scrum?

My approach is entirely compatible with Scrum. In some ways I think that it’s what Scrum was intended to be (or at least, in my opinion, should be).

If a Scrum team is working in 2-week Sprints, truly iterating, delivering working software every Sprint, inspecting and adapting the product etc. then this looks very much like the approach I am advocating.

6. A common criticism of #NoEstimates is that when you slice off functionality to deliver (the “heuristic” approach) you are, in effect, estimating. Is this a correct interpretation? Why/why not?

Well arguably if you create a heuristic for creating “small” work then I can understand why it is interpreted that way. However, I don’t believe it is estimating. The point is to create simple and unambiguous story cards. The “smallness” is a by-product of doing this.

If we don’t get the smallness we’re looking for (after measuring the result) then we inspect and adapt the heuristic. At no point do we actually look at a card and say “I estimate that this is small”. We trust in the heuristic.

7. You’ve been a really vocal advocate for working without estimates, standing up to some tough questions from established agile practitioners. Why do you think this topic has so many people so roused?

Because the way software projects are typically governed is largely driven by estimates, so it touches almost everyone in the industry. It’s an established way of doing things so it is deemed controversial.

8. What would your advice be to a team considering working without estimates? What should their first steps be?

Don’t simply stop estimating. Try and get better at creating simple, unambiguous slices of functionality. Measure your throughput. Compare story count data with your story point data. Discover for yourselves if a #NoEstimates approach is right for you and a good fit for your organisational culture.

Thanks for reading! If you are looking for help with your software or product delivery, I provide agile coaching, public training (both theory and practical) up to executive management level, and more. As well as public events, I can also run training internally in your organisation for a massively reduced cost, so please ✍ get in touch.