Death by User Stories

Hi, I’m Jenny – I’ve been doing a lot of
thinking recently about user stories and I’ve been wondering…. 1

Are user stories actually helpful? Or are they doing
us more harm than good? Have we wandered away from their intended use? Maybe we’ve wandered so far away, that we’re now in the user story badlands, where the dangerous user stories live. 2

Let me paint a picture of the badlands;
In the user story badlands you feel lost and overwhelmed. You don’t know how you got here and you can’t ﬁnd your way out. You don’t know what you’re doing, you don’t have any documentaJon to turn to, and your backlog is so monolithic you don’t even believe it anymore. You’re scared. User stories are dangerous. But how do you protect yourself? Well the only way to avoid a slow and painful death is by staying on the safe path to value. In this talk I’m going to introduce the OOPSI technique, which will help you navigate the path to value in the shortest possible Jmeframe and stay away from the badlands. You may even be able to avoid user stories altogether. OOOOOooh (shhhhhhhhhhh) don’t tell anyone I said that 3

1 They’re like a virus. Virus’ exist for
one purpose – to reproduce. As you start examining them, they keep on growing and dividing unJl you are completely consumed by them. You start ‘user story spliVng’. 4

What you thought was a small user story grows and
grows unJl you can no longer ﬁt it in your delivery iteraJon. In the user story badlands scope is creepy. But the cunning thing about the creeping scope is that it isn’t actually creeping at all. It was always there, lurking in the dark – you just hadn’t discovered it yet. You think that by wriJng something on a small post-‐it note you can pretend it’s not complicated. It’s ﬁne as long as you don’t look at it for any length of Jme, that’s when the creeping and mulJplying starts. 5

From a distance they all look the same.
User stories are disembodied and autonomous. Once you’re surrounded you become disorientated and lost, you can’t see the big picture and you don’t know where to turn. You don’t know what level of detail they are just by looking at them. An Epic looks the same as a story. A detailed story looks the same as a high level story. 6

How can you tell from looking at them, the point
at which they turn from a requirement into something that guides our development? When does the thinking happen? It used to be easier to know this in the waterfall days. You had a requirements document and then speciﬁcaJon and design documents, and this process of analysis and synthesis happened in between. It’s hard to support this process with post-‐it notes that all look the same. 7

Maybe it’s the acceptance criteria that are supposed to do
that? 8

Unfortunately Acceptance criteria look like stories too. I
come from a tesJng background, and I’ve never properly understood this. All the examples I see of acceptance criteria wri_en on stories are just more requirements – at a lower level of detail. It’s a way of capturing them without having to write new stories using the user story parlance. Acceptance criteria always used to be based directly on the requirements. They are just expressed using diﬀerent language. Acceptance criteria are just requirements preceeded by ‘verify that’ This just lulls you into a false sense of security, that you know how to test the thing. This is dangerous. Acceptance criteria aren’t tests. They’re not tests unJl they are concrete. Examples with real world data are concrete – but you probably won’t cover that on a post it note. 9

You’ve seen the problem with user story icebergs. At
each of those levels of detail, there’s always more under the surface. An a lot of the stuﬀ under the surface might not be that important. So surely we don’t want to track the actual story through to compleJon at any of those levels, because we’re going to iterate. 10

This is how we have been made to feel about
documentaJon. 11

See how we feel about post its though! Happy,
Smiling! 12

DocumentaJon – booooo, waste of Jme 13

PosJts hooray!! Happy families!! That’s because as
long as you have post it notes, you’re not doing too much unnecessary documentaJon. As long as you have post it notes, you’re not wasJng your Jme 14

That’s because as long as you have post it notes,
you’re not doing too much unnecessary documentaJon. As long as you have post it notes, you’re not wasJng your Jme. But wriJng 6756 user stories out in a prescribed format – regardless of how they are supposed to support our project a good use of Jme? Managing a giganJc backlog of wish-‐list features that are out of date in a month and no-‐one can remember is a good use of Jme? DuplicaJng and linking and un-‐linking, capturing details in Jira against Jckets that are eﬀecJvely going to be binned is a good use of Jme? This all sounds like job creaJon to me Where do you capture the important details about how our systems will behave? 15

You end up throwing it all into Cucumber as tests.
And you move out of the user story badlands and straight into AutomaJon Hell. Wow these user stories are dangerous. So if they’re so dangerous why do you use them? 16

So I’d like you to turn to the person next
to you and in groups of 2 or 3 spend the next couple of minutes answering these 2 quesJons & then we’ll see what the group thinks… 17

So I had the same conversaJon with myself as you
just did and came up with the following 3 deﬁning things about user stories 18

ConversaJons are good. We’re more likely to understand
what customers want by having a conversaJon with them rather than reading a document. During conversaJons, people tell stories. Stories give us even be_er insights because they give context and narraJve. They help us make an emoJonal connecJon and care about what we’re doing. 22

Here’s Jeﬀ Pa_on’s deﬁniJon of a user story. Aaaah,
so I can see value in that. 23

I went to a workshop last year run by Gemma
Cameron on Comic Strip User Stories led by Gemma Cameron – has anyone heard of comic user stories? 24

They all end with someone stood with their arms in
the air (put arms in air) and a yay! Moment. The comic strip sets the context, highlights the gap or the current pain and leads to an awesome outcome. 25

Here’s mine from. Our company delivers digital retail soluJons.
26

So stories are supposed to help you understand what awesome
outcomes really look like. You’re supposed to include the value in the story to help remind you of why you’re doing it. That’s why you have the so that / in order to bit in the user story format. 27

But you ojen see stuﬀ like this…. But
we’re OK in the BDD world because we put the value ﬁrst to make sure we’ve got it 28

Phew! Thank goodness for that – much be_er.
The value part shouldn’t be an a?erthought that you apply in order to follow the correct user story convenJon, it should be much more proacAve than that. 29

They all end with someone stood with their arms in
the air (put arms in air) and a yay! Moment. The comic strip sets the context, highlights the gap or the current pain and leads to an awesome outcome. 30

I don’t know I’m going to call them outcomes.
31

The whole point of iteraJve delivery is to allow us
to deliver in smaller chunks & get value earlier Not this 32

Not this. You can sJll get analysis paralysis
in an agile project 33

So we’ve all seen this before IteraJve versus
incremental delivery. The scope of a piece of work is the same regardless of how you deliver it. The beneﬁt of iteraJve delivery is that you start geVng value early and you learn quickly and can change direcJon if necessary. This normally leads to less work because it becomes apparent more quickly that a lot of the original scope isn’t actually needed. You might be able to stop at the motorbike and sJll get the outcomes you need. 34

The most important concept of chunking is a chunk of
value – a chunk of outcomes You need to a_ack your delivery like this But do you need to split your user stories to this Any autonomous unit up front in order to do that? No – ﬁrst you need to explore the ﬁrst chunk of outcomes and how we deliver value in the leanest possible way. But where do you start with that? 35

Has anyone heard of systems theory? Systems theory started
in the 1940s The study of systems in general, with the goal of discovering pa_erns that can be applied to all systems in physics, biology and engineering. System Theory says this The value of a system or process lies in its outputs. We know it’s good to focus on these. 36

I dunno, I’m going to call them outputs
To ﬁnd out how are systems generate valuable outputs we need to think of how the thing is actually going to work. We have to consider the user interacJons and processes that are required to make sure we have something joined up. 38

you need to tell a story about the interacAons that
deliver the desired outputs and outcomes. You need to think about acJviJes and events. 39

Here’s a quote from a guy called Jeff Pa_on
‘Telling the Whole Story’ In 2001 I lej the team I was on and started doing things differently. I, and my team, tried an approach to wriJng stories that focused on the big picture. We worked to understand the product we were building and to make trade-‐offs together. We used that bunch of index cards with story Jtles to organize our thoughts and break down that big picture into the small parts we could build next. In 2004, I wrote my first arJcular about this idea. I didn’t coin the term story mapping unJl 2007 Then he started running into people who were doing similar things – he’d discovered a pa_ern 40

Anyone not heard of story mapping? Anyone want to
describe it? So in story mapping you tell a story using a sequenJal set of acJviJes that deliver the desired outputs and outcomes. The map is a narraJve flow across many users and systems. Doing this helps you spot holes in story and helps you consider alternaJve paths and opJons. You’re looking for the minimum viable product. ‘the smallest product release that successfully achieves its desired outcomes’ And the really cool bit of story mapping is where you find the ‘opening game’ which is your first iteraJon through the narraJve. This is what will guide you strongly in your development iteraJon. This whole thing tells a story. But what about these individual lower level post it notes here. What are these? 41

I dunno, I’m going to call them acJviJes. As
part of a process So we don’t need to track user stories autonomously down to the lowest level to be successful in delivering in smaller chunks But the most important chunk is understanding the leanest story that delivers those outcomes. 42

To track and esAmate work This bit
really confuses me. You’ve seen already how user stories all look the same regardless of what level they’re at or what we’re using them for. Which type of user story to we track and esJmate. A whole outcome user story unJl it’s done? A whole output user story unJl it’s done? A whole acJvity user story unJl it’s done? 43

You’ve seen the problem with user story icebergs. At
each of those levels of detail, there’s always more under the surface. An a lot of the stuﬀ under the surface might not be that important. So surely we don’t want to track the actual story through to compleJon at any of those levels, because we’re going to iterate. 44

When we’ve got concrete examples we can start to work
out the work we need to do to implement them. So tracking and esJmaJng work at the example level makes sense to me. 45

In BDD we use the word scenarios a lot
46

I’m pre_y sure they’re tasks. I’m going to call
them tasks. 48

OK so let’s recap with the User Story Starfish
Why do you use stories, this stuff is important, you want to have conversaJons, collaborate and chunk things down so that you can deliver value as early as possible. To stay out of the badlands though, you need to be aware of doing too much up front analysis, don’t waste Jme adhering to silly formats if they’re not necessary and recreaJng user story format Jckets in Jira might be a waste of Jme. To get to value as quickly as possible, you need to chunk down a the outcome level, and be aware of moving through different levels of detail. You need to do the right amount of documentaJon to join up with your BDD pracJces, use the right tools for the right type of documenaJon. You should do less unencessary spliVng of user stories if you can defer diving into the detail unJl later. You need to tell the whole story. By capturing the processes and acJviJes that lead to the valuable outcomes. And track work at the example level rather than at the user story level. 49

OOPSI So how do you do that. How
do you support the intended use of stories whilst staying out of the badlands I’d like to introduce the OOPSI model for agile analysis. OOPSI stands for Outcome, Output, Process, Scenarios, Inputs. The OOPSI technique accelerates delivery by helping you structure your discovery acAviAes so that you are always working on the right thing and can see the bigger picture. It will give you a narraAve and context for your analysis artefacts and the examples, tests, and scenarios that support them. It’s an extended version of Chris Ma_’s feature injecJon OOPI, but includes scenarios to help bring together BDD and speciﬁcaJon by example techniques 50

So here’s how OOPSI Mapping works. A bit like
Ma_ Wynnes example mapping, but a bit more structured So starJng with Outcomes This could be a typical outcome user story, or a comic strip user story Gemma Cameron style. Or you might not even need a user story. If you’ve explored goals and outcomes by doing impact mapping, you’ll already have the goal, outcome and actor. Then we look at Outputs This is a really important step. You know that the valuable parts of your systems are in the outputs. You want to illustrate these using examples. Draw them. Do this exploraJon collaboraJvely with the domain expert. This part, exploring outputs works really nicely with DDD. As you explore the outputs the understanding of the domain rises and you start to design your ﬁrst iteraJon of your data model. So now we’re onto the Process part. 51

This is deﬁnitely a collaboraJve discussion with the key domain
experts and stakeholders. By choosing a small set of important outputs and illustraJng them you get a really good idea, quickly of what value looks like from the customer. You already have some concrete examples. You know that if you could demonstrate these outputs being produced, the customer will thing that’s awesome. Also we start to get a good idea of the type of data and interfaces that your system needs to support. But you don’t need to get becalmed by analysis paralysis because you’re going to choose the most useful output to start with. Which output is the most fundamental and important to the customer? 52

So let’s take the most simple type of coupon.
Based on products in the basket. What process will generate these outputs? What are the main scenarios? 53

Our BDD scenarios, if we don’t use SBE technique ojen
don’t go down to this level of detail. I think this is where all the magic happens and we get to start to properly understand the domain. We need to properly think about this stuﬀ before we build our APIs. I think some key examples like this on our wiki are really useful 54

So you may have noJced these detailed examples tend to
resolve around one of the acJvity boxes. In this case ‘evaluate promoJons’ in our ﬁrst iteraJon, we’re not too worried about potenJal prinJng problems, The scanning of items at the Jll is exisJng retailer funcJonality, so we’re really focusing on the evaluaJon bit.. Let’s look at another. 55

Does that aﬀect the process? Yes – we need
to scan a loyalty card for this type of scenario 56

That has introduced some addiJonal a_ributes and broken the model
from the previous example. So we might extend our soluJon to support this for our second iteraJon. 57

And we’d have other tests focusing on the recognising and
validaJng the loyalty card. They don’t sit with the evaluate promoJons test, they’ll sit around the ‘scan loyalty card’ acJvity box. If we wanted to, we could organise our documentaJon on a wiki hanging oﬀ these boxes. That’s not complete madness. It’s how use cases used to work and be organised. Whether you start in gherkin or with tables the most raJonalised expression of the test tends to bring it down to this level. You only want to evaluate one thing in each test 58

And then as we get more sophisJcated we deal with
new capabiliJes all together. Some of this we can short cut and some of it will extend our soluJon. We might need to refactor. You can see how more key examples would develop around the push coupon to mobile app acJvity box. All of these examples and tests we have talked about so far guide development really strongly. We can build them one at a Jme and build unit tests TDD style and have high conﬁdence that our system is going to work as expected. We might build up some regression tests around our APIs to support the key evaluaJon funcJonality. Using OOPSI helps us recognise when we’re working at diﬀerent levels of detail. Take a look at this. 59

Once we’ve delivered all this capability and we’re running in
producJon – we might have some automated higher level tests that ensure we generate all the diﬀerent outputs. These tests might check the actual output more carefully to make sure all the steps in the process are working, including the reporJng. 60

That was OOPSI It helps you chunk down and
start small – so you’re not overwhelmed with detail It helps you see the big picture and recognise where you are in the discovery process – so that you don’t get lost It helps you only examine the most important Jp of the iceberg and generate the right amount appropriate documentaJon – so that your projects don’t get sunk 61

It helps us with navigaJon and design thinking. At
each progression we evaluate opJons and make decisions to choose the most important ones. You may have noJced that if you a_ack this the other way round it ISPOO. 62

So hopefully I’ve convinced you that there is a way
to avoid death by user stories There’s even a way to avoid user stories altogether By using this OOPSI approach – Outcomes, Outputs, Process, Scenarios, Inputs you stay out of the badlands 63

Stay on the safe path to value, and achieve awesome
outcomes 64

Death by User Stories

Death by User Stories

More Decks by Jenny Martin

Other Decks in Technology

Featured

Transcript