In the past few years, Agile has been providing several frameworks that gradually replaced the traditional Waterfall approach in Software Development.
Scrum, in particular, is in many ways setting the standard for an Agile development process. Additionally, it facilitates the adoption of an Agile approach in a broader chunk of the sales process since it recommends that the Business Value is a necessary property of every Story.
Wikipedia defines the Business Value as:
an informal term that includes all forms of value that determine the health and well-being of the firm in the long run. Business value expands concept of value of the firm beyond economic value (also known as economic profit, economic value added, and shareholder value) to include other forms of value such as employee value, customer value, supplier value, channel partner value, alliance partner value, managerial value, and societal value. Many of these forms of value are not directly measured in monetary terms.
I would add that sometimes neither they are measurable. Nevertheless, several techniques were forged to estimate the BV, from the Business Value Game to the Balanced Scorecard. The bottom line is: make the business value measurable and assign a value to each story. The prioritisation can become quite an easy and less subjective task, having an estimate of both size and business value.
While many professionals consider the presence of Business Values as a sign of maturity of Scrum, the lack of such a concept in Kanban makes them deem this other modern framework unsuitable for software development:
Software development has things like business value, technical complexity, and user experience/acceptance/adoption — all of which are not addressed directly by Kanban.
From theory to practice, it might appear that the way stories are written and sized does not make estimating the business value any easier. As already pointed out by Mike Cohn:
When we get features that are too small (as good user stories are), it is very difficult to put a discrete value on each.
Even calculating the cost of these stories could be harder than expected since
with small features it is often the case that the true cost of implementing a feature is the sum of the cost of implementing multiple smaller parts of the system, some of which (e.g., architectural work) may not be separately estimated.
Let’s bring this even further. Assuming that we avoided the scenario described by Cohn and correctly shaped the stories, to do so we cannot avoid to:
- write the user stories,
- define acceptance criteria,
- estimate the user stories.
I do not believe this is an efficient approach. Way too much time would be wasted creating and maintaining a backlog with a high percentage of low-value stories created in the attempt of identifying more valuable ones.
Many companies must have reached the same conclusion considering the proliferation of well-structured approaches designed to drive the product envisioning process.
These frameworks are becoming a necessary step to embed Lean UX principles within an Agile organisation. There are some common steps all these methods agree on:
- Identify all the relevant stakeholders.
- Determine their needs.
- Drive them through the identification of their archetypal customer (generally called proto-persona).
- Outline the product that ideally will meet their needs and their clients’.
Most of the frameworks also share a story mapping exercise, that translates the product into requirements or user stories, allowing for the identification of an MVP. Once the process reaches this point, measurable Business Values are less relevant. Even if the Purchase feature is the most valuable story of your new e-commerce’s backlog, you might not quite get to develop it without a User Registration feature, which becomes mandatory regardless of its intrinsic Business Value.
If you ever had the chance to participate in a product envisioning session, you might have noticed that the process resembles a funnel. Many ingredients are channelled (the company’s culture, stakeholders’ needs and expectations, known risks) and the product is outlined and iteratively refined.
If you are still concerned about measuring the achievement of the fundamental needs, you could add the estimation of the Business Value in your Definition of Done, rather than in your Definition of Ready so that:
A story isn’t done until we’ve proved, through actual observation, that it has real business value
Many professionals are still looking for the right “formula”. I believe that is not possible to attribute a business value to anything more detailed than a Theme. Only a theme has the right size to ensure that we can calculate the cost and ignore the impact of shared cost.