In Agile software development, the term “business value” is often used when discussing the feature on a Story card, or when considering prioritisation between many possible cards. This might seem pedantic, but “value” is the wrong word to use here.

What we’re usually discussing is business benefit. This is the benefit a business will get if they implement the story, and might include any of the following:

• Reduction in cost.
• Increase in revenue.
• Compliance to regulations.
• Increase in productivity.
• Learning and new knowledge created.
• Removal of risk.

Knowing the benefit is important, and it’s usually the most significant thing described on a Story card. But it’s only half the picture, because obtaining any of that benefit will require work. This is the “cost”, and consists of:

• The cost to develop. This can be predicted from the estimate and the velocity of the team.
• The cost to support. This is ongoing cost that will have to be paid to support the feature described by the story (e.g.. hardware, regular maintenance / manual intervention, etc).

It’s only after estimating both benefit and cost, can we determine estimated value. In simplistic terms, value can be described as a relationship between benefit and cost:

value = benefit / cost

Knowing this, we can intuitively see that value can be increased by either increasing the benefit or decreasing the cost. Thinking about benefit and value in these terms makes it much easier to understand prioritisation of stories — you simply do the story that has the highest value first.