cloud-download external-link twitter envelope linkedin chevron-circle-right external-link-square paper-plane envelope-o network

Agile Fluency Project

« Back to the Blog

Estimation and Fluency

Estimation and Fluency

Martin Fowler recently asked me via email if I thought there might be a relationship between Agile Fluency Model and how teams approach estimation. This is my response:

I definitely see a relationship between fluency and estimation. I can’t say it’s clear cut or that I have real data on it, but this is my gut feel:

  1. Focusing teams tend to fall into two camps: either “estimation is bad Agile” or “we’re terrible at estimating.” These statements are the same boy dressed by different parents. Focusing teams can’t provide reliable estimates because their iterations are unpredictable, typically with stories drifting into later iterations (making velocity meaningless), and they have a lot of technical debt (so even if they took a rigorous approach to “done done” iterations, there would be wide variance in velocity from iteration to iteration, so their predictions’ error bars would be too wide to be useful).
  2. Delivering teams tend to take a “we serve our customer” attitude. They’re very good at delivering what the customer asks for (if not necessarily what he wants). Their velocity is predictable, so they can make quite accurate predictions about how long it will take to get their current backlog done. Variance primarily comes from changes to the backlog and difficulty discussing needs with customers (leading to changes down the road), but those are manageable with error bars. Some Delivering teams retain the “estimation is bad Agile” philosophy, but any Delivering team with a reasonably stable backlog should be capable of making useful predictions.
  3. Optimizing teams are more concerned with meeting business needs than delivering a particular backlog. Although they can make predictions about when work will be done, especially if they’ve had a lot of practice at it during their Delivering phase, they’re more likely to focus on releasing the next thing as soon as possible by reducing scope and collaboratively creating clever shortcuts. (E.g., “I know you said you wanted a subscriber database, but we think we can meet our first goal faster if we just make REST calls to our credit card processor as needed. That has ramifications x, y, z; what do you think?”). They may make predictions to share with stakeholders, but those stakeholders are higher-level and more willing to accept “we’re working on business goal X” rather wanting than a detailed timeline.

I’m not sure how this would play out with Strengthening teams. I imagine it would be the same as Optimizing, but with a different emphasis.

Categories