Fixing the Cause-Effect Trap in User Stories
Join the DZone community and get the full member experience.Join For Free
if you write user stories, it is very likely that you have been
using the "as a... i want... so that..." stanza. what you might also
have found is that it is hard to fill the "so that" clause with
something that makes sense. "as a user i want a button so that i can go
to the next screen"... that is pretty naff, isn't it? so how do you fix
ask "why" several times!
the "as a... i want... so that..." user story stanza is a very nice tool. it helps you put a lot of information in a very compact form, which is great for summarizing a user story, for instance as a descriptive one-line title in an electronic tool. but there is a trap in this stanza that i have seen just about everyone struggle with when using it, leading to all kinds of suggestions, mainly by changing the stanza around ("in order to... as a... i want..."). but those suggestions don't fix the root cause of the problem. let's start with identifying the real problem.
the real problem: the cause-effect trap
in the "as a... i want... so that..." stanza you answer the questions "who?", "what?" and "why?" respectively. so our button example becomes:
- who wants it? the user.
- what does he want? he wants a button.
- why does he want it? he wants to go to the next screen.
the "why?" question is the interesting one here. the answer "he wants to go to the next screen" is a perfectly valid answer, but the problem is that this is not something that makes sense as business value, which is what you would like to have in the "so that" clause. what happened is that with this first "why?" you have only stated a cause-effect relationship : when you press the button (cause) you go to the next screen (effect). this is what i call the cause-effect trap.
how do we fix the cause-effect trap?
the trick to fixing the cause-effect trap is to realize that there is a chain of why's that you need to answer before you get to the right level . the first "why?" you ask in the "so that" clause is just that, only the first in a chain. let's fix our user story.
the first thing we see is that that the answer to "why?" is a "what" in its own right, but at a higher level. so the first fix is to move the "so that" clause to the "i want" clause, and answer the next "why?" in the "so that" clause.
as a user i want to go to the next screen so that i can shortcut from screen 1 to screen 9
hmm, a shortcut? why, i wonder? let's do the fix again:
as a user i want to shortcut from screen 1 to screen 9 so that i can save time on 90% of the cases in the screen workflow
ah, so apparently screens 2 to 8 aren't needed in 90% of the cases, and this saves time. why, i wonder? (see the pattern? )
as a user i want to save time in 90% of the cases in the screen workflow so that i can improve handling time in my helpdesk
ah, so there is someone who wants to improve a business process. apparently it takes a long time to plough through screens 2 to 8 while it isn't needed... now, that sounds more like business value! but now the "as a" clause does not feel right. who wants this business value? who is being referred to in "my helpdesk"?
as a helpdesk manager i want to save time in 90% of the cases in the screen workflow so that i can improve handling time in my helpdesk
now that looks better. let's take this back to the team... they will likely respond with: "save time in 90% of the cases? that's too vague for us. can you be more specific?". okay, let's backtrack down the why chain to something more concrete.
as a helpdesk manager i want to shortcut from screen 1 to screen 9 so that i can improve handling time in my helpdesk
and there we have it: a fixed user story!
what have we learned?
lesson 1 : you can fix a user story by going through the why chain , replacing "i want" with "so that" as you go along. (in effect you've made the stanza go: as a... i want... so that... so that... so that... so that... )
lesson 2 : the "as a" clause is more closely related to the "so that" than the "i want". this is logical, since a stakeholder is not interested in features, but in the business value that feature provides . a feature is just a means to an end.
lesson 3 : put the highest statement in the "i want" clause where you're still making a statement about the product. an extra - and huge! - advantage is that you will have considerably widened the solution space for the team, enabling the team to come up with better solutions : there are a lot more options in "providing a shortcut" than there are in "a button". square button or round? green or red?
lesson 4 : look at that that "improve handling time" bit... wait! could it be true? do we actually have a basis for measurable business value ? so that i can improve the average handling time by 20% (current: 5 minutes 20 seconds) . that would be a great to help the product owner prioritize!
serge's three step process for fixing user stories
so here's my 3-step, fail-safe, make-you-a-millionaire-in-a-week plan to fix user stories :
- use the why chain: ask "why?" until you're talking business. put that in the "so that" clause.
- fix the "as a" clause to reflect the correct stakeholder.
- fill the "i want" with the highest level statement that says something about the product.
...and there you go. killer user stories are yours! happy fixing!
Published at DZone with permission of Serge Beaumont. See the original article here.
Opinions expressed by DZone contributors are their own.