Turn your guesstimates into estimates
Our process of scoping work, and estimating the time it will take, is fundamentally broken.
Our process of scoping work, and estimating the time it will take, is fundamentally broken.
For as long as I’ve been working on software products, the process below or some variation of it has been the status quo.
You decide on a feature you want to build
You scope the work and break it into tasks
Developers estimate the tasks (either using time or some relative complexity measure) and the team starts the work
During the work, the team discovers things they didn’t previously know, which typically throws off the estimates
This results in scope creep and late deliveries
Some teams are better than others at estimating. Sometimes those teams are more experienced. Sometimes teams regularly estimate work that is similar to work they’ve done before. Or, they grossly overestimate all work on purpose.
In order to estimate better, you must remove any unknowns. But that’s impossible. Unless you’re doing the same work twice, it’s impossible to know all the obstacles that you’ll encounter. The only way to truly know how long something will take is to do it.
What if there was another way to think about scope? What if there was a more sane way to get what you want without ending up spending more time than it’s worth?
Appetite
Weekend is the time I prefer to spend with family, reflecting, thinking, and reading. Unfortunately, my life isn’t devoid of chores. For the last few weeks, I’ve been delaying cleaning our back yard. The procrastination is a natural response to my previous experiences. I typically plan on starting the chore early, hoping to finish by lunch time, and then envision myself enjoying the rest of the weekend. What usually happens, though, is quite different. I end up spending the majority of Saturday and part of Sunday doing the chore.
I love a clean back yard, but the tradeoff of wasting my weekend cleaning it is too much to bear.
What if I invert the process? Instead of first planning the yard work, I would ask myself, “How many hours am I willing to invest in having a clean yard?”
Surely, having a clean yard is a joy, but it’s relative to other things that are delightful as well.
This is what Ryan Singer labels as appetite in his new book Shape Up: “What is my appetite for a clean patio? How much time am I willing to invest?”
For me, it’s about 2–3 hours. With that appetite in hand, I’m able to make tradeoffs before I get started and during the cleaning. Surely I can’t do a meticulous job given that timeframe, but what can I do to still feel like I achieved a satisfactory outcome?
Now imagine this concept applied to product development. Instead of starting with scoping the work, you first ask, “What is my time appetite for solving this problem?” With that time constraint in hand, you have to get creative in designing the solution. These constraints also help you make tradeoffs during the implementation.
The notion of starting with appetite is ingenious. It inverses the scope estimate function and creates time constraints.
Constraints drive creativity and tradeoffs. Without them, there is rarely an end in sight.
This concept is discussed in depth in Ryan’s new book, Shape Up, where he describes in detail how Basecamp develops products.
Ryan is also doing a 2 day intense workshop with Bob Moesta in Detroit on Aug 28th and 29th. Day 1 you’ll learn the Job-to-be-done theory (what to build) and Day 2 you’ll learn the Shape Up method (how to build it).