User Stories - How To Get An Earlier And Better Handle Of Your Customers Business Problem

Posted by Optimation Editor on 30 May 2013

Documenting the real business problem that a project team is tasked to solve is easy when you have one local Subject Matter Expert (SME) or business owner to talk to. A discussion in front of a whiteboard will generally enable you to get a good idea of the core problem that needs to be solved. You can then use whatever style of documentation to record it as you like.

This process gets very difficult under any of the following circumstances:

  • When there is more than one SME to talk to.
  • When the team are geographically separated.
  • When there is significant organization prior art that influences the space this problem resides in.

When you add more than one of these into the mix it becomes almost impossible!

One way to assist these separated or disparate groups come to a common understanding of the business problem at hand is to write User Stories in a workshop setting.

While their names are similar sounding, User Stories are not Use Cases. They differ in that Use Cases are typically highly structured and better suited for later in the requirements gathering process. Use Cases often involve a step-by-step flow through a particular usage which can easily start to describe the how rather than the why or what the problem is. A Use Case doesn't encourage discussion about a problem either… partly because they are so structured and partly because they are often either very complex (due to numerous alternate flows) or are very, very specific (an attempt to avoid the complexity of numerous alternate flows!).

This isn't to say that Use Cases are not of use in some circumstances! They can be very useful when you know exactly what the business problem is and wish to document the accepted solution at a low level.

Use Cases generally end up being very large and detailed. This makes estimating them or breaking them into manageable pieces more difficult. They also fail when the solution is not clear and conversation is required between multiple people to find out what the problem is from all angles.

User Stories are intended to state the goals (or the problem they wish to solve) for the users of the system in the language of the business. There should be one User Story per goal and as the User Stories are revised and broken down, they should become small enough and refined enough to be built in a single iteration.

So the idea of User Stories is to get a handle on the business goals and problems very early in the project in such a way that they're solution agnostic, estimate-able and understandable to everyone… especially the business.

User Stories should:

  • Describe the goal that the customer wants to fulfill.
  • Be short and represent small chunks of business value that can be implemented inside an iteration.
  • Avoid all technical detail.
  • Be easy and quick to read.
  • Not be hugely specific, thereby allowing lateral thinking while reading them.


A good way to remember the key qualities of a User Story is through the use of the INVEST acronym:

  • Independent - User Stories work best when they don't overlap and therefore can be implemented in any order or not at all.
  • Negotiable - User Stories are intended to capture the essence, not be a contract. Hence they are negotiable.
  • Valuable - A User Story must be valuable to the customer. If it doesn't create value, why build it? This is related to the Extreme Programming idea of slicing a problem so that every piece of work adds value as opposed to building layers (e.g. a persistence layer) that is feature complete but is unusable because a portion of it isn't required yet.
  • Estimable - A User Story must be estimable. If the team can't estimate the effort required, the story is too vague or big and needs further refinement.
  • Small - A User Story must be small. If it looks like it'll be a lot of work, it may indicate a lack of understanding about the story which should be addressed.
  • Testable - A User Story must be testable. If the customer can't help define how to test it, then perhaps the story isn't clear enough.


A User Story actually consists of three parts:

  • The Story - This is the written description of the story which describes the goal.
  • Conversations - Conversations about the story that flesh out the details and get everyone on the same page about the story.
  • Acceptance Tests - These document details that can be used to determine when the goal of a story has been fulfilled.

The most common form to write a User Story card in, as popularized by Mike Cohn, is:

  • As a <type of user>
  • I want <some goal>
  • so that <some reason>


e.g. as a cab driver I want to be able to quickly find my way to the 10 most frequent destinations so that organization knowledge on the quickest way to a destination is shared among drivers thereby saving myself and my customer time and money.

This story succinctly documents who needs what and why. In this example, the cab drivers' business problem is that he needs to know how to get to the top 10 destinations quickly and efficiently for his customers. The organization has knowledge about this problem which can to be shared amongst the drivers.

You'll also notice that the story avoids all mention of existing processes, methods or technology. In fact, it is devoid of all significant detail! This user story is a great way to start a conversation between the SME's on a project; since nothing is discounted off hand, everyone can offer their own perspective and bring their own understanding of the problem domain to the conversation where they can be openly debated.

A conversation also avoids one of the limitations of the written language i.e. imprecision. Because there is a conversation, people can ask for clarification on points at the time to get the idea across quickly.

This is the reason for a User Story workshop. It is a workshop to get all the SME's and key representatives of the project team together to define, discuss and document the User Stories. It is strongly recommended that these workshops be the first, second and third ways to gather user stories. Writing them in isolation after individual conversations is nowhere near as effective as it neglects the group conversation aspect.

Ideally you need the following participants in your workshop:

  • The business customer(s)
  • The product owner
  • As many SME's on the topic as practical
  • The project team test lead
  • The project team technical lead
  • The project manager
  • Any key organization members with knowledge of existing prior art

With all these people involved in writing, discussing and refining the user stories, you get excellent knowledge coverage across the team and a clear common understanding of the piece of work.

Going back to our example, our SME's have come up with the following options:

  • A paper map
  • A gps unit
  • More extensive driver are training.
  • A paper list of the 10 most common locations and quick directions to each

Each has their benefits and problems… so how do we choose one and how do we prove we've found a solution that is fit-for-purpose under real world conditions?

This is where the Acceptance Tests come in. This list of tests will often be scenarios in the real world that affect the user in reaching their goal. They normally line up with what would have been the alternate flows in a Use Case.

Going back to our cab drivers goal, some tests might be:

  • Test when it is dark outside.
  • Test when the driver is en-route but needs the next step or a reminder.
  • Test when the passenger only knows the name of a place and not the address or general location.
  • Test when the driver is not familiar with where they are starting from.
  • Test when a local event is taking place this week that is very popular (e.g. the World Cup).

With the goal, the conversations that generated some options and the tests, selecting and then estimating the solution should be much easier.

In conclusion, User Stories are a great way to capture the business goal or problem and encourage discussion about the topic. This conversation leads to a shared understanding and a more complete picture of the problem and the acceptance criteria that will prove success.