3.1 Value mapping

Before we begin the value mapping activity, let’s check our definition of ready. We’ll need outputs created in previous activities — especially 2.5 Context mapping and the supporting details about those contexts:

Before starting

Value mapping narrows the focus from the broad scope of a project to a smaller increment, then weighs the risks and rewards it offers. We map each feature’s benefit (to both customer and business) and its design and implementation effort — rendering relative value and relative risk. Out of that, we prioritize and decide disposition: build, buy, leverage, or adapt. It’s the first activity of the Delivery phase because this is where we plan the next increment — and we need to understand its value before we start building it.

Value mapping is part of a larger practice called value stream engineering. For the broader picture, see the companion blog posts How to deliver more customer value than your competitors and Value stream engineering in a nutshell.

What’s an increment?

An increment is:

The smallest amount of work that delivers a high-value feature into your customer’s hands.

To decide what feature fulfills this goal we need to understand its value and its cost. “Cost” here isn’t just monetary — it includes time, effort, risk, even opportunity cost. Value mapping quantifies and visualizes both.

We perform value mapping every time we plan an increment. This ensures changes in the architecture, value proposition, or technology state are taken into account before we start delivering. It’s fine if the activity is cursory and mostly confirms past decisions — but it’s critical to do, so we don’t miss changes.

There’s a subtle distinction between value mapping and sprint planning. During value mapping we’re still deciding what to build (shaping the future state). Sprint planning is about how to deliver (prioritization and implementation of an already-known target state). For example, during value mapping we decide whether to build our own IAM or pay for AWS Cognito — a what conversation. By sprint planning, we already know we’re integrating Cognito and the question becomes how much we can deliver in a sprint.

The steel thread goal of eliminating major risks early might seem to conflict with value mapping’s preference for low-risk features. These are two stages with different goals. Steel thread is an early-stage architectural exercise where “eliminating risk” is the value proposition — proving the architecture won’t sink the project later. Once those risks are dealt with, we shift into a regular cadence focused on reliably delivering high value each sprint.

Guide to value mapping

The desired outcome is clarity on each feature’s disposition (buy-versus-leverage) and its value. It will help prioritize what we build in the coming iteration. We want to deliver as effectively as possible — which might mean we don’t want to build, but instead leverage. By leverage, I mean we could buy something, we could adopt something, or we could adapt something: let’s not reinvent the wheel.

During value mapping, we need to be in the headspace of our customer. We’re looking at the problem from their perspective, thinking, “what’s the most valuable thing purely from my customer’s point of view?” The best way to answer this is to just ask them — your customer should be at the table making these decisions with you.

This means letting go of our own assumptions and desires. No more, “I think this is important.” As the engineer building something, we cannot make that call. Only the customer can tell us what is important to them.

That doesn’t mean we won’t add necessary components, features, or infrastructure. If something is required to deliver a customer’s most desired feature, we’ll build it. But we should not confuse what the customer wants with what we deem a required component. Every decision needs to consistently align with delivering what the customer values.

Inputs

• Sufficient time and commitment from your entire team (the business, technical roles, and very importantly, your customer) to devote to the workshop.
• Up-to-date event maps and corresponding objectives and key results.
• A visual map of your bounded contexts that clearly indicates how each context depends upon and communicates with other contexts.
• Any previous decisions to buy or leverage components (rather than build them from scratch).
• A functional architecture describing your target state and elaborating on specific technologies and design decisions about languages, frameworks, tools, and libraries.

The value map and risk map

We build two maps:

• Value map. A quadrant graph plotting features by customer benefit (vertical) versus business benefit (horizontal). The sweet spot is the upper-right quadrant: high customer benefit and high business benefit together.
• Risk map. A quadrant graph plotting features by design complexity (vertical) versus implementation and maintenance effort (horizontal). The sweet spot is the lower-left: easily leveraged technology, minimal effort, little design risk.

Done well, the sweet spot on both maps points you toward the highest value and lowest risk features. We won’t always be able to have both — decisions will be made, pros and cons discussed — but the goal is a well-informed decision that delivers the most value, as reliably as possible, with each increment.

Process

In this activity, you need a lot of information about each feature. You’ll want your whole team at the table — technical, business, and customer. Each role offers important perspectives: business drivers, cost, technical complexity, customer desires.

Up until now, I’ve talked about value mapping “features.” But what exactly is a feature? Start with your context map:

1. Each domain and sub-domain is the starting point for a feature. For the Peloton bike use case, the context map includes Borrower, Payment Profile, and Borrower Account. Whole contexts can represent external components (IAM, Underwriting).
2. Sometimes a context is synonymous with a feature. Integrating with Underwriting is a pretty well-packaged feature — you either implement the API call or you don’t.
3. At other times, more granularity is needed — break contexts, domains, and sub-domains down further. For instance, the Sale context might need to track payments for whole purchases; add a Payment Record sub-domain, which now represents a new feature.

In simpler terms: a “feature” is represented by the domains and sub-domains of your context map.

Worked example — IAM

Let’s map the IAM component’s benefits and risks.

Start with benefits. How much does this feature benefit the customer? The business? For the customer, IAM offers identity protection, account security, the convenience of single sign-on. For the business, it’s largely strong security and prevention of data breaches. Both customer and business get strong benefits — squarely in the “high value” quadrant of the value map.

Now risk, largely mapped by complexity. The security landscape is extremely challenging to design and it’s a moving target requiring constant evolution. Not only is design hard, the effort to build it will remain hard. Right away IAM lands in the upper-right quadrant of the risk map.

Unless… we decide to buy a ready-made solution. If AWS Cognito offers the features we need, implementation effort drops to near zero. The IAM context moves all the way left, vastly reducing risk and solidifying the decision to leverage Cognito instead of build our own. It’s not quite in the “sweet spot” (we pay for it rather than reusing something we already have), but it’s much better.

This information can be decisive when shared with your organization. I’ve been in situations where the business has a predilection to “build our own” technology, disliking the idea of paying a third party. Couched in terms of risk versus reward, the business quickly sees the light — this is why value mapping “gives you and your team the means to take control of your work.”

Prepare

1. Make sure everyone is well-prepared. Give them a heads-up about the importance of the workshop, and enough information on how it will run. Highlight the inputs you’ll want to discuss:
   1. The effort it will take to design each feature.
   2. The effort it will take to build each feature, in general terms (remember, it’s relative, so we’re talking about how “hard” it is, not how “long it takes”).
   3. How much benefit the customer gets from the feature (not quite the same as how much they want it — customers may not “want” a login feature, but without it they can’t do anything).
   4. How strongly the feature aligns with your own business drivers (the benefit to the business).
2. A collaborative workshop environment is most effective. In person, two boards will have each of the value mapping graphs and everyone will have a stack of post-it notes. I usually write out each sub-domain on a bunch of post-it notes, sticking them to the side of each graph. If working remotely, model a similar setup virtually.
3. When it comes to effort — the entire mapping exercise is relative. You absolutely should not be talking about time, days, or number of sprints. All that matters is whether one feature is more or less effort, more or less valuable. If the team starts dwelling on time estimates, gently steer them back toward a relative conversation: “We don’t need to know how many days, just whether the IAM component is harder to build than if we pay for Cognito.”
4. Use the best tools: walls, post-it notes, and non-permanent sharpie-style pens. If you’re going remote, use something like Miro. Keep your team honest about their ubiquitous language.

Execute

1. Conducting the workshop is largely about gathering everyone’s opinion about each feature and adding the feature to your value maps.
   1. Your customer clearly gets the vote when it comes to “customer benefit,” just as the business does when it comes to business drivers. You can, of course, have clarifying conversations — it’s important everyone agrees on what a feature does and how it brings value.
   2. Think about level of design as the complexity of the service itself, how many integrations and data sources it has, the extent of internalized components. Design complexity is different from effort complexity. Level of effort should consider change versus build, maintenance burden, ease of isolation, and other factors that indicate how much the component impacts the rest of the system and how far that impact extends.
2. As the team reaches consensus, add each component to both value maps.
3. If new information comes up that changes your evaluation of a component, no problem — move it as appropriate.

After working through all components, you’ll end up with value maps that look something like this:

From this outcome there are a few clear observations:

1. The customer is chiefly motivated by having a safe, secure online banking environment, and making their online purchase.
2. The business is able to keep effort low by leveraging existing technology and minimizing custom work (most of the custom work is purely focused on the customer buying experience).
3. There are good options for licensing IAM, payment profiling, and customer relationship management functions.
4. The Wholesale Payment context offers questionable value, and might be worth revisiting to see if it could be simplified or eliminated.

Outputs

• Context value map. A visual representation that expresses the relative value of each context (domains and sub-domains on your context map). Value is mapped based on business and customer benefit.
• Context risk map. A visual representation that expresses the relative risk delivering each context carries. Risk is expressed as complexity of design, and overall effort and impact in delivery.

You’ll be able to develop better communication tools from the data points you’ve established. A unified target state architecture map conveys progress and project health, a fantastic tool for communicating across your organization and building trust.

In the next chapter, 3.2 Security & governance, we’ll make sure both security and policy are not forgotten. Security and policy “as code” are important steps to simplify long-term delivery — something many team members don’t love thinking about, but doing it now avoids long-term pain.

Next activity

• 3.2 Security & governance
• 3.3 Identify product increment