Yesterday I wrote a silly song parody about agile backlogs. Today I'm going to get serious, a bit vulnerable and a bit passionate about why I build software.

The products and services that we build are designed to achieve outcomes. These outcomes - behavioural changes in our users, the acquisition or development of skills, empowering a new capability - carry business value. When we say we are in the business of "delivering business value", we mean that we do this by achieving these outcomes.

Agile development, as I understand it, places a large focus on outcomes. But we often fall into the trap of thinking about our output. Of course, we need output to achieve outcomes. However, too big of a focus on the management of output, at the expense of losing sight of the outcomes, leaves teams thinking that maybe this Agile thing isn't giving them what was promised.

Agile frameworks make it easy to be output focused. Let's pick on Scrum as a lingua franca. You start with a backlog, engage in intense and continual processes to groom this backlog, alongside the estimation of work and the capacity planning of how much can be done in an iteration. It's so easy for traditional project management to be ported onto this kind of framework. The glorified accountancy can even surface and worsen micro-management capabilities, with obsession on burn-down and perfect estimation.

Scrum of course provides the way out with sprint goals, but these themselves are difficult to use effectively if the way your work is arranged in an output-focused way. Work such as "change the design of this button", "reword this piece of copy", "make the header banner blue". Your default sprint goal is "do the work in the sprint", which is not helpful and entirely output-driven.

For clarity, I'm not saying I don't value this output-driven stuff, I just value the outcome-driven stuff more. And I don't mean to bash on Scrum, it's simply a convenient jumping-on point.

So perhaps it's time to detail how we can focus on outcomes rather than outputs by way of a use case.

An Example: Changing the question text of a web form

Let's say that we work on a product and in order to buy that product, the user needs to answer a series of a questions. We present these on a web form as part of the purchasing workflow. Our support operatives are receiving a lot of queries from confused customers, because the wording of the questions is confusing. We're losing customers and the ones we're retaining aren't that happy either. We agree that something needs to be done.

The output-driven approach is to "change the text of question". We can ask a designer to re-word the question - they may even run a small focus group - and then a ticket with the exact wording to change the copy on the web page is raised on the team's backlog. Fantastic. Job done. The output of a text change is delivered. Next project, please.

But how do you know that you've changed anything for the better? You can only answer this question by focusing on the outcome.

I'd propose the outcome that we're trying to achieve is that "customers should not be confused when purchasing our product".

That is your user story. That is the outcome that you wish to achieve - not "change the text of question to ...".

The exact text from the focus group? That's our experiment - it's how we think we'll achieve the outcome. Now we can take a stab at answering how we can measure the outcome. Putting the text change into production isn't enough. So we look elsewhere. Are support queries on this issue dropping? Are signups increasing? Does our analytics software identify users spending less time answering this question? Could we survey customers? It could even be possible to set the outcome as the sprint goal, experiment with alternatives through A/B testing, measure some criteria and present these at sprint review alongside data that demonstrates business value.

Why does this matter?

About a decade ago, a close family member suffered a brain haemorrhage. Don't worry, they're fine. When leaving hospital, they were left with no job and a huge cognitive task of having to re-learn basic things. Memory, reading comprehension, concentration - they all took a hit. Filling out a benefits form to claim the support they were entitled to was such a complicated task it drove them to tears. Without delving too much into the politics, in this case the outcome the UK Government were aiming to achieve was not aligned with the outcome of the users of their service. The questions were deliberately set out to confound, deter and disrupt the ability for people to claim their entitlements. This was ideologically-driven and financially incentivised.

When we design our products and services, we hold an immense power over people's livelihoods and wellbeing. The question text example seems superficially noddy, but when you realise that even simple things like this can have a profound impact on people's lives in times of need, the true power of aligning your work to outcomes becomes apparent. Indeed, I'd argue it's a responsibility. Work thrown over the wall as "delivered", without answering the question "how has this made things better" is not done. This obsessive focus on user outcomes is what gives our work meaning, what provides teams with a purpose and ultimately why we do this.