Customer Outcomes and Backlogs

Updated December 2022 following real-world testing of concepts

This is part three of Why Agile Fails. Find part 2 here >>>>

One of the key aspects of an Agile practice is the backlog. A delivery team works from the top of the backlog, collectively focused on the most valuable feature. Value is calculated from the benefits to the customer and to the company as agreed with the business team. In many companies the backlogs become disorganised and difficult to process for people outside of the delivery team. This often leads to non-productive manual work to tie the delivery team’s output to the business and financial structures of the company. This leads to the incorrect view that Agile means throwing project management, and delivery confidence, out of the window.

This blog first defines an outcome and how outcomes fit into a backlog. It will then talk through the integration of outcomes to the needs of the other departments within a company. This blog will hopefully provide the readers with simple ways to get control back over Agile delivery.

Why outcomes are important

Over the last few years many companies have called out the importance of being customer-centric in the delivery of new experiences. In practical terms, customer-centricity is the practice of starting with the desired customer outcome, and work backward into the company refining the user journeys, business processes, technology and human touch points. In taking such an approach, one can be assured that all the changes are tuned to meet the stated outcome. Outcomes are the language of delivery between Product Owners, Engineers and the Business Teams.

By taking an outcome-focused approach to backlogs, a delivery team can:

1. Improve self-service visibility of the work being performed by the delivery team to external stakeholders, internal management and team members
2. Ensure each delivery team has a well-defined set of deliverables and value to the customer
3. Ensure that the epics within the backlog are appropriately sized to enable a continuous train of delivery of value to the customer
4. Automatically report on progress across the teams without resorting to manual activity
5. Enables a culture of experimentation by making outcomes experiment-able
6. Track dependencies between the outcomes to the customer and work on the backend services

What is an Outcome?

An outcome is something that is meaningful to a customer, has a concrete content and offers business value. An outcome is written to share business goals across both the business and delivery teams, therefore it must be written in the language of the business. There are a number of ways to express an outcome, but they have a common set of components:

• a mandatory customer
  the customer is the beneficiary from the outcome. Most companies have many different categorisations of ‘our customer’. There might be an agreed set of semi-fictional archetypes called personas that segment the audience, a customer might be categorized by channel (shop, mobile, phone, etc), in some cases a customer might be a user of a system such as a fellow employee, a supplier or a business partner. How we define the customer strongly affects the way we communicate and interact with them.
• a mandatory object of control or a feature
  this component defines what it is the customer is doing when interacting with the company. It scopes the outcome down to a particular thing that is important to the customer.
  Objects of Control are existing ways of working that the customer is already familiar with, either on your product or in common usage within the environment A good object of control can be said to a customer and will be understood without any explanation. An object of control is useful when there is a distinct control path through which the customer can interact with the system, and with which we are improving the experience.
  A feature is more general and is better used when bringing fresh innovation to the product. In the case of a feature, the way the customer interacts with the system isn’t well defined.
• a mandatory customer benefit
  the customer benefit is what the customer is going to get out of the outcome. In some cases this can be expressed as a metric. A metric defines how a customer is going to measure the success of the outcome. The metric is the dimensional unit and a modifier, e.g. reduced time, lower cost, more privacy, quicker purchase. It is not specific value, e.g 5 seconds. This approach ensures that the outcome is stable over time and not a transitory goal.
• a mandatory business benefit
  outcomes are important to the customer, but ultimately they need to drive value back into the company. Every organisation needs to have clear benefits for any work. The benefit is expressed in a measurable way. If you can’t directly measure the benefit of some work, do not do the work. It is not unusual for delivery teams to first work on a baseline metric before starting the actual feature development.
• an optional contextual clarifier.
  This is any other information that make the outcome easier to understand and establishes constraints.

There are a number of forms to express outcomes. The two suggested here are ‘experimental’ and ‘directive’. The first example below is the experimental form. In this form a hypothesis is established that a user will gain some benefit from a given outcome. This is known as ‘formulating a problem statement’. In this form specific metrics are not called out, rather the outcome is a way to direct a set of experiments to establish if the hypothesis is true, and if so, the best solution.

With the directive outcome, the change is a lot more defined. For example, if regulatory requirements are to be met or if the behaviour of the customer is better understood. In this outcome the metric can be defined along with the thing the customer is controlling.

Using outcomes for experimentation

One of the big advancements in the past few years has been the increase in experimentation. As our customers get more sophisticated, as our products gain new facets and as data science gives greater insight, we are more and more driven to putting live different experiences to see which chimes best with our users. Experimentation is also pushing into the backend systems, opening up the possibility to experiment in business processes.

Any experiment starts with establishment of a hypothesis and an unambiguous method by which one can measure the response. This works very well with outcomes. In addition the team should consider using an Experimentation framework as a guided way to create successful experiments. Combining experimentation into the story creation also revolutionises the was a team can identify, try, support and kill experiments.

Experimentation is a subject of a future blog.

Using outcomes on the backlog

A major driver for failure in planning is the matching of a high level initiatives to an Agile epic. Projects are always too far away from the actual work to make them useful for planning purposes. Initiatives belong to the Senior Management Team as they fulfil the delivery of the strategy. Initiatives are implemented through projects. Projects are the language of middle management. Neither initiatives nor projects can be implemented as they express an abstract concept. They lack concrete detail.

Breaking down a project into concrete outcomes is the role of Product Management. This is where the company can start to talk about actual experiences and benefits for the customer. It is at this point, before a penny has ben spent in technology, the company has a clear idea of what will be included in the first release and subsequent improvements. The product team can start to build up the list of hypotheses that will be tested as part of the ongoing process.

The precise nature of an outcome forces a short time-box for development and delivery of the epic, ideally to less than a month. As the team is now thinking about outcomes, then the backlog becomes a priorities list of valuable change towards the customer. To make organisation easier, the epic is simply a collection of outcomes. An epic may simply be equated to a release, or it might gather together a number of outcomes that are logically part of the same customer journey.

At this point anyone with the company can look at the backlog and understand what the team is planning to deliver and how the value is to be measured in terms that are relatable and non-technical.

This approach also drives a significant change in how we think of backlogs. A backlog contains epics associated with a project. This moves away from a team-orientated backlog structure which requires lots of dependency management and replaces it with a structure that is organised around overall customer value. This is central to outcome-based delivery because a product isn’t delivered until the first customer buys it — it isn’t just about whether some code is ready or not.

An outcome decomposes into a number of ‘slices’ of functionality that the customer may do within the context of the outcome. A slice of functionality is a user story. A story takes a path through the user experience. This is often done using both a simple sentence as well as more rigorous structured language to write tests. The breakdown of stories and tasks are covered in my ‘Why Agile fails, and how stories make things better’ blog.

Keeping projects simple

At any one moment a company may have several projects, strategic initiatives, themes and short term targets in flight. There may be a number of delivery teams working on these goals. It isn’t unusual to find these teams spread over multiple sites around the world. There are a number of Agile scaling frameworks such as SAFe and LeSS that claim that they can help manage the complexity. These frameworks, in my experience, are more akin to ‘Project Manager Revenge’ in that they try to preserve and enhance complexity to validate the need for big command and control structures. They turn the delivery team into a tool to be wielded rather than being the owners of their domain.

In many cases, projects are complex because they are not structured as delivering value to a customer. They’re often named after a feature, ‘Parcel Tracking’, or some technology, ‘New CRM’. This is because projects usually start with a request for money, and we all want a bright, new shiny something to point at after we have spent money. In addition, if we are being honest, the decision makers often have little to no idea about what is actually going on in a company, so the project needs to be dumbed down for easy comprehension. These are real-world challenges that need to be embraced if Agile planning is to be successful.

Luckily, using outcomes all the way up through the Investment Panels and to the Board works surprisingly well.

Planning with backlogs

At this point we now have Outcomes boxed to no more than a month, and User Stories as no more than a few days’ work. Both Outcomes and stories are non-technical. Outcomes are owned by the product team, and user stories by the busine analytics team. A User Story now breaks down into small technical tasks. Due to the nature of a story being a single path through the user experience, the level of complexity and interdependence between teams is much reduced. Planning now become simply a case of adding up the stories. As the stories are small, there is also the opportunity to practice Continuous Deployment, delivering value to the customer every week.

A technical task is something that the development engineer will do in order to deliver on the story and outcome. Tasks may be to develop some code, to set some configuration, to create some infrastructure, to update some database, to improve a dashboard, or any other activity that falls into engineering.

Using Story Points with Outcome-Based Epics

Story points are set at the User Story level. While stories are generally encourage to be small, there are many situations where a story can contain a lot of technical complexity. Stories that have a high level of complexity can be an indicator for further breakdown into smaller stories. Story points do not map to time, they define relative complexity between stories and to support future performance predictions.

Outcomes and Software Improvement

A core principle of developing software is that work is only done if there is a customer outcome. The logic is very simple, if we are spending money developing new software, then we should prioritise the software that deliver the user experiences that will increase our revenue the most. Therefore any improvements in our software need to be done while delivering an outcome. To do so needs the engineers to take responsibility for the software and be prepared to have backbone when planning work. Luckily, the frequent delivery of outcomes from the teams increases confidence in the team. Engineers should not be asking for projects to improve their software, they do it task by task as part of User Stories. This may add a few days here and there, but that is a lot better than having to ask for money to rewrite crusty old legacy systems.

Next is how to write stories for back office systems, follow here >>>>