Thinking for a Change

Business Value

Business Value is one of those terms that’s used often but rarely defined or explained.

I use “Business Value” like “Story Points”: a unit-less, relative, leading indicator of the value that will be generated when we’ve delivered the piece of the system that we’re estimating. When we’ve got this nice one-dimensional Business Value and Cost, we can quickly create a plan in two steps:

1. Maximise delivered value by prioritising by Value/Cost
2. Adjust the ordering to take various constraints into account: dependencies, promises that need to be honoured, risks that must be explored… This re-ordering necessarily decreases the amount of value that’s delivered, so we try to avoid dependencies, premature promises and unexplored risks that will force us to reduce value.

Estimating Business Value

But how does one estimate this mythical “Business Value”? There are a number of techniques I’ve used successfully:

• Sort the items by value, from low to high. Don’t allow items to be given the same value, otherwise everything will end up with a high value (otherwise known as “MoSCoW Hell”). Start with the lowest value items and give them a base value, ‘100’ for example. Give all higher-valued items a relative estimate. This is exactly the same technique we use in the XP Game to teach how to estimate cost in Story Points.
• All new items are estimated relatively to previously implemented items.
• Build a set of representative items to estimate relatively against.
• Don’t make your items too small. I intentionally speak of ‘items’ here, not User Stories. It’s often easier to estimate the value of a larger chunk of functionality like a Minimal Marketable Feature (MMF). When you split the item in smaller parts, divide the Business Value among them or keep the Business Value at the higher level item so that you only earn the Business Value when you implement the whole item.
• Don’t take Business Value too seriously, it’s just a prioritisation tool.

So, we work with Business Value like with Story Points. On some projects we display this in a “burn down/up chart”. Cost burns down, while value goes up. I find this useful to break people’s (well, mostly managers’) instinctive idea that value is just the inverse of cost. Value and Cost are independent variables! It’s not because we spent 50% of the effort that we delivered 50% of the value.

The big difference between Business Value and Story Points is that I haven’t come across any company that calculated its “Business Velocity”. Velocity is measured to tie the unitless Story Points back to something tangible like man days. Velocity calibrates our story points estimates and improves its accuracy as a leading indicator of cost. Business Velocity is the same concept: if we delivered something “worth” 1000 Business Value points, how much did we actually get in something we value, like money? I have hopes that one team will actually calibrate their Business Value as that’s the business they’re in: modeling and calibrating to predict.

Improvement: build a Business Value Model

The simple process described above works well when the situation is relatively clear: one customer, one or a few sources of value that are easily identified (e.g. you sell custom software development). What if the situation is a bit more complicated? What if there are more stakeholders, each with their own definition of value? What if you value more than just money from project sales? Where does that prioritisation come from?

You build a “Business Value Model”. You make a list of all the things you value, which could include:

• Money you get paid in the short term
• Money you could get paid in the future (which is of course less valuable than money in the short term)
• The happiness of your customer
• The happiness in your company
• New information that can be obtained
• More visibility in the market
• Increased reputation, prestige of the customer
• Other sources of income
• ….

You also list the things that you fear, that would decrease the value of what you build:

• Technical risk
• Market risk
• Competition
• ….

Select the parameters that are most important for you. Give each parameter a weight. For a start, each parameter could have the same weight. Now you can evaluate each of your projects (and maybe MMFs) against the Business Value Model to see which ones are most valuable.

The value of the Business Value Model lies not so much in the model itself but in the conversations to create and use the model. These conversations might uncover some “unspeakable” facts. For example, there might be an unspoken hierarchy among customers: those customers who have the CEO’s phone number get higher priority.

Everybody uses a Business Value Model to prioritise. You can choose to make it public or keep it unmentionable. In the companies with a Business Value Model it’s easy to see and explain why the high priority projects are high priority. Everyone knows what value they’re adding.

Playing a few rounds of the Business Value Game is a good intro to start this conversation.

The techniques above help, but estimating Business Value isn’t easy. Getting someone to estimate is like getting blood out of a stone. Doing it at or before every planning meeting takes time. What if we stopped estimating Business Value of projects, MMFs and user stories, yet retained our ability to prioritise and evaluate value delivered?

Stop estimating implementation Business Value

Project have stakeholders. Stakeholders have goals. Now, don’t ask stakeholders “What’s the value of this piece of functionality?” Ask the stakeholders: “What’s the value of achieving that goal?” What’s the value in terms of the parameters of your Business Value Model: how much new income will we generate, how much money will we save, what important information will we have gained, how will this improve our reputation and brand? We can start asking why this stakeholder needs to achieve that goal.

Now we’ve moved the conversation away from implementation issues and are firmly in business-issues land. We can value goals and their sub-goals and start prioritising them early, before we start thinking about implementation. We start the conversation about value before we can even start to talk about cost.

We can derive the required features from the goals. The business value of the features is derived from the value that’s generated when the goal is reached.

Start writing User Stories differently

I’ve found it a lot easier to start with Business Value and to derive User Stories than to create the User Stories and then add Business Value, as the conventional advice goes.

This is Agile (Business) Analysis. Continuously:

• Create a clear vision
• Identify the stakeholders
• Identify their goals
• Determine the value of the goals
• Prioritise the goals according to value
• Determine the capabilities needed to achieve the most important goals and to realise their value
• “Pull” information about the needs to estimate cost, prioritise and plan
• Let the implementers pull information about the needed capabilities
• Track value delivered.
• Improve the process and the model.

To reflect this process we use a different User Story format:

TO <achieve a goal>
AS A <stakeholder>
I NEED <a capability>

Liz Keogh described a similar User Story format in her blog entry about  “Feature Injection”. We start with the goal and derive the need from that.

There is one difference: we don’t use “I WANT”, but “I NEED”. When we derive capabilities from goals, we only consider those that are really needed because we use a “pull” perspective, not a “push” perspective.

Bart the BA had just joined the large organisation where I was coaching. He asked me to help do the business and functional analysis of one of our largest projects. He had several years of experience analysing large systems. I tried to teach him how to do Agile analysis, convince him that he didn’t need every last detail before development started.

I failed.

The result was a thick document that described the processes and business rules in excruciating detail.

That won’t work!

There are a few ideas in Agile methods that are almost always met with incredulity and disbelief. The reaction ranges from a puzzled “Hmmm… That’s an interesting/unusual idea” to “Are you crazy? That’ll never work!”. What’s so hard to believe?

• Project managers can’t believe their project will run more smoothly with less detailed planning upfront and detailed controls on what the team is working on.
• Architects and designers can’t believe the application’s architecture will be more appropriate and easier to understand and change with less detailed design up front.
• Analysts can’t believe the team will understand what the customer needs with less detailed analysis up front.

The Waterfall dies hard

Wasn’t the Waterfall dead and buried? Why do so many people still think that doing more work and more detailed work up front will improve our projects?

It’s only natural.

Projects are scary. There are so many variables. So much could go wrong. Our instinctive reaction to deal with these fears is to nail more down, research in more detail, take decisions as soon as possible and reduce the number of variables and options. Which is exactly what we don’t want to do.

We want our coachees to accept the paradox that to control our projects better, we need to relax our control. If we want to take better decisions, we should take them as late as possible, when we have the most information. Instead of closing down options early, we should instead keep our options open to deal with an uncertain future.

Techniques like “Real Options” replace premature commitments with decisions about the conditions under which we will need to commit. Meanwhile, we can gather information and find more options.

Techniques like “Critical Chain” allow us to deal with the uncertainty of dependencies and estimates by giving us the means to deal with the planning risks as they arise.

Techniques like “Dimensional Planning” allow us to maximise value/effort by giving us the means to take decisions about depth of implementation as we get feedback from the customer.

An investment in code and design quality, automated tests and team skill keeps the system malleable so that we can deal with unexpected requests economically.

Leap of Faith

We must always be aware that to change the way people have worked, mostly successfully, for years requires a huge leap of faith from our coachees. When they first start changing the way they work, their performance will go down, they will feel uncomfortable and they will feel lost. They will want to go back to their familiar way of working.

We need to support them with practical assistance and encouragement, help them through the difficult moments and show them new techniques. We need to acknowledge their fear and address the fear:

• Yes, emerging design will rapidly degenerate unless we all have the discipline and skills to apply good design principles, practice test-driven design, continuously refactor and continuously improve teamwork. How can we strengthen the necessary practices and skills? How can we trust the team to do a good design job?
• Yes, just-in-time requirements will fail unless we have close collaboration and communication with customer representatives. How can we ensure that we will get quality information from them? How can we trust the customer representatives to do a good job of describing and validating user’s needs?
• Yes, “rolling wave” planning will fail unless we receive good credible and reliable information about estimates and status from the team. How can we ensure that the team has the necessary skills and transparency to provide the project manager with the right information at the right time? How can we ensure that the project manager communicates clearly about goals and constraints? How can project manager and team trust each other?

Bart noticed that the developers didn’t really read the requirements document. The developers wanted User Stories, so I helped him to translate the requirements into stories. Whenever the developers had questions they came to Bart. Through his work on the analysis he knew pretty well what the system was supposed to do. When he didn’t know, he knew who to ask.

Gradually, Bart became this team’s product owner. Some expert users were added to the product owner team. For the next release, the product owner team started with stories and elaborated the detailed requirements just before the developers needed them. For the first time in years, users were happy to receive new releases of this application.

What’s common in all of these concerns?

• Relinquishing control, or at least the illusion of control.
• Mutual trust.

The best way to break out of the vicious cycle of distrust and increasing control is to inject some trust into the system. Increase trust by the project manager by helping the team to communicate transparently about progress, for example with a burndown chart. Increase trust in the team’s estimates by using historic velocity. Increase trust about requirements by involving users, analysts, testers and developers in the definition of user stories and acceptance tests. Increase trust by showing the working and growing system regularly.

We, as coaches, are sources of trust. We’ve done this before. We’ve done this successfully before. We’ve also failed; but we’ve learned from the failures. An investment in coaching is an investment in trust.

Small Steps

A small step is a lot less scary than a huge leap. Therefore, we try to help our coachees to change gradually. First try a little less upfront work on a small project. Gradually decrease the amount of control; gradually increase the number of projects where the techniques are used; gradually increase the number of people who change their way of working. Small successes increase trust.

But the idea that you can get to your goal in small, incremental steps is another idea that many find hard to swallow.

The alternative is to take the “just do it” route: the team decides they will apply these changes on the next project and see what happens. They trust that the coach will act as their safety net. They trust that the coach will catch them if they fall.