Business Value in Agile: The Why is Valuable

Developers aren’t mushrooms; they won’t thrive in the dark being fed bullshit. Feed them a steady diet of business value if you want them to flourish.

What Is a Business Value in Agile

The term business value crops up often in agile literature. One of the most common forms of user story templates references it:

As a (role), I want (function) so that (business value).

However, the business value is more than just the closing clause of a user story. The first principle of the Agile Manifesto states:

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

This statement sounds great on the surface. Of course, we want to provide as much value as possible, but what is business value?

Roman Pichler provides a very succinct definition of business value in his book Agile Product Management with Scrum:

“An item is valuable if it is necessary for bringing the product to life.”

Unfortunately, I don’t find this definition very helpful. This interpretation seems to apply more to the MVP (minimally viable product). What if our product is already released and we’re working on a subsequent increment? How can I determine if request A or request B brings the product more “to life”? I need something more tangible.

In Agile Estimating and Planning, Cohn briefly touches on value but then jumps into prioritization factors. There is a strong relationship between business value and prioritization factors, but they’re not the same.

Next, I stumbled upon Cohn’s presentation on Incorporating Learning and Expected Cost of Change. Based on its description, I was confident I’d found a definition of business value, but alas, I was incorrect.

Everyone is trying to define business value by its calculation. The problem is that teams can calculate business value in many different ways. There are innumerable factors to consider, not all of which will be relevant to every organization. It’s a very situational calculation.

I must admit, I was starting to lose hope of ever finding a suitable definition. Erik de Bos’ Business Value article reinforced this feeling. His article implies there’s no agreement on the definition of business value within the agile community. He also simultaneously introduces even more prioritization factors. There should be a definition for business value that is distinct from how a team chooses to calculate it.

Then it struck me that determining business value is a lot like rating a book.

Even though everyone might follow a five-star system, they define the levels differently. Not only that but there isn’t much consensus on what factors go into rating a book. Hermione might base her rating on whether the book had a happy ending. Harry might be more concerned with how annoying the narrator is, and Ron’s primary concern is the plot. That’s a simplistic example because the truth is that each reader considers multiple factors in their ranking. And there is no guarantee that other readers will assess the same elements or give them the same weight.

Reading a book is a personal experience. The rating of a book is unique to each person, and I believe the same is true of business value.

All of this variability contributes to an unwillingness to define business value. After all, how would you define the term ‘book rating’? At the time of this writing, even Google seems to struggle with this.

Since a primary part of my learning process is finding exact definitions for words (and making those nifty vocabulary gifs), I must formulate the definition myself in this case.

Business value is an indicator of the benefits expected to be gained by a proposed change.

If I happen upon a better definition in my future research, I’ll come back and update this, but what I have will suffice for now.

Why is it vital given that business value is such a nebulas term? That’s precisely the question I hope to answer in the remainder of this article. Understanding and sharing the business value associated with a change request has several benefits, not all of which are obvious.

Enable Innovation

Developers have a unique skill set and knowledge of the current codebase that most Product Owners will not possess. We should leave the implementation details up to them to leverage their capabilities.

Defining exactly how something needs to be done instead of why can be a hard habit to break. After all, in the end, someone has to get to define the how. Presumably, the developers will be more familiar with the code base and have more refined technical skills that might enable them to make better implementation decisions than someone who doesn’t work deep in the code daily.

Also, when developers execute against a series of actions, it strips value from their contribution. They might start to think that any ole robot could execute directions. Skill and desire for problem-solving draw many developers to their profession. When we try to solve all the problems on their behalf, we take the excitement out of the role.

Let’s say I direct my husband to build a rectangle in the yard 5ft by 7ft. He is to use horizontal wood planks; on one of the short sides, there should be a door so that I can enter the structure.

My heartmate would instantly ask questions, but not all teams operate this way. Some cultures train their developers to do precisely what stakeholders ask of them and move on to the next task.

My husband builds precisely what I’ve asked in this contrived structure example. He does this in the easiest way possible. For instance, he simply leaves one of the sides open to meet the requirement for a door.

When I inspect my dog pen, I’m annoyed that the dog can just walk out the side of the fence. The missing side isn’t the only issue because, as it turns out, the wall is only two feet high. Our imaginary dog, Jumper, is going to leap right over that.

If I’d explained why I needed the structure instead of being solely focused on how to build the pen, both my husband and I would be happier.

As a dog owner, I need a fenced-in dog pen, so that Jumper (my dog) can stay safely outside without escaping.

With this description, we would have at least ended up with a taller fence and secured gate.

By understanding the business value the structure intended to provide, my husband also would have pointed out that 5ft by 7ft is too small for a dog pen. I missed a detail because I’m human, and not everyone is perfect. We can’t build a better product without the combined knowledge of a team that understands the end goal.

Now, don’t take this as an excuse to be vague in your details. The developers still need to understand the acceptance criteria. How do they know when they’ve gotten it right?

I could have specified the following acceptance criteria:

• The fence should be high enough to keep Jumper in
• The fence should come down to the ground (so Jumper can’t crawl under)
• The side door (or gate) should be secure and allow me to enter with a reasonable expectation that Jumper won’t escape

We should strive to provide enough information that the developer knows what we’re trying to accomplish and why, but not so much information that we squash their ability to innovate or provide feedback. It can be a tricky balance to maintain.

See Their Contribution

Although the initial structure would have come closer to resembling an unfinished flower bed than a dog pen, my husband did follow my instructions.

After talking and clarifying the requirements, he now understands that he’s building a fence for Jumper. The request isn’t just busy work, as it contributes to the overall mental health of the family. When Jumper gets the zoomies in the house, we can take him outside to run before he tramples multiple shelves full of action figures.

The same concept applies to developers. When they’re working on task after task, the job becomes monotonous. With no real connection to the value you’re delivering, and who it benefits, it’s tough to feel fulfilled in your career.

Negotiating with the Product Owner

Understanding business context can also enable developers to unnecessary options.

Our local park has a fenced-in area specifically for dogs. The park comprised the fence of horizontal boards and chicken wire that covers the gaps between boards and continues to the ground. Influenced by this fence, I might have thought it was an excellent idea to request a similar construction.

If I had, my dog pen developer, armed with his business knowledge, would have been able to point out another option. Instead of the additional cost and effort of mucking around with all that chicken wire, we could place our boards closer together. Jumper is a big dog, so he’d have difficulty fitting between the panels if we spaced them correctly.

By making this trade-off, we’d be able to finish the structure faster and cheaper. We can always add the chicken wire later if we decide it’s beneficial also to pen our daughter’s dachshund while she’s visiting.

We severely hamper these compromises when we don’t key the developers into the business value.

Learn the Business

One of the common complaints I’ve heard of agile teams is that they don’t take the time to understand the business. How can you build software to support a business you don’t understand?

On the flip side, one of the number one complaints I’ve heard developers make of stakeholders is that they don’t do a great job of defining requirements.

A single problem is at the root of both of these complaints.

If we include business value as a first-class citizen in our user stories, the development team will learn the business one bite at a time. With each user story they implement, they’ll piece together the bigger picture naturally.

Justify ROI

A Sprint has an associated cost. Given some number of developers with a given salary working over a fixed time, there is a hard cost associated with the effort. It will differ from team to team, but there is a number.

Knowing the business value the team plans to deliver in a Sprint can be a way to justify (or question) the return on investment.

Let’s say that a given feature will take a team two Sprints to implement fully. Once implemented, it will save Ron in HR four hours of manual work over the course of a year.

Although there is some value there, the effort to automate this process will cost us far more than the automation will save the company, so is that the most valuable thing that we could have the development team work on?

If we don’t include business value in our user stories, we lack the mechanism to justify our efforts or catch misplaced efforts.

Works Consulted

• Calculating Business Value
• Business Value
• Agile Estimating and Planning
• Agile Product Management with Scrum: Creating Products that Customers Love
• Incorporating Learning and Expected Cost of Change

TLDR

Sadly, all teams don’t think about or communicate business value. As a result, their development teams risk becoming code mills that churn out precisely what is requested.

The development team will feel unfulfilled, and animosity will build between the business and technology teams as each side feels like they’re not understood by the other.

If you want your development team to feel fulfilled, and offer more than a group of robots, don’t treat them like mushrooms. Share the business value with them, so they become closer to the business and offer more contributions than just generating lines of code in the dark.