Home > Agile, Business Value, Stories > so that… so what?

so that… so what?

One of my biggest frustrations on a project is when we have stories that capture a solution rather than a goal.  Often this leads to long conversations with the business to drive out exactly what it is that should be built and hinders the creativity of the development team in finding the best solution for the problem.  I’ve spent a lot of time over the last year and half thinking about this and trying out a solution to the problem and now after much encouragement from Mike & David I am finally blogging about it.  This isn’t meant to be a silver bullet solution, but I hope it provokes some discussion and you find it interesting.

A few of us got talking while doing an inception early in 2009 that the ‘so that’ statement was often either repeating the requirement, was too general or was left off completely when capturing stories.  This meant that we were missing the true goal of the business and lead to problems with scope and misunderstandings of what a story truly meant once we got into delivery.

Using an example of changing channels on a tv with a remote control, let’s look at some of the poorly written headlines you could have…

Headlines which repeat the requirement as the business value tend to be very difficult to prioritise because we don’t understand the benefit that they provide to the user.

As a viewer I want to change channels on the tv with my remote so that the I can use the remote to change channels.

Headlines which are vague cause debate over alternative solutions that may or may not solve the problem.  Is using the remote really necessary to watch different channels?

As a viewer I want to change channels on the tv with my remote so that I can watch different channels.

Finally, in really bad cases you end up with no business value at all which are both difficult to identify alternative solutions for and to prioritise:

As a viewer I want to change channels on the tv with my remote control.

Of course there are always the times when a headline captures the true value of what the business is trying to achieve:

As a viewer I want to change channels on the tv with my remote control so that I can watch different channels without needing to be in reach of the television.

This story can be easily prioritised against other stories and alternative solutions identified, but there are still problems.  The headline ends up being quite long winded and you may need to read it two or three times to grasp what we are aiming to achieve.

We played around with the idea of switching the so that and the I want but weren’t happy because it was very awkward when reading it.  We got busy with the inception and the pressures of delivery overtook.

My next project was centered around helping the client learn to write good stories and develop their agile process.  I had lots of time to think about what goes into a story and what is most important.  My favourite question came back… how do we ensure that the true goal of the business is the most important thing captured in a headline.  I came up with a potential solution, but didn’t teach it at the time because I hadn’t tried it myself.  I’ve now used it successfully on my current client for almost a year and found that it has accomplished what I wanted and more.

The format that I use is:

As a (role) I want (business value) by (method/requirement)

This forces the writer to capture the value and be specific with what what the story is aiming to achieve.  At first I found it quite challenging, but soon realised that the difficulty wasn’t because of the format, but that it was forcing me to have headlines which clearly stated the goal the business was trying to achieve.  I wasn’t allowed to wimp out!  The feedback that I have received from the developers on the team has been very positive and it has helped to ensure a common understanding with the business.Our remote control example now reads:

As a viewer I want to change channels without being in reach of the tv by using my remote control.

This states the same benefit to the viewer and solution as the ‘good’ headline above, but in a much clearer and natural statement.  We can prioritise it easily and the team has the ability to think of alternative solutions.  It also makes it very difficult to run into the ‘bad’ headlines from above.

Once I started using the format, I realised there was another big advantage.  The business value is attached to the strongest words of the statement (‘I want’) and the method of delivering the business value is attached to the weaker word (‘By’).  In the traditional I want/so that format it is the other way around.  This makes a big difference in the conversations with the business when an alternative solution has been identified, but that is for a different post…

Categories: Agile, Business Value, Stories
  1. March 23, 2010 at 22:48

    Love it! I’ve been hunting for a way to emphasize the reasons for stories. Thanks!

  2. Pat
    March 24, 2010 at 10:15

    Hi JK! Great blog post. Very insightful. Forgetting the goal is an easy thing for many people to do when working with stories.

    I like the Feature Injection style that Chris Matts harps on about (in a good way).

    In order to achieve
    As a
    I want

    I like the prominence of what they’re trying to accomplish first with the “how” as the last important part.

  3. Pat
    March 24, 2010 at 10:16

    Whoops. Didn’t realise angle brackets disappeared…

    It should have read…

    In order to achieve [some business goal/objective]
    As a [role]
    I want [some feature]

    • March 24, 2010 at 11:10

      Thanks Pat! Yes, I like that format better than the traditional one. I do find it a bit unnatural to read though because the role is in the centre of the headline. I also think there is a big advantage with having the business value associated to the ‘I want’ statement. I’m going to write about that soon.

  4. March 24, 2010 at 17:16

    Actually, you could simplify it with:

    As a viewer I want to change channels without being in reach of the tv.

    The “using my remote control” is prescriptive. Your UX guy might have a better solution. Yeah, all the competition might use a remote, but what if there was something better. People lose their remote, batteries go dead. What if I could do it by blinking?

    As silly as this sounds, when I was a UX guy, I was always annoyed when the requirements included the solution design because it removed better options.

    Just a thought.

    • March 24, 2010 at 23:57

      Agreed. I always want people to stay as FAR AWAY from the “how” as possible. “Why” and “what” are the keys.

      Too often people have requirements like “I want the user to register and create a profile” without thinking of *why* they want them to register.

      The real requirement may be “I want to build a community”, or “I want to track people’s actions”

    • Alan
      March 26, 2010 at 12:02

      Totally agree here Kevin. It seems to me that by specifying the use of a Remote to change channel there is an implied solution constraining the development options as well as the UX concerns.

      It may be entirely possible that the requirement could be met by the use of a long stick or as a managed service having a person at your beck and call to change the channel for you.

      I do, however, agree with the premise of JK’s argument here.

  5. March 31, 2010 at 20:15

    As a tv viewer I want to find something interesting to watch, without being in reach of the tv, by using a hand-held device.

    As always, the conversation and tests go beyond the headline:
    maybe what I really want is my iPhone controlling my Tivo.

  6. Chris Chan
    March 7, 2013 at 21:13

    Great post.

    With some teams I have dropped the ‘so that’ and in others not even follow this whole format at all’. However, for teams starting out on their agile journey the value of ‘so that’ is a constant reminder to focus on customer/business value. And if there is no value then we should not do it. It’s easy for teams to forget customer/business value at first (old mental models). So having the ‘so that’ helps them with the ‘Shu’ (Shu-Ha-Ri) level learnings of creating user stories.

    When teams have matured and have value in the back of their minds and are constantly asking themselves about “is this valuable”, then this is where adaptations can occur and dropping/replacing ‘so that’ may be possible. This is where they have moved to the ‘Ha’ level of learning.

  7. Edward Brown
    April 22, 2014 at 22:18

    How about this

    As a lazy couch potato I hate getting up to change the channel every time a commercial comes on…I wish there were some way to change the channel without having to get up
    Actually, this is more likely to come out during contextual inquiry or interview….
    Also, we have a pain point that we can prioritize against our other user types. Some people might actually not value the ability to change the channel without getting up.

    Either way, changing the channel without a remote is only a task and not the true benefit to the user.

    Great thread!

  1. March 26, 2010 at 01:15
  2. April 1, 2010 at 11:45

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: