BlogApril 18, 2015by Cesario Ramos

Where is the value in Agile?

I was coaching a number of teams and their Sprint Reviews were boring status meetings and few stakeholders attended. I see this pattern often at companies and the reason for poor stakeholder attendance is that the discussion about added value happens in other meetings. In this post I want to share a little model based on Impact Mapping and Value Requirements[2] I use to improve team’s focus on value.


Delivering value has always been the priority of agile teams. One of the principles of the agile manifesto emphasises this focus:

“Our highest priority is to satisfy the customerthrough early and continuous deliveryof valuable software”.

This principle sets the focus on delivering value to customers. Value from the customer’s point of view is the benefit they think they will get from using a product or a service. The focus on customer value has led some to measure and track value delivered with user stories. Measuring customer value with value points only goes so far.


User stories are great for many reasons, but a user story is focused on customer value as you can see in the quote below.

“A user story describes functionality that will be valuable to either a user or purchaser of a system or software”

source: User Stories Applied, Mike Cohn, 2004 

If your Sprint Reviews have a lack of stakeholders, maybe it is because you are having the wrong discussions. If your Sprint Review is a demo and only discusses how many user stories were delivered you might have found the problem. The discussion at the Sprint Review should be about “how much value we created?” and “what is preventing us from shipping today?”. It should address the value of all stakeholders not just the customer’s value.

A Product Owner may have the following value questions:

  • Are we solving the right problem?
  • Are we building the right solution for that problem?
  • Are customers willing to pay for it?
  • Can I make money developing it?

For a customer, value questions could be:

  • Does it solve a problem I know I have in a better way then my current solution?
  • Does it solve a problem that I didn’t know I had?
  • Am I willing to use it?
  • Am I willing to pay for it?

A stakeholder could be interested in:

  • Am I making the right investment?
  • Am I reaching my stakeholder objectives?

Answering all these questions by measuring value points on user stories can be challenging. It can work if you are developing a mobile-app, but it becomes harder when you are developing an internal system for supporting a new business process.


In order to satisfy different stakeholders and steer development you need a more fine-grained definition of value and progress. Different stakeholders seek different values There are various levels of outcomes and outputs; I like to discriminate between three levels:

  • The team level
  • The product level
  • The business level.

Value at the team level

I like to see outputs at the team level as potential solutions a.k.a. product increments. The outcomes at the team level are its potential impact on product quality. These are product qualities like usability, costs, maintainability, performance and so on.

Value at the product level

At the product level the quality of the product are merely outputs of the team. Outcomes at the product level are customer behaviour and stakeholder values or happy customers and happy stakeholders.

Value at the business level

At the business level, the happy customers and happy stakeholders are merely outputs to the product. The outcome at the business level would be increased revenue or increased employee satisfaction for example.

In the graphic below you see the three levels and their relationship on outputs and outcomes.

The good part of all of this is that you can measure and receive feedback at these three levels and are therefore able to learn more from your development experiments.


Let’s say you are an airline company and your business objective is to make more money by increasing ticket sales in the current customer base. The expected outcome at the business level is a 20% increase in revenue and of course happy customers and stakeholders. It is decided that one way to contribute to the 20% increase in revenue, is to increase in the sales under frequent flyers from 10M to 11M. At the business level, we end up with an expected outcome of 20% increase in revenue under existing customers. The expected output is a 1M increase in frequent flyer tickets sales.

At the product level the 1M increase in frequent flyer sales is one of the outcomes. Another outcome is happy customers, in this case frequent flyers. In order to have happy frequent flyers it is decided to increase the ease of rebooking. So, at the product level we have as outcome a 1M increase in frequent flyer sales and as output we have an increase in ease of rebooking.

Finally we arrive at the team level. The outcome of delivering an increment is to increase the easy of rebooking. The product quality we are talking about here is Usability. The output is the potential solution ‘Auto-rebooking’ functionality to increase the ease of rebooking.

You now have linked the experiment of developing ‘auto rebooking’ to the expected business outcome of 20% increase in revenue. At the Scrum Team level it is absolutely clear why we are doing the experiment we do. At the Sprint Review you can discuss how much product value you added by measuring Usability. You can also measure, after releasing, if an increase in Usability results in an increase of frequent flyer sales and if the business objective is significantly impacted. You can now design Sprint Goals that add value for all stakeholders and measure progress towards them.