Introduction

Business analysts, requirements managers, and project managers will find the greatest interest in this article.

Software Product Planning

It occurred to me last week during one of our weekly iteration planning sessions that one of the most esoteric methods around product planning is deciding which requirements to turn into software features.  The more rigorous approaches look at the cost of the feature, the potential impact to ROI ( assuming there is one ), and the demand.

What’s wrong with this approach is that it considers the features and resulting requirements in isolation from one another.  By not considering how each new feature affects the existing product as a whole teams can and do end up with products in which the original feature set, that made the software successful, become diluted.  Those of you who’ve worked with me know my favorite example is CA’s Remedy product, but I think one could find other examples: the Microsoft Office suite of products may be in this camp.

Feature Dilution:  A Formula

So how would one go about constructing a measurement for feature dilution?  First – some assumptions:

• You know or can retrieve the cost associated with the original marketable software release.
• You know or can calculate the benefit ( ROI ) for the original marketable software release.
• You have an estimated cost and benefit associated with any potential new software features.

Ok, so knowing these let’s construct a model for software feature dilution.  We’ll adapt a formula from the world of finance.

V – Value of sofware after Feature dilution =

((O x OP) +(N x (∑ IP1, IP2….IPn))) / (O + N)

where…….

O = original number of features

OP = Current NPV of product ( could use ROI too )

N = number of new features to be added

IP1, IP2, IPn = NPV of each new feature.

If you run this formula through some examples in time what you’ll find is that as a product matures new features need to continually generate greater returns to justify value to the original product and ultimately diluting the existing feature set.

This is exactly what should happen if we want to avoid the fate of an overly complex and unmanageable software product.  Just like stock market share dilution the product management team needs to justify that further feature dilution will grow the value of the product in terms of existing functionality…..not just that it will add to revenue.

Summary

Simplicity in software design has always been something great software architects knew yielded great products.  With this formula I hope I have provided at least a start to measuring simplicity in software.