This is a writeup from a series of talks and workshops I’ve given on this topic. It’s been really helpful to think through what techniques I’ve used, what situations each work best in, and what less-than-obvious challenges make this such a hard topic to give simple answers on.
This post is part 1 of … many! I’ve thought a lot about this topic. So far we have:
- Part 2 and part 3 explore using data instead of asking people how long they think things will take
- Part 4 looks at how wide, uncertain ranges can still be useful, and part 5 has a guide to practice that skill
- Finally, part 6 takes a look at some of the cognitive biases and difficult personal dynamics that make estimation such a surprisingly difficult subject to talk about.
The slides are all online at https://speakerdeck.com/neilvass/minimum-viable-estimation-whats-the-least-you-can-get-away-with, along with a synopsis:
Knowing how big a job something is before choosing to start it is definitely valuable – it can be used to inform all kinds of decision-making. But agonising over how to work that out and insisting on simple answers to unknowable questions is a waste of time, energy and trust. Let’s talk about how to make things better.
Fans and opponents of #NoEstimates are equally welcome – I think we might all be talking about the same thing…
What’s the least you can get away with?
Any discussion of “what’s the least estimation you can do” has to start here: hashtag-no-estimates-at all. Just don’t do it.
Discussion over? Well, not exactly.
#NoEstimates has caused huge amounts of angry debate online, with people on both “sides” of the debate really sure that their position is the only sensible one. I’m trying to stay out of flame wars and just take a look at what might be useful to think about.
Reading through posts and articles about the topic, I think different people are talking about two distinct things when they discuss the idea. The first meaning is the one put forward by Woody Zuill, who I believe invented the hashtag:
One of Woody’s blog posts on the topic outlined what he means by coding without estimates. He was looking to use his computer to make working with the monthly accounts for his business easier, and hadn’t found a commercial application that worked well.
The smallest, easiest valuable step he could think of was to get all the invoice totals in a column, so he could easily check he hadn’t missed anything. This turned out to not need any code at all, just a text editor. He went on in small steps, adding functionality to total things up, then more and more bookkeeping features.
At every stage, he added one more tiny feature – he didn’t know how “tiny” any of them were, but they all seemed small, and if something turned out to be a big job he was prepared to back off and think of something smaller to try instead. And, at every stage, he had something complete and useful – if he’d decided to stop working on the application after the first step, it would carry on being usable and a timesaver compared to his old process.
Some important things about this style of #NoEstimates:
- He really wasn’t thinking about how long anything would take, beyond what seemed “small enough”.
- He had lots of freedom to choose what to work on next, and to change his mind if he realised he’d picked wrongly.
- After every small step, he had a more-useful application than before, and had the option to stop working on it but keep getting value from the work done so far.
My experience
Could I see this working? Absolutely – and I can think of several examples where I have worked something like this. On one team, we were adding functionality to software used by research scientists, and were sat working in the same room as the most frequent users of the application. We could hear them mutter in frustration at parts of the app that didn’t work well for them, and wheel over our chairs to ask about it. And they were on hand to talk through options for changing things when we wondered what a simpler next step could be.
We didn’t say we were “not doing estimates”; the topic just didn’t come up much. Everyone understood that we had limited time and budget to do the many great things we’d ideally like to do, and trusted that we were all working together to make the best use of that time together. We had plenty of other challenges to think about, but it’s interesting that estimation really wasn’t one of them.
Thinking back over the time on this team, we had done a few different things to help with planning and deciding, and they’d all worked fairly well for us. At one early phase we were using story points, a technique I’ve really struggled to make useful in other contexts, but here they’d worked just fine for discussing how big a job we were taking on with some items and how surprisingly complex some ideas were. We moved over time to “what’s the simplest we can make this and get something useful into production”.
My conclusion from this experience: In a high-trust environment, almost anything can work. Most of estimation and planning techniques have some value and several limitations, and if you can talk honestly about what you’re trying to achieve with them you’ll probably get them to work for you.
The other side of this conclusion is: In a low-trust environment, almost nothing will work. If your team and stakeholders are all second-guessing each other, trying to get guarantees and certainty, there is no framework or tool that’ll fix that. Work on the trust issue.
In a high-trust environment, almost anything can work. In a low-trust environment, almost nothing will.
Assuming you have that trust in place (easy, right?), what makes this Woody Zuill version of no estimates work? I think those 3 bullet points are all important.
- Can you work in small steps (as in, very small)?
- Can your team and stakeholders together choose different steps easily?
- Do the steps you take give you lots of points where you can say “that’s enough now”, and leave the users with all the improvements you’ve made so far?
I’ve definitely seen teams try #NoEstimates without putting these in place, and get into trouble. On one rewrite of a site, work got started without much discussion of how long it would take. Several months in, and with multiple cans of worms discovered, it was becoming clear that this was a huge task. And if they decided to stop, any time before the whole, unknown end date was reached, they’d have nothing usable to show for it. That’s a fairly extreme example – but you might have seen various cases where people have tried (or refused to try) not estimating that have some similar qualities.
I’ve found I can’t just say “let’s change to small steps” and start using this approach everywhere – sometimes I’m working a long way from that. It’s useful to talk about what’s possible, and how you might move the way you work in that direction. It’s also useful to have a good selection of other approaches you can use for other situations you might be in. I’ve got various suggestions that will come up later in this series.
Next in this series
I mentioned that I think there’s two distinct meanings people might have when they talk about #NoEstimates. We’ve discussed the first – and you can read lots more about it on Woody Zuill’s blog.
In part 2, we’ll talk about the other meaning: Using data to avoid having to ask people how long they think things will take. Then, part 3 has some practical guidance on getting started with using that kind of data.