The term “user story” is emerging in the practice of Agile software development, but the notion is very applicable in all types of products and services. A user story is a simple, one-sentence description of what an actor (any person or entity with behavior that expects things of a particular system) would find valuable to be able to do as the actor interacts with a product or service. The simplicity is part of the power. A user story is written in language that the most basic user and most sophisticated system analyst can readily understand – and which they can review and refine together to reach a shared understanding. That’s a sometimes rare, and always valuable, thing.
Examples of User Stories
A user story is a complete sentence with an actor, a verb and enough context to convey clear meaning. Examples include:
- “A service technician can anticipate network degradation.”
- “A patient understands the status of her procedure as she is going through it.”
- “The search engine suggests alternative spellings that may be more effective.”
User Stories Are Not Use Cases
The focus on verbs makes many people think of use cases. While the verbs and functional view are a common thread, use cases are most often employed to detail requirements into the underlying workflows and exceptions that are implied. In that way, use cases decompose requirements to uncover underlying action that is worth understanding.
User stories, on the other hand, are generally more compositional, starting as rough sketches that support the discovery of stated and latent requirements. User stories start with context data and needs data. They may state or imply functionality that should be better understood. A verified and valuable user story may become a requirement. A user story is discovery.
Use cases, on the other hand, often start with requirements. Use cases detail workflows, starting conditions and exceptions. A use case is for decomposition.
User Stories in Lean Six Sigma Context
In the beginning, a user story does not presume to be a requirement – it is just a form for articulating a fledgling understanding back and forth with customers and among development people. No fancy analysis is called for at that point, because there isn’t enough information to be dangerous. The one-sentence, verb form of a story gently enforces two important things:
- Each story is a small enough nugget of functionality to be unambiguously understandable.
- Stories are solution-free (leaving design options as flexible as possible when it comes to solution alternatives).
Lean Six Sigma encourages and guides the connecting of measures and tests with key stories to supplement understanding about what is important to address. Functionality (verbs) tells an important part of the story, but it often begs clarification about how fast, how many, at what success rate, etc. – the performance measures. This brings test thinking into the picture from the very beginning. A user story can evolve to a number of useful Lean Six Sigma links, as shown in the following example.
| Table 1: A User Story and Lean Six Sigma | |||||
|
Priority |
User Story |
Performance Measure/Tests |
Baseline |
Targets |
Size |
|
7.5 |
A patient understands the status of her procedure as she is going through it. |
Post-procedure comfort rating False alarm rate |
82 0.005 |
> 90 < .0001 |
30 |
In this example, regarding the user story, the question can be asked: “Where did we learn about this?” This is the source context and needs data. Regarding the performance measure tests, the question can be asked: “What solution choices can be identified?” Potential solutions include:
- Hand-held display
- Wireless headphones with music and updated messages
- Icons on main monitor in her view
The following figure is laid out in four quadrants that depict zones involved in the course of product and service development. Zone I is the user domain, where the real problem, customer value and risk reside. Context and needs data gathered there provide the clues and seeds of user stories. The stories that survive review and refinement carry the understanding of the stated and latent needs into the system (II). There, Lean Six Sigma can be used to connect measures, baselines and targets, as appropriate – and develop the measurement systems to help analysts to see the right things clearly enough as they proceed.
Y to x flowdown informs Design about the results drivers and constraints. When analysts move to consider “How to deliver?” they move to the solution space, in quadrant III, where Lean Six Sigma helps them to predict and closed-loop tune performance as it emerges.
Verification and test happen early and often, fueled by the insights kindled on the front of the ‘V’ back in Quadrants I and II. Test-driven development and test-driven design are natural in this picture. In quadrant IV, what started as a user story is delivered into actual use as a working feature. User story language still conveys what the feature is accomplishing, but at this point it is not hypothetical, it is real and verified.
Find Your Own Fit for User Stories
The simple construct of a user story, with the right connection to measures, tests, prioritization and performance targets, can find its way to support many kinds of development and other value-focused work. Service level agreements, service-oriented architecture, model-driven development and many other product and service constructs are ripe for the tailored application of some direct or derivative form of user stories. Additional information about and practical guide to user stories can be found in the book User Stories Applied by Mike Cohn.
