So, When Will It Be Done? And How Much Will It Cost?

If there’s one question that puts all those lofty ideas about Agile and Scrum to the test, it is when a customer or manager casually asks: “So, when is it done? And how much will it cost?”. It's also one of the most natural and obvious questions for a customer to ask. Of course, they want to know if you can develop what they ask, and for how much. But at the same time, we know from experience that there is no easy answer.

Product development is full of unpleasant surprises, emergent discoveries, and better ideas that manifest halfway through the work. That makes it very hard to give a concise and clear answer to this casual question of your customer. And simply refusing to answer that question clearly will probably cause your customer to take their business elsewhere. So what can you do?

A Bit Of Context

I wrote the first version of this post in 2016. At that time, and since then, most of my professional experience with Scrum originated from commercial organizations, and working on business-to-business solutions. My struggle with this question was quite personal as I tended to either write or be closely involved in pitches, proposals and presenting them to customers. I was also part of many conversations that occurred when delivery dates had to be rescheduled or budgets had to be extended to account for new insights.

Since then, my work brought me to many different organizations — large and small — and although the dynamics are always different, this struggle between the reality of complex work and the desire for simple answers is a universal one. So following up on another extensive post about this topic, I wanted to revisit this blog post and update it with new insights.

It Is About Risk Management

The reason why customers, managers, and other stakeholders press you for a price and a delivery date, is because it gives them certainty. With a clear budget and delivery date that they hope to get from you, they can answer similar questions from their own managers. They can go into their own organizations with a clear message that things are under control. If your customer is an entrepreneur and investing their own money, they will probably sleep better at night knowing that there is a delivery date and that they know how much money it will cost them.

The issue here is that, in order to deliver an accurate answer as to when it is done and how much it will cost, we have to accurately forecast the work before we do any of it. In effect, we have to factor in all the variables that influence the success of our work, ranging from the skills in our team to the technology we use, the complexity of the domain, and the quality of communication. And then there’s the reality that customers often tend to change their minds, or “don’t know what they want” (as many teams lament). And it happens regardless of how long or small a project is, and how simple or complex it seems initially. Even for products that were expected to be delivered in weeks (like a website), I’ve found that scope spirals out quickly.

This is reality, not theory. And it is this grounded experience of product development that Agile software development has its roots in. So when faced with questions about delivery dates and budgets, you roughly have two options. You can either play along, and simply offer a date and a budget and hope for the best, or offer an entirely different kind of answer. Let's begin with the first option, which is the one that we often used initially.

Lets Talk Risk Management Theater

You can’t possibly blame customers or managers for trying to limit risk. If you’re a customer holding a proverbial bag of money, you’re fully in your right to want to know that that money won’t go to waste. For managers, risk management is often part of their job. If one of their projects goes belly-up, they may be held accountable by their managers for wasting money. So in their shoes, you’d probably be asking the same.

At the same time, by going along with these questions, and by providing a budget and a delivery date for an unpredictable amount of work, you are playing along in “Risk Management Theater”. You’re effectively persisting the illusion that, despite the uncertain nature of product development, it is still possible to offer an accurate budget and delivery date.

“By going along with these questions, and by providing a budget and a delivery date for a certain amount of work, you are playing along in ‘Risk Management Theater’”

But the hard truth is that costs will probably overrun the budget and that the delivery date will probably be rescheduled. Or worse, quality suffers as an incomplete product is released that turns users off and damages the brand. The irony is that everyone knows that this is how it goes. But they still play along in persisting this shared illusion or ask for hard guarantees to push all the risks to one party. But by that point, the party developing the product can easily hold the product hostage unless the customer pays more. So as a result of all this risk management theater, everybody loses. It's a great example of the risk of sunk cost; we’ve already invested so much that we’ll have to invest more to finally get our promised product.

So, How Should You Respond?

So how else can you respond? What actually is a good response when a customer asks how much it will cost, and when it will be done? I’ve found that the best answer is not to go along with the line of thinking behind it, but to offer an alternative with unique benefits that customers wouldn’t otherwise have.

Agile approaches, like Scrum, make risk manageable by not putting all the eggs in one basket. Instead of a big upfront plan and estimate for something that you and the customer haven’t worked on yet, you instead deliver small, useful, and valuable increments of the product at a steady pace. If these increments are as production-ready as possible or even taken into production continuously, the risk of failure decreases with each released increment. Because the more often you deliver a small and workable part of a product, the smaller the chance the investments of the customer evaporate without returning on those investments. Perhaps the costs will overrun at some point, or a deadline is missed, but this will not cause the previous increments to lose their value.

When delivery is incremental, the customer has the unique opportunity to stop or change their mind at any time. Work can be dropped from the Product Backlog, the order can be changed, or the budget can be expanded to capture additional valuable features. A customer can also stop at any point when they’ve reached their objective or discover that the product isn’t feasible, without being required to invest their entire budget and having to wait until a distant delivery date to make those decisions otherwise. This benefit is unique to an incremental approach, and it is a great way to help the customer spend their money where it is the most valuable.

What's more; an incremental approach doesn’t require the customer to bring a huge bag of money and a whole lot of trust in your ability to pull it off. They also don’t need to write up legal documents that spell out mutual penalties in case of non-delivery that only frustrate collaboration and don’t actually prevent sunk costs from pushing customers to pay more. With a (truly) incremental approach, customers have a visible and transparent process for managing their investment and avoiding the trap of sunk costs. They can capitalize on new valuable ideas as they emerge, and let go of ideas that turn out to be not so valuable.

Any entrepreneur, any customer, and any manager worth their salt should see how this benefits them, and how it makes it easier to manage the risk of wasting all the money on something that doesn’t return on those investments.

Your Professional Responsibility

Agile, including Scrum, doesn’t magically make projects successful. They don’t prevent mistakes and failures. But they will reduce the costs and impact of those mistakes because they can be detected sooner. If a technology doesn’t work well, it will take only a few Sprints — and not the entire development cycle — to discover. If the market response to initial increments is minimal, this can be discovered (and the course corrected) before the entire budget is blown. And that's the whole point of Agile; to be able to respond more quickly to the unexpected discoveries (bad and good) that are an inherent part of product development.

I also feel that it is our professional responsibility as product developers to not play along in “risk management theater”, but to offer a viable alternative that offers unique benefits to customers. Turn Agile into a competitive advantage for your customers, and how they invest their money.