Time box

Give us two weeks and we’ll show you what we can do.

This is the mantra of Agile. The idea is to shape the work to fit in a time box. Have something of value presentable by the end of the time box and you’ve shown the customer what you can do with that time.

This way you aren’t predicting the future and constantly ending up wrong. You’re showing how far you got. The customer can then decide if they want more work done. And, well, since it’s been two weeks it’s a good time to ask for a check so your people can get paid.

While this isn’t for everyone it’s certainly an alternative to estimates.

In my experience estimates are mostly consequence free guesses. When they decide to get serious about this stuff they call them bids. Those have legal consequences.

The leading alternative to estimation is the use of flow metrics and probabilistic forecasting. If you have historical data on cycle time and throughput, you can use statistical modeling to determine how long it will take to complete the work with a given level of accuracy.

However, this approach will require some effort to break down the work into right-sized pieces. With a large enough sample size of historical work, some variation in sizing can be ignored, but you need to have the work reasonably sized. You probably won’t be able to take a raw request and use your flow metrics to determine how long it will take. This may be a bigger investment of time than it takes you to refine the work sufficiently to provide an estimate, but the quality of the predictions will likely be higher.

Since the data is based on history, there are also several things that can disturb the data. Any changes in context could make the historical data less relevant. This includes changes to the team, the problem domain, the tools and technology, and the processes and way of working. If you have a large enough set of teams within your organization, you may be able to try to get some organizational historical data, but it would be less accurate than a single, relatively stable team over the life of a long-lived product.

As candied_orange notes, the mainstream alternative is to timebox the result. You basically deliver whatever you have completed after a certain amount of time and charge for the time. The issue is that a lot of customers probably won’t accept this arrangement. Think about if you were having some work done on your house, would you pay a contractor for whatever they deliver in 2 weeks? How do you know that they won’t just slack off? That requires a lot of trust and if you are managing a business, entering into such a deal is highly questionable.

One thing that strikes me in your question is “Work is generally broken down into small chunks, with estimates being provided for each of these, rather than large pieces of work all at once.” This is problematic and an example of one of the most common misconceptions I see around estimation: that estimating more granularly will improve the estimates by increasing precision. The problem is that while you might increase the precision (likely with false precision) it’s almost surely going to reduce your accuracy. As an analogy, let’s say I asked you to measure a length of a long straight board. You have two unmarked measuring sticks of known length: one is a meter long and the other 10 centimeters. Which one is going to give you a more accurate answer? The 10 cm stick has higher precision but requires more measurements and the errors in each measurement will tend to accumulate. You will get a more accurate answer with the longer stick. In fact, one trick to increase the accuracy of any estimate is to lower the precision. For example, if try to predict the location of a person in the world, I’m much more likely to be correct if I give a larger area as my answer. You should really limit the precision of your estimates to what is useful. If you are estimating in hours because that’s what you charge by, that’s a mistake. The client is unlikely to be making their decision hinge on the cost of a single hour of work. They are probably thinking in multiples of money e.g. $10K or $100K, maybe millions if it’s a big project.

The other big issue I see with estimates is that people are either unaware or disregard the fact that an estimates are inherently ranges/distributions. Often people just give a single number and never provide any guidance of the precision. That’s not an estimate, that’s a guess.

Lastly, I also find it frustrating that people ignore prior art around this kind of thing. PERT, for example is a useful technique with a sound mathematical foundation. I’m not saying everyone should be using a formal process like PERT for their projects, but understanding things like how to add up variances across a number of estimates and use those to predict a delivery time with 98% confidence can really help with wrangling the issues you describe.

Ideally, a company would capture metrics/measurements of how long projects take. How “big” or “complicated” was project X? Additionally, reviews (sometimes called “post mortems”) would be held after the project’s completion.

One software consultancy I worked at required all work to be measured in 15 minute intervals. They were able to prove how long it would take to develop things (whether “just a web page”, or significant redesign & upgrades to the sites involved). This way they could always show the customer what things were going to cost and the customer was able to say whether those changes made financial sense (or not). They were very uptight about billing and every code check-in had to point to a project that was paying for that code (even internal “refactoring” had to have a project to bill to). They were too uptight for my preference, but I believe that they were one of the few places I worked where they gave estimates that were reasonably accurate. They had multiple clients each having different software needs & solutions.

Your agency should have been collecting metrics. How “big” (nowadays, usually called “points”) each task was. And measuring how much each developer billed (or documented working) each of those tasks. Eventually, you can say “developer X says this is 4 points” and from experience that means developer X is going to take 6 working days to complete that task. If developer Y said 4 points, that takes them only 4 days. That does not mean X is better than Y. It just means that for X, “4 is this big” means “6 days” and for Y, “4 is that big” means “4 days”. Too many mismanagers would think something like “Y is a better developer because they get it done 2 days quicker” and they would be wrong.

If you never capture estimates and examine them afterwards, then estimating project times is useless. This is the state that most companies I’ve worked for were in – never looking at those estimates ever again. For those companies, deadlines were determined by managers looking at calendars.

Function Points and COCOMO are reasonably well known estimating systems. There are books about them that you can read. I’ve made simple Excel spreadsheets with Function Point estimators so when a manager goes “how big is that”, I can punch in a few numbers, multiply by what I think the complexity is, and get a reasonably close answer.

You can charge in a outsourcing or agency fashion. ie X developers at rate Y working full time on the clients project.

Of course the client will still want a rough estimate, at which point you can also charge for a project manager to work out the estimates for them.

This model maintains the trust between your client and you by allowing the client to manage the resources (more) directly. You can sell the idea by saying that it can reduce costs by removing the priced in risk of underestimating, the possibility of dropping features that turn out not to be needed and/or allowing changes in spec during the project at zero cost.

Just don’t give estimates

It’s as simple as that really… If your client demands estimates, you explain why it’s a futile false economy.

At that point you explain the benefits of an estimateless system such as Kanban, and then offer to do a small subset of the work to demonstrate how well it works. You can always give them heavily couched ballpark estimates under the proviso that they will be wrong and they’re for very rough guidance only.

If they still insist on proper estimates then you either suck it up and give them some estimates or you go find a less archaic client.