Break the Feature Paradigm

I was thinking about product backlogs today, and I realized that they represent an interesting paradigm. In short, they equate features to a checklist. Once it is done, it is marked off. Completed. Done. Finito.

In reality, this isn’t true at all. A feature is a commitment to your users. For every feature, the initial cost is usually design, development, testing, documentation, and support. What’s funny, is every single one of those is a continuing cost that usually gets overlooked. For every feature, there are bugs that developers need to fix, testers need to verify, and writers need to document. For every design, there is usability testing that reveals flaws. For every feature, there is support.

To succeed, I think there are really two choices. One, eliminate as much continuing cost from each feature as possible. This can be accomplished by reducing uncertainty. Unit tests, functional tests, usability tests, continuous integration, and multiple testing environments all reduce this uncertainty. Unfortunately, this slows your turnaround time down unless you can hire at a rate greater than your continuing cost, which is hard.

Or you can implement less features. This means every feature you implement has to be super important and you can spend a lot of time making it awesome. What’s funny is you now have time to do all the things necessary to build a feature with a very low continuing cost. The obvious downside is, you may not be able to compete because your competitor has everything you don’t.

What’s better? I honestly don’t know. What I do know is every feature should be thought of this way and not as a checklist item. Then skipping that _useless _unit or functional test doesn’t seem as appealing.