Never ask “how long will it take?”
Anyone who has worked on any kind of project at some point are familiar with the question “when will it be finished?” or “how long will it take?”.
In software development, this has become such a central part that numerous different models have been developed to make estimates of how long things will take. The purpose behind these time estimates has, at least historically, often been about someone (the product owner/customer/engineers?) wanting predictability and control.
Anyone who has made estimates or project plans also knows that they are no more than, at best, educated guesses. Someone more cynical might even call them “lies”. No matter how much time and effort you put into estimates, they still tend to be wrong. So wrong that they often cause harm rather than help.
Instead of asking us “what does it cost?” we ask, “what is it worth?”
Woody Zuill, a guru in software development and the man behind Mob Programming, put it like this:
I hear it over and over: Our estimates were not accurate, and we had a lot of trouble because of that. We need to get better at estimating. It is similar in a way to saying “My tooth hurt, so we pulled it out. Now I can’t chew as well as I used to. We need to get better at pulling teeth”.
At Lime we don’t work with time estimates for the same basic reason that Woody doesn’t: we don’t see much value in them. We find that they don’t help us build the right things, to the right quality nor with the right effort. So, what do we do? Instead of asking us “what does it cost?” we ask, “what is it worth?”. The answer to that question is what we call The Appetite.
The concept of The Appetite is taken from a process called Shape Up. We have been working according to Shape Up for three years and I claim that The Appetite is the most difficult thing to both understand, formulate, and get right. But this is how it is supposed to work:
Let’s say I’m going to buy a pair of jeans. The first thing I might do is to start investigating “how much does a pair of jeans cost?”, which is the same approach as working with time estimates; “How long will it take?”. Which I don’t do. Instead, I ask myself “What is a pair of jeans worth to me? What should I use them for? How often should I use them? How important is a pair of jeans to me?” If I were my father, I might have said “I do not care what they look like, but they should do the job when gardening. I can imagine paying €30.”. While I might have said “It is important that they fit well and can be used if I dress casually as well as formally. If they look great and I can use them for a lot for many years, I can probably pay €180.”
So here we have the same product, a pair of jeans, which one person is prepared to spend € on and another €180 on. That’s a difference of factor 6. This is The Appetite. The Appetite is a number but it is also the reasoning that led to this number.
How do we use The Appetite when we build our product, then? Here is an example: we recently redesigned the user’s start page of Lime CRM. The start page is filled with various widgets where the user gets a quick overview of their day. Before we started that project, this was the stated Appetite (here, slightly shortened):
In the near future, we wish for a situation where our project managers can easily insert and place widgets on the home page without having to think about responsiveness. More user-friendly start pages enable brand new customers, who previously declined our offering, to use our product. We also want to replace the legacy technology used, thus removing technical debt. This also enable reusability and standards by using the same components as the rest of the client.
We believe this will enable brand new business opportunities at a value of x over time y and reduce frustration and costs for customers, consultants, and sales reps alike. We are therefore willing to invest 4 engineers for 4 weeks in this project.
Instead of saying “How long will it take to build a new start page (given this specification)?” we said “Invest four people over four weeks and do the best to solve the given problems.”
This also means that we do not work with any form of “Definition of done” 😱. Our “Definition of done” is when the appetite is gone. In the example above: after four weeks.
“But what happens if you’re not ready, then?” someone might ask. “What do you mean by ‘done’?” is my answer. “You have been given four weeks to create a solution. I don’t want to pay more now. It is now up to you to create a solution that can be delivered in four weeks. (There is a rough so called “suggested solution” provided.) As a suggestion, you make a solution that can hopefully be shipped already after two weeks and then you make it better and better and better until the time runs out. That means that we do not know what the scope will be. We will need to make priorities during the project. But it is of the utmost importance that when the time (appetite) runs out, something can be shipped.”
In this model, the scope, not the time nor number of people, is a variable. Therefore, we also do not have any exact feature specifications. (We are entering a project with “breadboards” and rough sketches, but that is another chapter.) For a product manager, this means less control and predictability. Instead, it requires a presence, participation, and the ability to react during the project.
No process is perfect, and I am the first one to argue “people before process”. But if your goal is to “get things out the door” then my tip is simple: stop talking time estimates, specifications and “definitions of done” and start talking Appetite.
