7 . Thoughts on Value and BDD/ATDD
Two Thoughts on Estimating Business Value and BDD/ATDD
By Ken Pugh
ESTIMATING BUSINESS VALUE
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.
Business Value
Every change in a system should have business value. Business value can come from numerous areas, such as:
- Increased revenue (sales, royalties, fees)
- Decreased expenses
- Using less resources
- More efficient use of resources
- Customer satisfaction
- Product promoters / satisfiers/ detractors
- Staying in business
- Avoiding risk
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.
Tracking
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.
Bang for the Buck
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.
Developable Changes
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).
Business Value at MMF or at Story Level?
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).
- If the implementation time for the MMFs is small so that one or more fit into an iteration, then that could be the level at which you track business value.
- If the time is large, then I’d allocate the MMF business value to stories within it and track that. It gives more feedback
WHY SHOULD YOU TRY BDD/ATDD?
Behavior-Driven Development (BDD)
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”.
Acceptance Test–Driven Development (ATDD)
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:
- Customer (what problem are we trying to solve?)
- Development (how might we solve this problem?) and
- Testing (what about…)
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.
Attendees:
- We are rarely on the same page. This training requires and reinforces it…this is how training should be.
- Now I know why developers hate me! (From the Business).
- BDD makes communicating details and requirements MILES easier.
- I saw the whole perspective of a software lifecycle in a different and better way.
- Frames the way our team will create stories and tests.
- Help me and the team to understand when something is “done.”
- Provide better understanding to save time and reduce frustration.
- Communication and understanding will be improved.
Executive Observer:
- Every team went from zero to having solid usable examples of how to automate.
- There was so much discussion where they were trying to get on the same page that it made you wonder how they were working before.
- Immersive element is a huge differentiator – not short scenarios and not examples, real work – and fully cross functional – lays the groundwork for future requirements clarity.
Team -three months after:
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:
- Team “happiness factor” increased.
- Specifically, the lead developer and tester are much happier.
- Less stress on testers, more distributed testing effort across the sprint.
- Helped to create/enhance the “we are a team” feeling.
- Fewer production defects.
- Fewer test environment defects.
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!