Where Do Unused Features Come From?

July 12, 2011

My last post discussed why Cramming Features into a Product is Bad Business. Coincidently, a related issue popped up in the LinkedIN Agile group discussion, Do you agree or disagree that Scrum is not Agile? – as the discussion found its way to the topic of requirements.

Horia Slușanschi referenced the oft-quoted Standish Group’s statistic that over 40 percent of a systems features are never used. The exact figures from the Standish Group are depicted in pie-chart form below:

How do these unused features find their way into the system in the first place? And what can we do to prevent what is clearly a huge waste?

Expanding on my LinkedIN answer, I can think of four possible ways that this can happen:
  1. The business appoints representatives to work with the development team who are either not the actual users of the system or those who will make use of all of its features. As a result, their perspective on what is necessary and a priority is biased or incorrect – and they may not invest the time to work with the actual users to find out what is actually needed.

  2. There is a strong organizational aspiration to “nail the project,” creating an undesirable side effect of adding any and all possible features up front so that the organization “doesn’t have to come back to the project later.”

  3. If the potential for future, follow-on work on a system is questionable in the minds of the users, they most likely will feel that they only have one shot to articulate their full spectrum of needs – and start speculating and adding features in anticipation of future needs that may or may not become a reality.

  4. A large range of features are asked for as a negotiating tactic because the users expect scope to be negotiated down; if not at the beginning of a project, then later, when the project is falling behind – and people look to cut scope to make a date. If the latter scenario occurs, the risk is that lesser-valued and/or unnecessary features have already been completed.
One great way to avoid wasting all of this time and effort is to start small, deliver frequently, have product demonstrations and robust conversations between the development team and the customer/users (preferably the actual users, not a proxy) about what has been delivered, what the next priority is, and to iterate (re-work) as necessary over delivered features until they are fully correct from the users’ perspective. (Doing everything possible to prevent the re-work scenario, like using high-fidelity prototypes to validate requirements and user interaction.)

And that is just what Agile development is all about! Establishing trust through early and frequent delivery. Having conversations between the development team and the business users. Rigorously prioritizing the work. Welcoming changes to priorities. Eliminating overhead and waste.

And the waste involved with unused features is huge. The person-hours invested in articulating one feature requirement to the development team along with designing, writing, testing, documenting that feature is a significant cost in its own right, but other costs are more exponential in nature. The complexity and interdependencies of each and every feature added to the system raise the bar in terms of design and testing challenges, and they require increasingly greater time to contend with, one way or another.

By one way or another, I mean that in order to keep a system maintainable, development teams need to follow good programming practices. Portions of the code base will need to be refactored as the code base expands with the addition of each and every feature. This is a tax that you should pay.

If you ignore it, you will pay another tax: buggy, difficult to maintain code that will take increasingly longer periods of time to add features to, eventually reaching a point where developers throw up their hands and say, “No Mas!” because the system is un-maintainable.

I haven’t seen any statistics on this, but it would be interesting to see how this “unused feature” metric correlates with Agile software projects. I would expect the figure to drop dramatically.