Projects often deliver the wrong thing or functionality that isn’t as good as was hoped for. Time on projects is often wasted in arguments and re-prioritisation and some important things never get done.

In Agile and Scrum, we’re advised to focus on value and to order our backlogs primarily by the value of the story. Good advice: but how do we know the value?

And can we make that value meaningful? So it guides the decisions of everyone on the project – from the senior managers, thinking about the bottom line and deciding strategy, right through to the developers, making thousands of detailed technical decisions.

In this article we’ll look at an example of uncovering the value of a large-scale requirement. We’ll see how to create layers of value that connect the day-to-day implementation details to the big picture strategy with a crystal-clear line-of-sight.

We’ll see how to integrate that clear view of value into Scrum and User Stories. And finally, we’ll see how that helps collaboration and decisions on large projects.

Uncovering levels of value

Typically, user stories are a solution to some business problem. In fact most “requirements” are actually solutions to a business problem. So, when faced with a user story or “requirement” we can uncover a chain of business value behind it by using a simple application of Powerful Questions. Then, we can focus on value because delivering value is the real requirement.

I’ll use an example from a 100+ person programme where we applied Value-Focused Agile. They were building a system to replace manual processes across multiple business lines. I’m going to simplify it considerably for this introductory article and I’ll be slightly vague and use made-up numbers to keep client confidentiality.

To uncover a chain of business value, the key Powerful Question is repeating: “And what does the business get from that?”

For example:

• We’re building a system that publishes data every day
• And what does the business get from that?
• The users can publish the data with a lot less effort
• And what does the business get from that?
• The business will need less of the users in order to publish the data
• And what does the business get from that?
• Reduced costs

When doing this for real, the levels don’t always come out so cleanly and sometimes there are missing levels. There are additional questions and techniques to handle that, but we’ll keep it simple for this article, so you can understand the basic aims.

We can write the results of our questioning as a “chain of value” where each level has traceability to the level above:

Clarifying the value

The statements of value are still ambiguous. People could misunderstand what’s meant and potentially build the wrong thing. And the statements aren’t testable so we can’t tell whether the value has been delivered, or whether we are making progress delivering the value.

We can use more Powerful Questions to clarify the value. There is an art to asking clarifying questions that is outside of the scope of this article but, as a little taster, some questions that help you get more specific are:

• Precision questions
  • How much X is there now? / How many X are there now?
  • How much X will there be when Y? / How many Y will there be when Y?
  • By when X?

By clarifying meaning and removing ambiguity, we can rewrite the chain of value as:

It’s more complicated in the real world

I’m keeping the example simple; if you were doing this for real you would want to uncover the specific meanings of “cost”, “publish” and “data”. What I hope this example shows is that you can create a simple, unambiguous, testable statement of value at multiple levels.

You’ll also find as you do this for different solutions or user stories, you’ll start to uncover multiple definitions of value at each level. That’s good and in later articles we’ll see how to manage that.

You’ll also find that different stakeholders value different things. You’ll need some more advanced techniques to track that, but it allows you to precisely know how much value you’ve delivered to which stakeholder at any time, which is pure gold information when it comes to working with stakeholder’s expectations, reducing politics and increasing satisfaction.

Developing product solutions

Within the context of the product, we now have extreme clarity about what the product needs to do: Reduce Effort (defined precisely above) from 8000 to 500 hours.

A next step might be to break down the activities required for “publish data” and analyse the current effort for each of those activities. We can start to brainstorm solutions that incrementally reduce the effort in the activities and then prioritise those ideas that have the most ROI (i.e. they reduce the effort in the activities the most for the least implementation effort).

By clarifying the product value, we’ve created a clear goal where the technical and product people can collaborate and innovate product solutions. The value has meaning for them because they can directly influence it with their ideas and implementation.

By clarifying the levels of value, we’ve given a high degree of confidence that the product solutions will ultimately lead to the business value that we’d like.

At every stage, even in the most detailed breakdown or technical solution, perhaps developing screens or infrastructure, it’s possible to keep a crystal-clear line-of-sight of the value right up to the business value. I’ll talk more about how to do this in future articles.

Linking this to Scrum and User Stories

With a chain of value, a Scrum team’s Sprint Goal can be crystal clear. Perhaps the first sprint might be: Effort (as defined above) reduced from 8000 to 7900 person/hours. The team now has a meaningful challenge that it can creatively tackle.

With more maturity, the value can be measured and team members can discuss that data in demos and retrospectives. Value creates a solid, empirical basis for Scrum’s ability to Inspect and Adapt and points it straight at what the business really wants.

If the team is using User Stories, then they can simply link the story to the value. For example: As a DataManager I need an adjustment screen (instead of my Excel spreadsheet) so my effort in correcting data errors is reduced from 30mins/day to 10mins/day.

Adopting value-driven Agile

When I first teach this to people, some are concerned about the measurement of the numbers or the consequences of not meeting the goals. There are potentially complex personal and organisational culture issues here. Fortunately, they are talking about a mature state and there is lots of benefit to be gained from a very gentle first step, which is to use value as a communication tool.

By specifying value this clearly and having a value chain, everyone on your project and all your stakeholders can discuss how delivering value at the product level leads to business value. This line of sight enables them to make better decisions and to challenge assumptions when they believe what’s proposed won’t deliver the higher-level value.

The first change in behaviour I’d encourage when adopting these techniques is “Are people referring to the value in their decision making?”. For example, is there a “one-pager” with the value chain and I see and hear it being referred to repeatedly in strategy meetings and planning meetings. Do I overhear people debating the merits of different solutions by talking about the “Effort saved”?

Embedding value into decision-making changes conversations from arguments that are based on gut feel and misunderstandings to ones based on a clear, shared understanding of what’s important to the business.

Value-focused Agile is first and foremost about better communication. Once you’ve mastered that, the next stage is to plan to deliver value early. And once you can do that, then you can measure and learn from the value you actually delivered.

What Next?

• To learn this in-depth, look at our training and our coaching
• To benefit from the approach in your organisation, please Contact Us
• Let us know what you think by commenting below

Credits

Value-Focused Agile is a result of my experiences making Agile work in large, complex environments. It is primarily a combination of the Evo method developed by Tom Gilb, traditional Agile methods, and soft skill techniques from the world of coaching, particularly Clean techniques developed by David Grove.