From Use Cases to User Stories: The 3Cs, INVEST and When Use Cases Are Still Better

Version note: This post is conceptual; the three parts of a story follow Ron Jeffries' XP (Extreme Programming) article "Essential XP: Card, Conversation, Confirmation" dated August 30, 2001, and the qualities of good stories and tasks follow Bill Wake's 2003 article published on xp123.com.

Guess First

Elicitation is done. Selin, Emre and Ayşe first write bulk ordering as a use case, because the information from elicitation comes as a flow: the list is entered, validated, distributed to delivery points, sent for approval, shipped. The result is a seven-step main flow and seven alternative flows.

Now the team will split the use case into user stories that can be delivered in sprints. There are three proposals. Emre: "One story per step, seven stories." Ayşe: "The main flow is one story and each alternative flow is a separate story, eight in total." Selin: "Some are stories, some are acceptance conditions of other stories." Which is right? How many stories come out? Write down your own number before reading on.

The Institutional Order Use Case

We covered use case diagrams, actors and the fields of Cockburn's template in detail in the "Use Case Diagrams and Specifications" post of the UML and Modeling series; we don't repeat the template here and only use the flows. Following the glossary decision from the previous post, the use case is called "Place Institutional Order" and the primary actor is the school's purchasing officer.

Main success scenario: (1) The purchasing officer starts a new institutional order with the institution's account. (2) They enter the list of ISBNs and quantities. (3) The system validates each row against the catalog and shows the result row by row. (4) The purchasing officer distributes the rows to the institution's delivery points. (5) The system applies the institutional discount and shows the total. (6) The purchasing officer enters the institution's purchase order number and submits the order. (7) The system saves the order, passes it to the warehouse for shipment and queues the invoice for the ERP transfer.

Alternative flows: 2a the list has no ISBNs, only titles; the purchasing officer searches for books by title. 3a an ISBN is not in the catalog; the row is flagged and the order cannot be submitted until it is fixed or removed. 3b the same ISBN appears on more than one row; the system suggests merging them. 5a the order does not meet the institutional minimum quantity rule (the rule itself is still an open question). 6a the total exceeds the institution's approval limit; the order moves to "Awaiting Approval" and continues once the institution's accounting officer approves it. 7a stock for a book is insufficient; the institution chooses between a partial shipment and waiting. *a the purchasing officer gives up at any step; the list stays as a draft.

The value of a use case is that it shows the whole at a glance. Anyone reading this text immediately sees which situations were considered and which are still unanswered (5a). What is missing is how this whole fits into a two-week sprint.

From Flows to Stories

The main idea: each alternative flow can be a separate story, but it doesn't have to be. What makes an alternative flow a separate story is that it gives the user value on its own and can be delivered and demonstrated separately. A rule that has no meaning without the main flow stays as an acceptance condition of a story.

The result is seven stories and a few acceptance conditions spread across them. Of the three proposals in Guess First, Selin's is the closest. Emre's "one story per step" is a trap: the step "the system validates the rows" gives nobody value on its own; validation means nothing without entering a list and submitting an order. Splitting step by step is a close relative of splitting layer by layer, which we will look at later.

The table has another hidden advantage: every story knows which part of the use case it came from. Anyone who knows that 3a and 3b are acceptance conditions of the first story can be sure both cases get tested when that story is tested.

Card, Conversation, Confirmation

The idea of the user story comes from XP, and its plainest description is Ron Jeffries'. In his 2001 article Jeffries writes "The card is a token representing the requirement.": the card is not the requirement itself but a marker standing for it. The real content of the requirement passes between the customer and the developers in conversation; the agreement reached at the end of the conversation is confirmed with acceptance tests. Card, conversation and confirmation are the names of these three parts.

Here is the card for the first story at Bookstore. Front: "Institutional order: order by pasting a list. As a school purchasing officer, I want to order by pasting the list of ISBNs and quantities I collected from teachers, so that I don't have to search for 240 books one by one." On the back, three sentences for confirmation: when a valid 240-row list is pasted, 240 rows and the total are shown; an ISBN not in the catalog is shown with its row number and the order cannot be submitted until that row is fixed; the same ISBN written with and without dashes counts as the same book.

What is not on the card is the conversation itself: Emre asking "what about the ISBNs of old editions?", Gül mentioning her fixes list, Selin deciding not to include it in the first release. That conversation gets noted somewhere, but it does not replace the card. The card is the most visible and least important part of the trio; it is usually exactly where teams spend the most effort in their tracker.

The confirmation part is the core of the rest of the series. The three sentences on the back will turn into rules and examples with Example Mapping in post 05, into Gherkin scenarios in post 07, and into running tests in post 08.

The "As a / I want / so that" Template and Its Limits

The role, want and reason template on the front of the card, according to the Agile Alliance glossary, emerged in 2001 in the Connextra team in the UK and has become almost synonymous with user stories. Its real contribution is reminding the team of two questions on every story: who wants this, and why?

The template's limits come from the same place. The role part carries information only when roles really differ; a story starting with "As a user..." says nothing. In bulk ordering, the purchasing officer, the institution's accounting officer and Bookstore customer service are different roles, and whose eyes you write the story through changes its acceptance conditions.

The "so that" part is the most neglected and the most valuable. A reason ending in "...so that I can place an order" repeats the want. "...so that I don't have to search for 240 books one by one" gives the team a criterion: if the solution doesn't remove the searching, it has missed its goal.

The template also doesn't carry context. The fact that the purchasing officer does this once a year, at the end of August, while waiting for budget approval is not in the role sentence, yet it deeply affects the design. In the "Outcomes over Output" post of the Introduction to Product Management series we looked at the job story format, which fills this gap; the two formats can be used together. Finally, the template is not mandatory. A short, clear sentence the team agrees on is better than one forced into the template.

Testing with INVEST

In 2003 Bill Wake gathered six qualities of a good story under the acronym INVEST. Let's test each letter with one of Bookstore's stories:

Wake also accepts that independence can't always be achieved; the goal is not zero dependencies but being able to order stories by value rather than by dependency. The advice behind the Estimable letter is practical too: if a story is too vague to estimate, set aside a time-boxed spike to learn, and define the spike's output with a concrete sentence such as "a test invoice was transferred to the ERP and the transfer time was measured". We'll look at ways to split stories in detail in the next post.

Epic, Story, Task

The three words describe different levels of detail, and when they get mixed up the backlog becomes unreadable. An epic is a large piece of work that does not fit in a single sprint and gathers a group of stories under its umbrella: "Institutional order" is an epic. A story is a change in user-visible behavior that can be delivered and demonstrated on its own: "Place an institutional order by pasting a list." A task is a step the team takes to finish a story, and the user doesn't see it: "a function that strips dashes and spaces from ISBNs", "adding a delivery point column to the order line", "the Angular component for the validation result table".

In the same article Wake suggests a checklist for tasks as well: SMART. It should be clear who owns a task, when it is done and which story it serves. Stories are ordered together with the Product Owner; tasks are the developers' own plan and live under the story in the backlog.

When Is a Use Case Still Better?

The spread of user stories did not make use cases unnecessary. In some situations a use case gives something a story can't: keeping the order and the branches of the whole in a single text.

Multi-step, rule-heavy flows are the first example. The library's process (first a price quote, internal approval of the quote, the order, delivery, then the invoice after delivery) is a flow where the order of steps and which step to go back to in which situation matter. If you spread it over seven independent stories, the answer to "can an order be placed before the quote is approved?" does not live in any single story.

Regulated domains are the second example. In work where an auditor wants to see the whole behavior of the system, exceptions included, in one document (payments, healthcare, public procurement), scattered stories do not meet that need; a use case becomes a reference that can be kept together with test evidence.

Contract-based work is the third. If acceptance in a fixed-scope project is done against a signed scope document, having that document in the form of use cases shows both sides beyond dispute what was delivered. Stories can still be used as the unit of delivery; the use case remains the record of scope.

There is also an approach that tries to combine the two worlds: Use-Case 2.0, published by Ivar Jacobson and his colleagues in 2011, splits a use case into vertical pieces called "use-case slices", each of which can be tested and delivered separately. Our table above is a light application of that idea: the use case is the map, stories are the units of delivery.

In Production

Link each story to the use case part it came from. Putting a reference such as UC-BULK-01 / 6a on the first line of the story description lets you answer "where did the approval limit rule come from?" six months later with a single search. Update the use case as stories are finished; a use case that contradicts the stories is more harmful than none at all.

Keep track of the conversation. Decisions made in conversation, especially ones like "we're not including this in the first release", should be written in the story's comments or a linked note. Otherwise, when someone asks in the demo "why don't old edition ISBNs work?", nobody remembers that the question was answered.

Don't take a story into a sprint without confirmation. A story with an empty back means "done" will be argued about at the end of the sprint. We'll write and clarify acceptance conditions in detail with Example Mapping in post 05.

Common Pitfalls

The first pitfall is writing technical work as a story: "As a developer, I want to create the database tables for institutional orders, so that I can store orders." The sentence fits the template but gives nobody value and hides a task of some story. The tables are created inside the first story that uses them. If there really is technical work that must be done on its own (such as the ERP spike), write it under its own name without disguising it as a story.

The second pitfall is turning a story into a mini specification document. A story with three pages of screen descriptions, field lengths and error messages in its description makes the conversation look unnecessary; the team reads it, implements it and never asks the questions that weren't written down. The card should stay short; detail is produced in conversation and recorded in confirmation.

The third is the opposite: a story with only a title. A card titled "Institutional order - approval" with no description and no acceptance condition is a sign that the conversation never happened.

The fourth is making each step of the use case a separate story. When "the system validates the rows" and "the system shows the total" are delivered separately, neither gives the user value; that was the problem with Emre's proposal.

The fifth is turning the "so that" part into a repetition of the want. The reason is the criterion the team will use to judge the solution; "...so that I can place an order" is not a criterion.

A Small Experiment

★☆☆ Test five stories from your backlog with INVEST. For each, mark the weakest letter and write in one sentence what should change in the story to strengthen it.

★★☆ Write a short use case for a workflow you know: a main flow and at least four alternative flows. Then fill in this post's table for your own use case: which part is a story, which is an acceptance condition? Justify each decision with the question "does it give value on its own?".

★★★ Find a story in your team's tracker that starts with "As a developer" or a similar role. Either turn it into a real user's story or move it under a story as a task. Discuss with the team which one you chose and why.

We have seven stories and a use case, but one question is still open: which of them ship in early September? In the next post we place the stories on a story map, find the walking skeleton, look at ways to split large stories and choose the first release.