Ditch Epics and User Stories and Focus on Outcomes
FYI this was originally published on my site as part of my regular newsletter. You can read it here (no paywall)
When I’ve helped organisations become more outcome/product orientated, more often than not, I’ve moved them away from ‘epics’ and ‘user stories’ and towards things like one-pagers, opportunities, hypotheses, etc.
Why?
Simply because they’re better tools for facilitating outcome thinking and experimentation.
I’ve seen too many places get stuck in a perpetual hamster wheel arguing over what an Epic is? Epics vs Initiatives vs User Stories? Who owns what? Who prioritises what? Where do they belong? etc.
All that energy and effort wasted to semantics really. Imagine if we put even half that effort into defining our outcomes, experiments, or understanding our users?
If this is you, read on because you might be far better off ditching them altogether!
A common client of mine looks like this.
They’ve done the whole agile thing, generally they did an ‘agile transformation’ 2–5 years ago and whilst they doing great things, they have a regular cadence, small teams and are releasing often, they haven’t seen any significant change in customer outcomes and business impact.
Whilst agile will preach to inspect and adapt and follow build-measure-learn cycles, many organisations are years into their agile transformations and are still struggling to put that into practice. Any inspection or feedback loops are unstructured, yielding insight sure, but not the type of insight that’s really moving the dial.
Recognising this they realise they’re stuck in the world of outputs, and need to shift their focus towards outcomes — but how?
As many of us will attest to, one of the biggest challenge with such a shift is mindset and cultural change — something I’ve spent many years unpacking and don’t worry I’m not going to use these terms without giving you an actionable way to change them. After all that’s the intent of the post — an actionable guide to shifting your company from outputs to outcomes.
How to Change Mindsets & Culture
John Shook Ph.D., Vice President for Education and Research at the Center wrote an award winning article for MIT, called “How to Change a Culture: Lessons from NUMMI”.
In the article Shook shared his experience at NUMMI (New United Motor Manufacturing Inc., a joint venture between Toyota and GM) which were contrary to the traditional thinking when it comes to culture change.
Traditional thinking normally states that in order to change culture we must first change people’s mindsets and then the behviours will follow.
But this was not what Shook experienced at NUMMI. Instead he stated:
“What my NUMMI experience taught me that was so powerful was that the way to change culture is not to first change how people think, but instead to start by changing how people behave — what they do…The culture will change as a result.”
Culture change starts not with mindsets but with behaving differently. By changing the way we behave first, we can experience the benefits of working in a different way. Which is far more convincing when it comes to changing one’s beliefs than any form of education.
After all, as the proverb goes, “seeing is believing”.
Shook’s model very much aligned with my experience.
I’ve been a part of several transformations now and whilst there are many reasons why transformations fail, those which I would categorise as successful (and I have data to back that up as these companies value and market share increased as a result) we were far more focused on facilitating change through doing, than preaching.
These experiences have shaped my approach to change in organisations. One of my principles when I work with clients is “show, don’t tell”.
Which means that if you want to become more outcome-orientated, it all starts with working in a different way.
This is where ditching ‘epics’ and ‘user stories’ comes in.
Ditching ‘Epics’ and ‘User Stories’
As mentioned, a common client of mine are ‘agile’. They have small teams and product backlogs are flowing with epics and user stories. But for all intensive purposes they’ve found themselves in a rut — a feature factory.
Typically following the story narrative their user stories articulate the WHO-WHAT-WHY but seldomly the outcome or any way of actionably measuring it.
User Story Narrative:
As a [type of user] = WHO
I want to [some goal] = WHAT
So that [reason] = WHY
Yes ideally, as part of your story narrative you want to articulate the outcome and measurement but seldomly do I see this happen. Instead teams user stories are simply tasks nested under larger tasks (epics), under projects (initiatives) leaving little room for experimentation and pivoting.
So let’s ditch that structure — shake things up.
Move away from ‘epics’ and ‘user stories’ and instead introduce things like one-pagers, opportunities and hypotheses.
Why?
Because these tools do a far better job to provoke questions like:
- What problem am I trying to solve and/or
- What outcome am I looking to achieve?
- What am I going to try first?
- How are we going to measure success?
In my experience they also do a far better job to help shift our behaviour away from; what do we need to do? and towards asking; what are we trying to achieve? and what is the first thing we can try to get us closer to that outcome?
So to make this tangible for you:
- One Pager = What outcome(s) are we trying to achieve?
- Opportunity Statement = How might we achieve it?
- Hypotheses = What is the first thing we can try to get us closer to that outcome, and how might we measure it?
One-Pagers
Rather than articulating a large initiative, start with the outcome — What are we trying to achieve? What problem are we trying to solve and for whom?
A great way to represent this is through a one-pager.
Typically I’ll introduce one-pagers at the strategy layer in the form of a strategy on a page, but depending on the company this may or may not work. Regardless the goal is to facilitate the conversation around strategy and outcomes.
Of course if this is new to you, don’t expect fantastic one-pagers from day one. It’ll be a long journey to get them even half-decent but a well formed one-pager can act as a forcing function to prompt questions like:
- Where are we choosing to play vs not?
- What outcomes are we focusing on?
- What ‘big bets’ are we making and how will we measure success?
- What key business/customer problems are we focused on solving?
- Etc
Again leveraging a tool to shift behaviour to, over time, shift mindsets.
Note: There is also no reason why a one-pager can’t be introduced in other places. A very popular place for one-pages to appear is in the form of a canvas. You can easily bring this and the opportunity layer together in an opportunity canvas like the one below.
Opportunities
Opportunities are the next layer.
The intent here is to shift the thinking from projects to opportunities and problems.
Rather than having large initiatives or epics we want to facilitate the thinking towards to customer — what customer problems are our customers facing and are any of them an opportunity for us to solve which will help us achieve our chosen outcome?
I plan to have a whole post on Problem Framing and Opportunity statements in the future (so watch this space) but fundamentally I want to use a tool/framing to go deeper than just the “So that” statement in the story narrative.
A common format I use here is to express user problems as opportunities are through ‘How Might We’ (HMW) statements.
For example, if users were having trouble remembering their passwords we might create the following opportunity statement: “How might we make passwords a thing of the past?”
Taking this to the next level would be using something like an Opportunity canvas which begins to add on additional information like the problem, supporting data, users and expected benefits.
Hopefully you can see how this facilitates deeper thought around outcomes, customers and experimentation a lot more than the story narrative or a blank user story.
Don’t discard structure, they’re not inherently bad. And when it comes to facilitating change, I’ve found that the right structure and mental lattices are powerful tool to shift the way we think/work.
Hypotheses
The piece I want to take you through are hypotheses.
Also known as Hypothesis Drive Development, this approach is about shifting our work from delivering on a set of requirements towards being an experiment.
“When viewing work as an experiment, the traditional story framework is insufficient. As in our high school science experiment, we need to define the steps we will take to achieve the desired outcome. We then need to state the specific indicators (or signals) we expect to observe that provide evidence that our hypothesis is valid.” — Barry O’Reilly
A typical hypothesis statement looks like the following:
We believe that [doing something]
For [type of user]
Will achieve [some kind of outcome]
We know we have succeeded when we see [this measurable impact]
Quickly comparing the user story narrative to a hypothesis you will see that they look similar but there are some subtle, but important differences.
Yes, both articulate WHO, WHAT and WHY, however subtle, going from “I want” to “we believe” shifts from certainty to uncertainty. In other words, “I want” can come across as a done deal, they want it and if we deliver it we WILL get the impact we expect. Whereas “We believe” is uncertain, we BELIEVE it’s what they want and will give us the impact but we’re not 100% sure — we might be wrong — so we will test and learn.
And finally there’s also: how will we know?
This is something I almost never see on epics and user stories — metrics!
- How will we measure progress and success?
- How will we know this has been a success or whether we need to pivot?
Again facilitating a different way of working and thinking.
Conclusion
Of course, you can do all those within ‘epics’ and ‘user stories’, I’m by no means saying you can’t — after all a user story at it’s core is a placeholder for a conversation — but I’ve found these tools, these kinds of framing can be far more effective at facilitating outcome-orientated thinking than the ‘initiatives’, ‘epics’ and ‘user stories’ structure.
Further, depending on your company and structure such terms might carry baggage. You might have already pinned yourself into a corner saying things like an Epic must be linked to an Initiative. In these cases I’ve found that simply moving away from those terms rather than trying to reinvent them can be more effective. Avoid the baggage and start fresh.
And for those who are seeking change in their organisation, remember Shook’s experience at NUMMI. We can talk about the importance of having things like metrics and measuring impact until people ‘get it’ or we can create a forcing function (e.g. through hypotheses) to make people begin to work in this new way and show them the benefits.
I know which I’d choose.
