#noestimates: Thought experiment or solution?
A friend of mine (Yemi Awoyemi, Technical Development Manager and generally clever fellow) mentioned I should write a post about the #noestimates debate going on on Twitter. I responded with a very well informed... "What #noestimates thing?"
Now, I've written about estimation before, like 3 Point (Stocastic) Estimation & PERT Analysis in MS Project and Project Estimation and the M.E.W.S. So, I did a bit of reading, some of the articles I've found are linked below in the grey box if you are interested.
One thing to start with, the original author was conducting a thought experiment. Like many of us working to deliver things, be they soft-ware or soft-toys, we've all had frustrations with estimates, particularly that they are held to be a firm and cast iron guarantee by people who really should know better. Woody Zuill was asking a question to himself, could we do away with estimates, as from many perspectives they are waste, they take effort and time from the team, time they could be spending building working software and generally they are of limited use when you compare them to the final work done.
It is also worth defining terms. When the #noestimate proponents are talking about no estimates being done, they are not talking about "Yikes, that looks like a big requirement, its going to take weeks" being an estimate. Nor are they talking about "I should have this working today". They are talking about formal estimates (though they might be a one line email). The kind of estimates that Client Services want right now, Project Managers managers say will require a week of scoping and the people actually doing the work say "umm....a week or two for this item. three weeks for this" and is then wrapped in contingencies, estimate warning tools and other professional sounding ways of making educated guesses less risky.
For me, there are two quite distinct business models that have to be looked at separately when we are discussing whether estimation is a viable tool in a companies process box. (if you'll forgive the mixed metaphor.)
Project Delivery Companies
Project delivery companies are those companies who's business models are about servicing the needs of (ideally long term) clients. They are approached by a client with a specific need and requirements and agree to produce that project.
Companies such as these will struggle to move to a #noestimates approach. Clients are notoriously hesitant when asking for a product to be told "Give us a pile of cash, we'll put some people on it and we'll deliver what ever we can get done before the money runs out..." A factious representation of Agile? Yes, certainly, but one many clients will have with a new partner or one that has not been an agile delivery house previously. "Why should we take on the risk for the completion of what we want? You are the experts, you are the people in the market square shouting that you do this better than anyone. The risk therefore of getting all our requirements complete should be yours." Therein lies the problem. In a Product Delivery Company, you own the product and make the decisions on value. In a Project Delivery Company, you can only agree the value with your client and they have a heavy weight of authority.
An interesting counterpoint to this however is the paragraph from Doing Scrum Without Estimates stating I will ask one more question: “Did the PO ever prioritise one story over another based on it having a lower estimated cost (story point size)?” If the answer to this question is “No” then I conclude that all estimating in this context was waste because no decision was made based on the estimates that were given (instead the PO simply prioritised the highest value stories). If, however, the answer is “Yes” then estimates controlled what I believe should be value-based decisions. It is a very interesting point. If you are making these decisions with a client and they are not truly driven by the value that is going to be delivered, is there real use in spending a half day or more every sprint estimating the work you are doing to do? Why not JFDI?
The answer again is, can you really convince your client that committing their money and time to your company when you will not give them a guarantee of delivering what they actually ask for by the date they want it is a good idea? It can be done. A mature partnership between client and delivery company can produce some remarkable work, but that level of maturity and organizational trust is hard to earn. You are probably going to have to create, and hit a number of estimates on the way. Or take some significant risks like 'No Estimates' in Action: 5 Ways to Rethink Software ProjectsRainsberger made no promises up front, offering instead to show working software every two weeks — and also allowing the client to fire him with as little as two weeks' notice.
Product Delivery Companies
Product delivery companies are those companies who's business models are about creating one or more distinct products which are then taken to market and sold to consumers. They may (indeed should) take feedback on the next generation of these products but they are not directly beholden to their customers, the backlog they work from is defined by the company.
A Product Delivery Company, at its heart, is not beholden to its end users for the scope of the product. Rather than the customers coming to them with discrete requirements, they provide a solution for a gap in the market that they have identified. This is when the #noestimates approach can add real value. The point is not to hit an external idea of the product requirements but rather to create a valuable iteration of the product.
It is easier to sell, and to gain appreciation from your customers when you are regularly delivering new and valuable updates to your product. If you are being agile, and managing your work in clear user stories, and the team have ownership and engagement with the products then you are going to develop a clear idea of the most valuable improvements you can make, especially if you are using (as you should) a quantifiable, data driven measurement system.
The challenge is selling that idea upwards, convincing the ultimate decision makers that they can trust the teams working on the products to actually deliver real valuable improvements when they don't have a deadline and an estimate they've given to be measured against.
In the end, estimation, it is a form of risk management, and it is when this is forgotten that we really lose the value of estimates. It is a team of experts, of people with the skills tools and knowledge looking at a problem, with as much detail and focus as they can and drawing a line in the sand and giving a number. The business can then make their decisions on how much risk they are willing to undertake. What value does this collective experience have? Does the time spent investigating the problem to be solved? This is something that only the organisation can effectively answer, but it is a question worth spending time on.