“As a, I want, So that” Considered Harmful

If you are working on an agile project, it is almost certain that you are using Stories to describe your backlog of work. It is another near-certainty that if you are using Stories, you write them down using this format:

As a <user or stakeholder type>
I want <some software feature>
So that <some business value>”

As someone who cares about the state of agile practice, I want to offer some alternatives, so that agile teams remember that the point of the story is in the telling, not the template. The shared understanding comes from the conversation, not the card. By offering you different ways to ‘tell’ the story in its short written form, I hope you will be able to re-ignite a greater level of meaning, interest and engagement in your team’s discussions about the work they are doing to build great software that matters to people.

Who, What, Why

Let’s start with what’s good about the “As a…I want…So that…” format.

  • It identifies the Who, What and Why of the story. Who will use this, or find it valuable? What feature are we providing? Why is this valuable or important? These are all fundamentally important things in the discussion of the story.
  • It’s memorable. Once learned, nobody is likely to forget the structure.
  • It’s well known. People who are already used to the structure don’t lose any time getting their head around a new format on a new team or project.
  • It’s brief. The structure encourages the who/what/why to be expressed in a single sentence.

So, what is wrong with a simple, memorable structure that gets the key points across in one sentence? In my opinion, the runaway success of this format has been its own undoing. It is like a creative, original song that became a hit and has since been turned into elevator musak due to its popularity. It is so widely used, it’s no longer a handy suggested primer, it’s the law. It’s no longer a form of expression, it’s a story-shaped mask hiding a lack of imagination. Now anyone can make any lazy bunch of words sound like an agile story.

Why bother?

Arguably the most important purpose of a Story when it is first proposed is articulating the reason why there is value in making a change. From the implementation team’s point of view, doing nothing is always the cheapest and simplest option, so there needs to be a good reason for making a change in the first place. That’s meant to be the purpose of the “So that…” clause in the common template, but putting it last means the logic is the wrong way around, and this phrase often ends up just being a grudging re-phrasing of the “I want” clause. Instead we should always start with the reason why we need a change, before proposing what the change should be.

Chris Matts is credited with what I think is the best improvement made to the story format so far. He suggests replacing “So that…” with “In order to…” and placing it at the beginning of the sentence. This is absolutely the right place to be expressing value to a stakeholder.

Hence a simple and effective alternative format is:

In order to <achieve some business value>,
As a <stakeholder type>
I want <some new system feature>”

Who cares?

The intention of the “As a…” part of the story format is to encourage us to tell stories from a user’s perspective, rather than just itemise a long list of things the system should do. It is there to humanise our work and remind an agile team that they are not just building software, they are making an impact on the way people work.

To get the most out of this part of the story description, you should be specific about the persona that typifies who gets the benefit of the impact that this story will make. Use adjectives if it helps to bring the story to life, such as “busy executive”, “risk-averse investor”, “regular commuter”, “stressed mother”, “bored teenager” and so on. Avoid generic roles like “user” or “customer” – if your story benefits all users equally, then just leave out the “who” clause altogether, and save it for stories that benefit from the differentiation. Definitely avoid using non-persons such as “the system”, “the database” or even “the Product Owner”. As Gojko Adzic once said, “The system doesn’t want to do anything – the system wants to sleep.”

A story does not always need to be told from the user’s point of view. It does not always make sense to say “As <someone> I want <something>” because we can deliver value without necessarily answering a specific user need. Good software is like good service in a restaurant – often we are delighted by the little things that happen without us asking for them.

Therefore you can try formats that still identify who benefits from the change, but express it as a pro-active change. Consider this clunky example in the traditional format:

“As a shopper, I want to not see the card types that don’t match my card number when I type it in, so that I can only see cards types which do match the number.”

This sounds contrived and awkward, and would read a lot better in a format such as this:

“In order to increase visual feedback for shoppers entering card details, we will progressively hide the card types that do not match the card number as it is entered.”

Notice how in this format we still identify the “who” (shoppers entering card details) but the “what” action is introduced as “we will”, since it is the product team that is prompting this improvement.

What’s new?

Having identified the “why” of the story in an “In order to…” phrase, and identified the “who” in a “for…” or “as a…” phrase, the story culminates with a call to action, describing “what” is to be added or changed in the software.

One of the common problems I see in stories is that the “I want…” phrase is not specific enough, and often states behaviour or features that overlap with what already exists.

To combat this and help keep the “what” of the story short and to the point, I like to start with a verb that highlights the new action or behaviour the product will have, that it does not have now.

Note that although I often precede this verb phrase with “we will…” (as a replacement for “I want…”), the verb phrase should describe an action or behaviour that the product takes, not the action that the implementation team does to put the feature or behaviour there.

For example, if the “what” of the story is about hiding card types that don’t match an entered credit card prefix, the following product-centric use of “we” is valid:

“we will hide the card types that do not match the entered card number…”

But this team-centric use of “we” is not:

“we will make an AJAX call to the card validation service after 2 digits are entered…”

Similarly, this is valid: “we will include settlement date in the transaction report”

But not this: “we will add a column SETTLEMENT_DATE to the Transaction table”

If the distinction is too subtle and you find yourself writing implementation details, try using “the system will…” or name your product, as in “Ex-Sell will…”

Where’s my Change?

As I mentioned earlier, the short description of a story often leaves a lot of ambiguity about what the scope of the required change will be. Even if the required new behaviour (the “what”) is accurately described, the amount of work required of the team to implement it depends on how much it differs from current behaviour, and that might not be clear to everyone.

For example, imagine your job is to estimate the size of this story for a financial trading system:

“In order to continue trading while avoiding breaching regulations,
As a trader, I want a warning message when the total volume of trades reaches 90% of my daily trading limit”

The requirement is pretty clearly described, but unless we are very familiar with what the relevant part of the system does already, we can’t tell on the face of it if this is a major change or not. Consider the following possibilities:

  • Is there already any concept of daily volume limits in place? (If not, this story has to build a lot of new things, and would be relatively complex to implement.)
  • Does the system already have daily limits which it prevents traders from exceeding? (If so, much of the existing logic could be re-used to trigger the required warning, and it would be only a moderate change.)
  • Is there already a warning in place, but which is triggered at 80% of the volume limit? (Changing this warning threshold to 90% would be a very simple change.)

The point is that the description of the required behaviour alone, even if complete and accurate, is not enough to indicate how complex the story is to implement. We also need to know how much of a change it represents compared to the current behaviour.

Try a “Whereas currently…” clause

A technique I like to use to address this problem is to add another clause to the story template starting “Whereas currently…” or “Instead of…”

The wording of this extra clause should make as clear as possible the contrast between what is needed and what we already have in the product.

For the example story above, applying these techniques might result in the story being amended as follows:

“In order to help traders make best use of trading volume limits,
The system will warn traders when the total volume reaches 90% of the daily trading limit;
Whereas currently no warning is given until the daily limit is reached and all trades are blocked.”

Don’t obsess about the format!

I’ve given you some ideas for adjusting the way you express the short form of stories, but remember that the format does not matter as much as the process you use to identify, discuss, elaborate and ultimately implement the story.

A story is ideally just a token for the real information that needs to be discussed – the story card is a promissory note to hold a conversation about how you can improve your product. Assuming the information you write on the card is not false, any of the formats is probably good enough to start that discussion. But if the information on the card is false, all formats will be equally bad.

Remember that your customers are not buying your stories; they are buying the results of those stories. Varying styles and experimenting with different formats might help you to see whether something new comes out during discussions, or results in quicker or more reliable implementation and better shared understanding. Try these ideas for example:

  • Name stories early, but add details later, after a conversation
  • Let the Product Owner write the ‘why’ phrase, let the developers write the ‘what’ phrase
  • Avoid spelling out common or obvious solutions
  • Think about more other stakeholders who would be interested in or affected by the story, not just the primary actor
  • Ask a question, like “How can we reduce reconciliation time?”
  • Use a picture instead of words – Chris Matts recalled a story card that only had these Kanji symbols, meaning “Japan”, to represent a story about Japanese translation.storypic

For more advice and ideas to improve your stories, see our new book:

“50 Quick Ideas to Improve Your User Stories”

By Gojko Adzic and David Evans

leanpub.com/50quickideas

20 responses on ““As a, I want, So that” Considered Harmful

    1. Martien

      Many of us find that what we think are our best ideas are traceable back to something Tom Gilb has already thought of 🙂

      Thanks for commenting.

  1. Gojko and David – in the long run all formats will be come harmful. Yours is a good alternative but after too much mis-use it too will decay.

    Instead what I tell people – start with any format that forces you to ask questions about the goal, the audience and the reason why. Get good using that approach and then branch.

    I suggest to attendees of my classes if you’re still using As a, I want, so that – in a years time you missed the point.

    1. Agreed, all templates and tools of this kind are like crutches — they help to get you moving, but ultimately it is the movement that heals, and when you are able to move freely, crutches will only slow you down.

  2. Great article David, I agree completely that we often forget to focus on writing great stories. I particularly like the ideas of including an adjective to describe the user, and the ‘whereas currently’ phrase.

  3. Thanks for the ideas!

    My only objection is about “In order to…” which almost always can be shortened to just “To…”.

    Mats

    1. Mats

      Short is sweet! Anything that improves the signal-to-noise ratio without distorting the meaning is a good thing, so I like your improvement.

      David

  4. It is great to see more prople thinking about this.
    I have been using the So That:, As a:, I Need: format for a long time primarily to maintain focus on the business value, rather than the role. It i sometimes difficult for people who are used to the ‘traditional’ user story format, but ti really works.

  5. I guess the takeaway from this is that it’s really less about the format, and more about careful choice of phrasing.

    Your “clunky” example perfectly illustrates this:

    “As a shopper, I want to not see the card types that don’t match my card number when I type it in, so that I can only see cards types which do match the number.”

    Which in itself is somewhat contrived, because the format can be kept and the sentence still make sense if the wording is chosen more carefully:

    “As a shopper, I want to only see the card types that match my card number, so that only information relevant to me is shown”.

    The “In order..” alternative you give SOUNDS better than your original “As a..” but snippets like “In order to increase visual feedback” are equally confusing because they’re not explicitly describing what the concrete effect is going to be.

    You’re right though – people start seeing the format as the desired outcome rather than the content.

    Derek.

  6. I totally disagree with the position/proposal expressed in this article. User stories are meant to be handed to the Scrum’s engineering team and must be expressed in the lingo (qualify INVEST/DEEP) understood by the developers to ensure delivery of done-done increments. The proposed transformation leaves to much space for generality and certain later reformulations with well known and expected consequences.

    1. When you say “handed to the Scrum’s engineering team” it sounds like you are putting a process over communication.

      If you need to use this format of lingo, it’s to cover poor communication. What this article says is that if your communication is adequate then the format can become an unnecessary burden and actually unhelpful.

      I whole heartedly agree with this article.

      People and Communication over Processes and Tools.

    2. In order for a story to communicate value to the business owner, it must be written in a way that is non-technical. So, I’d argue that the structure is less important than the content, but the content must be meaningful to anyone in the company (even the CEO).

  7. I agree with your ideas. However, rather than say “I want”, I think “I can” is better. Who cares what you want? What the business wants is often wrong. What the business NEEDS is more important. But rather than write about wants and needs, why not just write what the devs should be building so the user CAN achieve something.

    “I can steer left or right so that I don’t crash into a tree” is better than “I want to steer left or right so that I don’t crash into a tree”. You should build something so that the user CAN do something, “want” is irrelevant.

  8. Great article. I hope this article will be very relevant for ages. Most of the time we deviate from the initial intention of why we started following such a process or template. So it’s good to question in frequent intervals whether we are justifying to our intentions.

Leave a Reply to Mats Henricson Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.