Quite naturally, we often look at software development as the process of doing stuff, of creating new things, of generating new features for our customers.
And our enthusiasm for doing things, for making customers happy, can lead us to create lots and lots of new things.
Let’s think for a minute, though, about the costs of creating each new thing:
Of course, when we’re considering development of that new thing – whether it’s a new application or a new feature – we often think only of the cost of item 1, the initial coding, even though we can clearly see that this is only the tip of a very large iceberg.
So what is the alternative? What can we do instead of developing that new thing, in order to save all this cost?
In order to exercise this last option, of course, you will need some means of establishing the priority of this thing compared to other things of a similar nature. And here we run into another strong reason for Delivering Early and Often. If your project will only have one large monolithic delivery, then it will be pretty hard to get anyone to admit that any of the proposed features don’t deserve to be included, and so you will end up with everything on your list, up to and including the proverbial kitchen sink.
On the other hand, if you are delivering new software every 1 - 4 weeks, in a regular, repeatable cadence, then it will be much easier to get agreement on what is to be included in the next sprint, since other items are not being dropped forever, but only left on the backlog for consideration again in a few more weeks.
At some point, of course, you will have implemented the most valuable features, and will only have low-value features left in the backlog. At this point, your governance process should kick in, and divert your available investment dollars to some other project, so that your organization can continue to maximize the value being created for your customers.