Elaborating user stories by using abstract to concrete approaches

Abstract to concrete is a term I am going to use to describe the idea of elaborating stories by:

• Using a structured format to interrogate the story;
• “Abstracting” the context and meaning behind the story rather than just listing acceptance tests or task; and
• Making the abstract conversation more concrete by discussing what needs to be done in order to build the story.

It may seem strange at first glance to take the story up a level and discuss why you need it as well as what else could be accomplished. In fact doing so creates the risk of scope creep.

But I find that a structured discussion of both the context and the purpose behind the story leads to a better understanding of real user needs and even the ability to deliver less because what is delivered is based on a sound understanding of real needs.

The Generic Abstract to Concrete approach is to:

• Use a structured conversation to understand the purpose and context of the story (I have listed three tools below for doing this);
• Allow the scope and meaning of the story to mature before becoming “concrete”;
• Stop and create concrete tasks, stories, models and/or tests using whatever method suits the team; and
• If desired, prioritise the “concrete” elements of the story using MOSCOW or another prioritisation process.

Some approaches to the structured conversation are:

• Using the standard story format to make the story more abstract or more concrete;
• The “Question Compass” or a similar questioning model (This could include “6 Thinking Hats”, FMEA, or any techniques the team feels are suitable);
• Telling a story based on the format “that was then … this is now”.

Using the story format

People don’t always notice how useful the standard story format can be, so lets look at how we can use it to make the story more abstract or more concrete:

The standard format is:

As a [user] I want [something] so that [reason].

To make this more abstract:

Remove the [something] and replace it with [reason], leaving a blank space where [reason] was:

As a [user] I want to [reason] so that [blank]

Ask the group to come up with possible replacements for [blank] to make the story whole again.

For example, “As an iphone user I want to sms my friends so that I can share my experiences” becomes “As an iphone user I want to share my experiences so that [blank]”. Then the group might replace [blank] with “so I will be popular” or “so my life is made public”.

If you do this multiple times then it is really just a variation of the 5-why’s technique, and it can lead to merging other stories, realising gaps in your understanding and, most importantly, discussing the real drivers behind a user’s (assumed) need for the story.

To take things a little further you can also take the [user] component and explore this with questions such as:

• Is this user part of a wider community? Who else is in that community?
• What do we know about this user?
• Who else might benefit from this story? Who else has a vested interest?
• What personal or business goals does this story help the user achieve?

Once you have abstracted the story you can create some acceptance tests if desired, and then make the story more concrete again by reversing the process and seeing where you end up (which is usually with multiple stories):

To make the story more concrete:

Remove the [reason] and replace it with [something], leaving a blank space where [something] was:

As a [user] I want to [blank] so that [something]

Ask the group to come up with possible replacements for [blank] to make the story whole again.

For example, “As an iphone user I want to sms my friends so that I can share my experiences” would become “As an iphone user I want to [blank] so that [I can SMS my friends]”. Then the group might replace [blank] with “select a friend to SMS” and “Attach photos of my experiences to an SMS”.

I sometimes use this process at the beginning of the project to get the team to explore and understand the real user needs and to either add additional stories to our list (by creating more concrete stories to meet the high level needs) or to cut down the number of stories that the team is managing (by leaving them at a more abstracted level). But it can also work well at the point where you are elaborating stories.

The question compass

Many BA’s have their own format for structured interviews and mine is the poorly named “question compass”. This is really just a series of questions I ask to better understand the context around any topic.

The compass looks like this:

Essentially I run through a series of questions for the story:

What do you mean?

• What do you mean by “any noun in the story”; for example “what do you mean by iphone?
• How do you see people “verb”, or how do people currently “verb”. For example “how will users SMS?”
• Keep going through nouns and verbs, not just in the story itself but also in the explanations to your questions.

Why?

• Why do people want to “verb”? Why else?
• Why do we want them to “verb”? Why else?
• Why is this story aimed at that user in particular?
• Continue asking why with respect to the answers you receive until you are thoroughly sick of it, and then ask just a couple more.

Is that true?

• When is that not the case?
• Is that always the case?
• How do we know?
• Is that what users will really do?
• Is it really that user who is getting the benefit of this?
• What information are we basing that on?

So what?

• What is the impact of not having this story?
• What will be different if we deliver this?
• What else may need to change?
• What is the long term impact of not having this?
• What are we expecting will not change?

Use this discussion to form a better understanding of both the story and the user’s needs and then use any of the standard approaches (simply writing code, creating acceptance tests etc) to make the user’s needs more concrete.

That was then – this is now

Rather than exploring the user story in detail, this approach focuses on the user.

Ask the group to tell a story (a tale or narrative) about the user and his or her life today. Have them:

1. Come up with a fictional character who is a typical user (this is sometimes called a persona).
2. Create a short tale describing what the user is doing without the new story being rolled out. Call this “That was then”.
3. Imagine that the new story has been delivered successfully and create a new tale about how the user’s life is different (and hopefully improved). Call this “This is how it should be”.
4. Finally, imagine that the new story is not fully implemented or that the user is not taking full full advantage of of it. Create a tale where the user encounters frustrations and call it “This is how it should not be”.
5. Discuss the gaps between “That was then” and each of the possible futures.
6. Finally – create acceptance tests to describe “this is how it should be” and to avoid or clarify constraints in “This is how it should not be” and to take into account the gaps discussed in step
7. The acceptance tests are then called “This is now” and are used to build the story.

Your own creative approach

“Abstract to concrete” approaches might not be needed for simple stories and might seem like overkill if you are working on a large number of stories on the project. But I find they can be very useful in creating a better understanding of the user’s real needs.

The approaches I have listed here work for me but you should feel free to explore any approach the team would like to apply. The key is to spend time “abstracting” the meaning behind the story before diving into the code writing or listing the “concrete” components of the story (acceptance tests, tasks or technical stories).