Sunk costs – when to cut your losses

A sunk cost is an accounting term referring to something (e.g. a project) that has been heavily invested in without success and will not continue to be funded. In these situations, often more money or time has been spent than is wise and it continues because so much has already been invested. The mantra is “I’ve already put so much in, I can’t stop now or it will all be for nothing.” The sunk cost is realized when it’s determined that no more money or time should be invested because of the lack of success. The cost is sunk; the money or time spent will never get a return on investment – it’s simply a loss.

We see this in IT projects, in cars, houses etc. How much money or time is too much to invest? Do you keep investing just because so much has already been done? When do you cut your losses and move on? When do you admit failure? While sunk costs are a continuous reality, I don’t like to think of them as a total loss. There should always be something salvageable from the sunk cost – it isn’t a total failure. Even after a car is totaled, it still has some salvage value. After a house is flooded, the frame is usually still good. Very rarely do you have to start over from scratch with nothing remaining.

In Scrum terms, a spike story that didn’t pan out or a feature that has been being worked on and the product owner decides they no longer want it are examples of sunk costs. Sure, there has been time invested in it, maybe a lot of time in some cases, but almost certainly something was learned in the process – or maybe there is some code that can be reused. Even though tangible monetary or business value may not come directly out of the salvageable part, usually something can be gained or saved.

So how does this fit into Scrum? The possibility of having a sunk cost should not deter teams and product owners from taking risks. In fact, it should encourage moving the risk forward to address it early. If it is something that does not work out it can be learned from and mitigated up front; the team can inspect and adapt to keep from making the same mistake twice. Even if something fails or an iteration or two is wasted, there should always be something that can be salvaged – even if only the fact that it happened up front and not toward the end of the project. There is always something to be gained and learned from making a mistake, and it’s not the place for blame. Sunk costs are often overlooked by many people with blinders on who are only seeing what is going in, not what isn’t coming out. Realizing and addressing a sunk cost is a tough thing to admit, but when it can be learned from it can turn out to be a great asset for teams and stakeholders to learn from in the future.