We do what we do in order to change the world. This is especially true for organisations: from independent consultants to global super powers. So why do so many of us forget this and end up focussing on the wrong things for too long?
In this article, I’ll introduce you to ‘User Stories’ in real-life. This Agile story telling technique will encourage you to focus on outcomes and purpose (valuable change), rather than features and churn (the red herring). And you can start it straight away.
Purpose, outcomes, values and functions
I am goal driven. I’m also very lazy. And I love trying new things. In the wrong hands (my own!) this has led to many different stories.
For example:
- completing the Great South run and smashing my target pace by minutes
- indulging in watching the whole of series 1 ‘The Wire’ in a day
- beginning various projects that didn’t make it past the first hot flush of novelty
- practicing yoga every day when I’m at home, and most of the time when I’m not
My daily yoga practice is driven by purpose: I want the outcome of remaining physically active, flexible and healthy, so I can realise the value of keeping doing the things that bring me joy in my life for as long as possible.
The function of serving this purpose is to actually practice yoga.
Let’s try this out for size in an organisational context.
The purpose of a learning designer is to change the way people behave in the world, aiming for a particular set of valuable outcomes, and is not simply to design learning. Producing learning materials, instructional design, facilitation and scaffolded resources, as well as the learning design itself, are all simply functions of this purpose.
Describing value through User Stories
In Agile, we document requirements for specific types of people in short, regular, value-based stories. ‘User Stories’ focus on outcomes and value, rather than function. We leave the function (how) at the door and come back to it later.
With an Agile mindset, our preference is for collaboration over contractual agreement. We especially don’t want to create a weighty set of design documentation, which could be misunderstood and inhibit change as our understanding of realising the value develops.
So, user stories are kept discreet, in order to prompt focussed discussion between stakeholders and producers, with an aim of increasing shared understanding of the value to the user of the outcome.
Structure of a User Story
As [a user], I want to [reach an outcome], so that I can [realise value].
Let’s use my yoga practice example.
As a man approaching a significant birthday, I want to remain active, flexible and healthy, so I can keep doing the things that bring me joy in my life for as long as possible.
Here we’re focussing on a specific user (me!), a defined and testable outcome, and the value to the user that the outcome will deliver. We haven’t mentioned the function or ‘how’ in the story at all. We’ll come back to that later.
Here’s an example of a badly formed user story.
As a man approaching a significant birthday, I want to practice yoga regularly, so I remain active, flexible and healthy.
In this example, the function and outcome have been described but we’ve skipped mentioning why the outcome is valuable. We’ve decided that practicing yoga is the way to deliver this outcome
And we’re left making assumptions about why this particular user might find value in ‘remaining active, flexible and healthy’. Maybe it’s because I’m a champion limbo dancer with a big competition coming up next week. Is yoga the best preparation for a limbo dancing competition. I can tell you, it is not!
Let’s try this with a Learning Design example.
As a Learning Designer, I want managers to tell stories on social media.
If we break this story down we can see that:
- We’ve picked the wrong user to focus on. The manager should be the subject of our story. In this case we’re not considering how the Learning Designer can attain value.
- Instead of our ‘want to’ relating to an outcome, we’ve jumped to a function. In effect, we’ve now decided/designed how we will satisfy the requirement and so skipped the chance to keep an open mind to solutions.
- We’ve totally skipped the ‘so I’ part of the story, and therefore not considered the value that would be delivered. This makes it difficult to prioritise the story over others, and to know what effort is worth investing.
So let’s write a better story.
As a manager, I want to influence decision makers in my organisation, so I can achieve my goals more quickly.
This time we have a clearly defined user, and a testable outcome. The value is still vague though. What specific goals does the manager want to achieve as part of this user story? I’ll leave you to ponder that.
Okay, I think I get it. What happens now?
User Stories are often used in Lean and Agile teams, but not exclusively. If you’re not using Scrum or Kanban, user stories can still be a great way to capture and prioritise Agile requirements.
Review and refine
Once you have a collection of user stories, you can begin to prioritise and refine them. This ideally happens within your team, where each story is discussed, questioned and improved.
At this stage, it’s not unusual for big stories to be broken down in to several smaller ones. This is a good thing – it demonstrates that you’re improving your understanding of the users, outcomes and values. Make a note of the new stories and add them to the collection. Treat them as independent user stories from this point.
You might also discover a story that you initially decided had a great deal of value, which ends up being canned after discussion with your team. Don’t feel bad about this. You might have discovered this three months down the line. You just saved three months of wasted effort!
Teams are now able to reorganise and prioritise user stories on outcome rather than function, so more valuable stories can be identified and tackled first. This is often done using stickies on a board or table, or on a cloud-based board, like Trello.
Tackling a User Story
You’ve reviewed and prioritised all your user stories with your team. It’s now time to get things done.
Pick the top story from your collection, and decide with your team how you could best deliver the outcome. Different methodologies suggest different approaches to agreeing this. This article isn’t a full guide to Agile Practices, but it makes sense to test the assumption you made in the user story with the minimum investment.
Do this with real users if you can, and concentrate on using as little effort as possible to complete the test; at this point you don’t have evidence that the story is valid or valuable, and you want to minimise any waste your time.
Iterate
If you got the result you hoped for, then you have satisfied the user story, and you can pick another from the collection. You might write more user stories that build on the first success. Review, reprioritise, then pick the most valuable story in the collection and go again.
And if you didn’t get the result you wanted then you’ve learned quickly. Be grateful for failing fast. Now pick yourself up and choose another story from the collection (it could be the same one), and go again.
Over to you
User Stories are a great way to keep a team focussed on delivering outcomes and value, and of building a shared understanding. They help you to avoid working on the wrong things for long, especially if revisited regularly.
Next time you want to introduce or improve something with your team, try out user stories. I’d love to hear how you get on, and it might be your first step to a more Agile mindset.
Also published on Medium.
