The Business Value of Requirements

Assigning a business value to each requirement is a key idea in agile approaches like Scrum. The relative business values provide an initial prioritisation of the requirements. The idea is to try and deliver as much business value as soon as possible.For projects with less than a hundred, user-story-sized requirements this can work well.

In contrast, for projects with several hundred such requirements, where a significant proportion must be implemented for the end-result to be of any use, spending time valuing individual requirements becomes over-kill. In these cases, it is better to work with sets of features related by business or user activity, prioritising as much by risk and dependency, FDD-style.

However, business value can still be used to determine if a set of features form part of the minimum viable product (mvp), are worth the cost of developing, or will cost more to develop and use than they will ever produce in profit. It makes absolutely no sense to even waste time talking with a development team about a set of features if those features will not increase revenue, increase productivity, or reduce costs by a reasonable amount. The only exception are features to meet regulatory requirements but these are usually well and truly part of the mvp.

Omitting requirements of little or no value seems like common sense but stakeholders often feel pressured to insist on requirements of dubious value. There is the pressure of existing business practise, the ‘way we do it today’, or ‘what we have done for years’. Then there is the worry of not wanting to leave out anything important so they cannot be blamed for missing it when users complain later.  Of course, personal hobby-horses and a perceived need to protect vested career interests can also add to the pressure to insist on inclusion of dubious requirements, and include them ‘in the first release!’. Examining the business value of such a set of features provides objective ammunition to fight back against the emotional pressures to include them early or at all.

Estimating the business value of a set of features is straight-forward in some cases but in many situations it is not, and half a book could be written on the topic as Mike Cohn has in Agile Planning and Estimating. It is not enough to consider the frequency with which a set of features will be used. An infrequently used feature may deliver relatively enormous value each time it is used. In contrast, the frequent use of another feature may generate only a fraction of that value. Some high-value features may only deliver high amounts of business value for a very short period of time due to known impending business practise or regulation changes but a lower-value feature may over a longer period of time deliver far, far more value. 

About Author

Leave A Reply