Most project management methods have some definition of “business value”, traditionally it’s documented in a business case, Kanban advocates cost of delay, Scrum defines a business value for stories… In practice though, nearly all software projects are really concerned with delivering software. Frequent readers of our blog know that we believe software is useless until it’s delivered, so there’s nothing wrong with a focus on delivery and in fact we’re big fans of delivering quality at pace. The thing to keep in mind though is that delivery is not a goal. Delivery is a tool!
Software isn’t made to be delivered, it’s made to have a business impact
So maybe, just maybe, delivering software isn’t always the answer to the problem. But if it is, how can teams build software if they don’t have a proper understanding of the problem they’re trying to solve. So if you’re a product owner, analyst or anybody else writing requirements please remember, as a team you’re trying to solve a problem for your users, and so everyone in that team must understand the problem. Developing and delivering a particular feature is merely a consequence of that. Your first goal should be communicating the real problem.