Feature Thinning is the agile practice of simplifying the scope and implementation of specific features, on a case-by-case basis.  Often, given their growing knowledge of the technology and business domain, an agile team can suggest simpler alternatives to what the users originally asked for.  Often, these simpler alternatives still give all the key benefits, at much less cost.

It is important to thin features whenever you can, because the money you save will come in handy in other areas of the project.  For instance, the users may look at some other feature that you’ve built and say, “Yes, that’s exactly what we asked for. But now that we’ve had the chance to try it out, we realise we should have asked for something different.” There’s nothing wrong with that! It’s good and normal.  For instance, on one project we completely re-designed and re-built a whole series of key screens based on user feedback like this – and thank goodness we did! But you can only afford to delight your users like that if you have saved money elsewhere in the project – which is why it’s so important to thin features wherever you can.

A note on terminology.  Jeff Patton is the key author who has written about feature thinning.  But he didn’t call it “feature thinning”.  He originally used terms like “managing scale [of each feature]”.  I asked Jeff recently, and he confirmed that he now prefers the term “feature thinning”.

For more, see Jeff’s most excellent post on estimates, red herrings and dead fish.

[This post is a brief digression from my current series on contracts for agile projects. The final two instalments of that series will follow…]