Chris Chapman “interviews” me about #NoEstimates :)

Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Email this to someone
interview1.       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.

Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Email this to someone

5 thoughts on “Chris Chapman “interviews” me about #NoEstimates :)

  1. It is my understanding Agile never intended card sizing to relate to time. It relates to difficulty. That being said, I will add that time estimates for software are always guesses. As an industry if we can get to the point where we can implement continuous deployment then time estimates have even less value.

    Deploying a Minimal Viable Product and adding to it every day is the fastest way to generate revenue. The longer the product exists, the more valuable it is. As it increases in value to the customer the more that can be charged for it or the larger number of customers that can use it.

    Therefore, the questions to ask are:
    1)Which epic adds the most value? (Either in expanded customer base or raising the price of the product)
    2)How do we build usable features everyday toward that epic each day?

    Not, “How long will this take?”

    #Agile, #Lean, #No(Time)Estimates

Leave a Reply

Your email address will not be published. Required fields are marked *