Creating software is about delivering business value. Without some measure of business value, it is hard to determine whether the software has any.
For several years, I have presented a session on estimating business value to local user groups and national conferences. My book, Lean-Agile Acceptance Test-Driven Development: Better Software through Collaboration, includes a section on estimating business value.
Here are some ideas from the book and other morsels accumulated over the years.
Every change in a system should have business value. Business value can come from numerous areas, such as:
Business value in some areas is easy to quantify. It is straight dollars. However, in other areas, quantification is more difficult. But without some way to compare these “apples and oranges” it is hard to determine which changes should have higher priority.
For example, should a change that saves $10,000 be prioritized over a change that gives some customers more satisfaction?
One way to compare is to assign a relative business value to every releasable change. I use the term releasable change, which could be a feature or a story, depending on how an organization uses these terms.
Since business value is not achieved until a change is released, then it should be applied to a releasable change, rather than a portion of that change.
The customer unit has the responsibility to assign business value.
The business value does not have to be an exact measure. It is just relative. If the $10,000 savings seems to be the same as giving customers more satisfaction, then the changes have the same business value.
Relative determination may be made by putting the changes up on the wall one at a time. If a change has more business value than another releasable change, place it above that change. If less value, then put it below, or if about the same, on one side.
If a releasable change fits between two stories, move the stories and make space for the new one in-between. For example, from the chart below, “Change Two” has the highest value, “Change One” and “Change Three” are about the same, “Change Four” less than those, and “Change Five” seems a lot less.
You can use a Fibonacci series (1, 2, 3, 5, 8, 13…) or a power-of-two (1, 2, 4, 8, 16, 32…) series to assign a value to changes in each row (as shown in the next chart).
Where you start with the numbering is not important, as long as you assign the same numeric value to equivalent changes in the future.
Now, periodically, you can measure the cumulative business value of the delivered changes (see next chart). Since the key in agility is to deliver business value quickly, such a chart provides feedback for the developer and tester units to see how well they are doing.
Presenting a business value chart prior to or in lieu of a burn-down/burn-up chart can focus attention on this critical measure of software delivery.
Since the business values are determined by the customer and are not accumulated until the corresponding change is accepted, this chart can present a more accurate picture of the value the software is currently providing to the company.
The developer and tester unit can estimate change effort in story points using the same technique as for business value as an alternative to story point poker.
A change’s business value estimate divided by the estimated effort yields “Rough Return on Investment” or “Bang for the Buck” (BB). It is a rough guide to the relative return on investment. It can provide another input when the customer unit makes decisions as to what changes to develop.
If changes are developed in a BB sequence (high BB valued changes completed first), then the return per effort spent will decrease over time (as shown in the later iterations in the previous chart). At some point, this return will decrease below that of another project. The current project should be terminated. Not because the project is a failure, but because it no longer provides the best use of resources.
For financial-oriented individuals, the total return on a project (dollars saved or revenue earned) can be divided by the total business value for all changes. The result is the dollars per business point.
A releasable change may have one or more developable changes which can be created independently.
You may allocate the business value for a releasable change to developable changes to show progress. But the business value is not actually realized until the entire change is released.
Note that these developable changes may have business understood acceptance tests or developer-only acceptance tests (e.g. developer stories, enabling stories, or technical customer changes).
If you use Minimum Marketable Features (MMFs), that is the best place to do business value estimation –since every story in an MMF has to be completed before the business value is achieved (otherwise, the Minimum Marketable Feature is not the minimum).
It is a test-first, software development practice that encourages collaboration among developers, testers and customer representatives in a software project.
With the goal of providing built-in quality, it encourages teams to use conversation and concrete examples to formalize a shared understanding of how an application should behave.
Written in a shared language, it improves communication between tech and non-tech teams and stakeholders.
Instead of referring to “tests”, a BDD practitioner will prefer the terms “scenario” and “specification”.
It is a collaborative process where developers, testers and business representatives come together to write acceptance tests in advance of implementing the corresponding functionality.
The goal is to work out requirements, perceive potential pitfalls and reduce the chance of errors before coding begins.
ATDD is written from the perspective of the user and answers the question “Is the code doing what it is supposed to do?” The collaborative discussions that occur to generate the acceptance test is often referred to as the three amigos, representing the three perspectives of:
These acceptance tests represent the user’s point of view and act as a form of requirements to describe how the system will function, as well as serve as a way of verifying that the system functions as intended.
Listening others’ opinions is an effective way to get insights about the benefits, advantages and practical value of something…
Here are some comments from attendees and an executive observer at one of my BDD/ATDD workshops. Also, a report from a team three months after the workshop.
The product owner was originally skeptical going into training, but she is clearly a fan now, stating that it is “totally worth it” to do ATDD.
Her thoughts were mostly about the effects of the workflow changes. Automated testing was more of an after-thought. She could clearly see and articulate the benefits of simply implementing the workflow change associated with ATDD. She said that one day of ATDD specific training, plus a half day of coaching, plus a committed team is all you need to get going.
Benefits she cited included:
I am Ken Pugh and these are my agile-thoughts
2021 © Durham, North Carolina, USA by Ken Pugh
Ken Pugh helps companies develop software effectively by removing waste and delays in value streams; building in quality with ATDD/BDD; and creating a collaborative environment.
He has written several books including the 2006 Jolt Award winner Prefactoring and his latest: Lean-Agile Acceptance Test-Driven Development: Better Software Through Collaboration.
Ken has helped clients and presented at conferences from London to Boston, Sydney, Beijing and Hyderabad.
Was it interesting? Share it others!