Say I have one feature in the backlog that would delight Acme Inc, and another feature that would delight Barclay Instruments. My strategy (i.e., my prioritization criteria) says that Barclay is the more important customer. If I can only deliver one feature, which one will it be? Obviously the one that Barclay wants!
Because I have a big backlog of features I could deliver, I want my prioritization scheme to help me pick the features that match my strategy the best. Tell me which features will further the strategy, and hide the ones that will not contribute.
If my boss comes to me tomorrow and says, “Oh, we lost Barclay, let’s focus on Acme,” then it’s also obvious which feature becomes more important.
But notice that the features themselves didn’t change in response to the strategy. What changed was their strategic value. The fact that Feature 1 is appealing to Acme is intrinsic to the feature. The fact that it didn’t align with the first strategy, and does align with the second strategy, is purely a function of the strategies.
Real-life strategies are more complicated than simply “Barclay Instruments is the most important customer,” so the calculation of strategic value gets harder. But the point remains – the strategy doesn’t change the feature, it just changes the value of the feature for that strategy. Another way to think of this is that the strategic value of a feature is a “point in time” value, that changes when the strategy changes.
The problem I see with many of the requirements (feature) management tools that include prioritization functions is that they munge the prioritization criteria (point-in-time data) into the feature. Essentially what they’re doing is to denormalize the data. And just as with a database, denormalizing means there is a big maintenance cost when the prioritization criteria change. When the strategy changes, the features also have to change. And this can happen a lot as in the example.
In other words, with most tools I’d have had to put in a score for how well the feature matched strategy 1 (Barclay) into both features. And then when the strategy changed, I’d have to go back into both features and change the score again.That’s a lot of work if my big backlog is more than two features!
For a better approach, check my post on prioritization schemes. Or stay tuned to this blog – I’m sure I’ll be following up. Because to enable my idea, you have to support relationships in your requirements data model, and none of the tools do that very well.