I wrote this as a comment on another site, but thought I'd stick it here too. If you don't give a damn about software, then don't read it.

I consider inventory to be any software that we've written but have not yet sold a single copy of. Much like the manufacturing-equivalent, where unsold stock sits in a warehouse, this software has cost us money to make, and has also cost lost-opportunity of the workers who made it, who might have made something else that we sold instantly. Although, unlikely manufacturing, it probably takes the same amount of physical storage space for lots of inventory as it does for none (i.e. about the size of a server rack, compare with differening sized warehouses in the physical world), in my opinion, it is still highly undesirable to let completed code remain unsold and unused. If there's no way this code can be sold now, then perhaps that's an indication that something else should have been made first. However, there are some reasons I've seen given for why "we cannot sell this yet".

1. We're waiting for more features, to make a bigger impact.
2. Selling it in this state will give a false impression of the software.
3. Selling it at this stage will give a negative impression of the company.
4. Deploying a new solution is so much work that we can only do it infrequently.

The first three of these come into the category of "minimum marketable feature set", something which makes sense, perhaps, in the earliest stages of a product, but which, in a mature offering, could be a falsehood, born out of not understanding the customer, having customers with unrealistic expectations, or to cover up inadequacies in the requirements gathering process. If a single story cannot add some measurable value to the product enough to make it worth buying by a customer who needs that value, then the story may not be worth implementing.

Number 4, however, is a compelling argument. If the process of deploying a new version requires a lot of people, training, communications, supporting materials and so on, then perhaps the deployment shouldn't be done that often, though internal deployment should continue, to ensure feedback etc.

The big problem with inventory, apart from lost opportunity cost, is that it goes out of date. Technology moves, as does our understandings of user requirements. Something I made last year may no longer cut it as the solution a customer wants to use. So, the sooner the code is out of the door, the better. I reckon it's best to get in there first with something simple and coherent, than join the party increasingly late with something brilliant, but costly.