Agile Zone is brought to you in partnership with:

In the business since 1995. Did a lot of development in Delphi, Smalltalk and JEE. Turned to full-time Agile consultancy in 2007, although I still do the more "techy" stuff on the side. Serge has posted 1 posts at DZone. View Full User Profile

Fixing the Cause-Effect Trap in User Stories

04.06.2010
| 8620 views |
  • submit to reddit

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 it? 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 ;-) :

  1. Use the Why Chain: Ask "Why?" until you're talking business. Put that in the "So That" clause.
  2. Fix the "As A" clause to reflect the correct stakeholder.
  3. 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!

References
Published at DZone with permission of its author, Serge Beaumont. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Andrew Arrigoni replied on Tue, 2010/04/06 - 8:08am

This has the added benefit of exposing other options to solve the problem. For instance, re-arranging the pages so that page 9 becomes page 2, and giving the user an option to finish early. Or create two completely seperate flows, one for the 90% case and another for the 10% case.

 Each of these has pros and cons but might not be thought when a user is yelling, "I want my button!" when what they really want is "I want to do this faster!"

Erin Garlock replied on Tue, 2010/04/06 - 8:35am

Great article Vincent.  I'd even go so far as to remove the "shortcut from screen 1 to screen 9" into something more business oriented.  I do not allow business conversations to specify technological "How" statements.  Let me give you an example of where leaving how statements leads to a flawed or incomplete user story.

Thinking about old dial-operated stereo controls on the dashboard:

As A Safe Driver I Want the radio dials easier to find ("how") So That I can keep my hands on the steering-wheel more.

The problem here is that to be a safe driver, using a dial is the wrong technology/solution ("How").  The real solution was ultimately button controls and then relocating them from the dashboard to the steering-wheel.  Thus we have:

As A Safe Driver I Want radio controls So That I can keep my hands on the steering-wheel 100% of the time.

As A Helpdesk Manager I Want intelligent navigation So That I can improve handling time in my helpdesk

I set to thinking about the problem from my viewpoint to get a couple ideas, and then get ideas from the business needs people.  We all think in different ways, and this gives us different perspectives to collaborate on without first creating a bias from someone's initial thoughts.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.