Built to Be Finished Later
Decision decks in software organisations have a recognisable page. It lists use cases, one sentence each, sometimes with a subline, sometimes with an expected benefit beside it. Leadership reads the page, compares the lines, and allocates money and people on the strength of them. Nothing on the page distinguishes the line that compresses weeks of analysis from the line written shortly before the deck was due. Both are a single sentence. Both are called a use case.
The name is doing something the sentence cannot. “Use case” names a method, one with a literature, templates, worked examples and a clear account of what a finished use case contains. A line on a slide borrows the standing of that method whether or not any of the method’s work was ever done. The same is true one level down, in the backlog, where a single sentence called a user story borrows the standing of a different method with the same indifference to whether its work happened.
It would be easy to call this carelessness, and it would be wrong. Both forms were designed to be short, and both were designed to be read by people making decisions. What they were not designed for is to be read on their own. Each was a placeholder whose meaning depended on a process that would complete it, and what organisations have carried forward is the placeholder without the process. The artefact has not changed. The practice it belonged to has degraded, and the unit that degraded is the practice: the artefact together with the process that finished it.
What the word promises
Alistair Cockburn’s Writing Effective Use Cases, the standard text on the form, is candid that the term covers a wide range. A use case can be a name. It can be a brief of a few sentences, a casual narrative of a paragraph or two, or a fully dressed document with stakeholders, preconditions, guarantees, a main success scenario and a numbered account of the ways it can fail. Cockburn is explicit that saying a project writes use cases tells you very little until you know which of these it writes.¹
He is equally explicit that the short end of the range is legitimate. The name alone, he says, counts as the first level of precision, and a list of names is a useful thing to have.² So the one-sentence use case on the slide is not a corruption of the form. It is one of its sanctioned states. The question is what that state was sanctioned for.
Built to be finished later
Cockburn orders the work of writing use cases in stages of rising precision: first the actors and their goals, then a brief or a main success scenario, then the conditions under which it can fail, then how the system handles each failure. Each stage costs more than the one before, and the order exists to protect that cost. “Precision is not the same as accuracy,” he writes.³ A statement can be vague and right, or exact and wrong, and effort spent making a wrong goal precise is effort thrown away. So the low-precision list comes first, is checked for accuracy, and only then earns the investment in detail. The short form is a stage, and a stage implies the next one.
Two terms help to keep this straight. Altitude is how high or low in scope a piece of work sits. Grain is how fine the resolution of attention given to it is. The two vary independently.⁴ A use case name is work at a fair altitude and at the coarsest grain there is. The staged process adds grain without changing the altitude, and the name on its own records none of that grain, only the place where it was meant to go.
User stories arrived in the late 1990s with Extreme Programming and made the same arrangement more openly. Ron Jeffries described the story card as “a token representing the requirement”, carrying just enough text to identify it and remind everyone what it is; the requirement itself travelled in conversation and was confirmed by tests.⁵ Mike Cohn, whose User Stories Applied became the standard account of the form, quotes Rachel Davies to the same effect: cards represent requirements rather than document them.⁶ Cockburn supplied the phrase that has stuck to stories since, describing the cards on an early Extreme Programming project as each “a promise for a conversation between a requirements expert and a developer”.⁷
The two forms are closer than their later reputations suggest. Cockburn’s own discussion of briefs notes that some teams never write more than briefs, keeping the rest of their requirements in continual discussion, prototypes and frequent increments.⁸ A brief backed by conversation and a story backed by conversation are the same kind of object at different altitudes. Each is built to be finished later, by people, in a process that the artefact itself does not contain.
Meant for the executive’s desk
The obvious diagnosis would be that these short forms were never meant to leave the team, and that the damage starts when they reach people who make decisions. Both authors rule that out.
Cockburn locates the first moment at which use cases create value in the list of goal names, examined by user representatives, executives, developers and project managers, who estimate cost and effort from it and negotiate what gets built first.⁹ Cohn is as direct. Rough cost and benefit, he notes, are often needed before a project receives funding and approval, and his chapter on release planning describes a manager who writes the stories, researches the market on the strength of them, and decides from their estimated cost whether the product will be built at all.¹⁰ The short form reaching the executive is designed in.
What separates the designed case from the familiar one is what surrounds the decision. In Cockburn’s process the list reaches executives as the opening of a loop: it is reviewed for accuracy, reprioritised, elaborated in stages, and corrected when the failure conditions turn up something nobody had considered. In Cohn’s, the estimates are revisited, measured velocity replaces the guessed one within a few iterations, the customer stays with the team throughout, and the plan built on the first estimates comes with an explicit warning not to trust it too far.¹¹ The decision made on one-liners is provisional because the process around it keeps it provisional.
On the deck, the same decision closes the loop instead of opening it. The allocation is made, the line becomes a commitment, and nothing downstream is organised to test whether the line was accurate. The one-liner has not changed. What it is being used for has, and it is being used for something it was never fit to carry.
Precision without accuracy
Cohn makes an argument about sparseness that is easy to read past. A story card annotated with every detail its author could think of, he observes, invites readers to mistake extra detail for extra precision.¹² A sparse card does the opposite. Two developers discussing a story that says only that a company can pay for a job posting by credit card will not forget that their discussion is abstract; too many particulars are missing for anyone to treat it as settled. In his account the thinness of the card is a feature. It tells the people holding it that the work is not done. He makes the same point about the medium: the low-tech nature of an index card is a constant reminder that stories are imprecise, and the same text held in software starts to look like a formal requirement.¹³
That signal only works for readers who know what the card is. Inside the team, a one-line story reads as not yet worked out, because everyone present knows the conversation is still to come. Move the same line onto a slide in front of people who were never part of that process, and its brevity reads the other way. A single clear sentence looks decided. It looks like the output of thought rather than the prompt for it. The one-liner does not merely lose its backing when it leaves the process. It misrepresents its own status. A slide can show how precise a statement is. It has no way to show how accurate it is, and accuracy was the property the process existed to establish.
Organisations do eventually notice that sparse items are not enough. The usual correction, in practice, is to add content to the item: acceptance criteria, attached documents, longer descriptions, templates with more fields. What is rarely restored is the conversation, and least often the part of it that included the engineers who would build the thing. Requesters, for their part, tend to be reluctant to join a process that asks for their time beyond writing the request. This is a practitioner’s observation, not a measured result, but the effect of the correction follows from Cohn’s own argument. Detail added without the conversation raises precision without testing accuracy, and it produces the misreading he warned of: the belief that the card now holds everything, and that nothing further needs discussing.¹⁴ The inversion no longer stops at the edge of the team. The people closest to the work now read the item the way the audience of the deck did.
The engineers mattered for a specific reason. Cockburn places the second moment of value in use case writing at the point where the writers brainstorm the ways a scenario can fail, because that is where unconsidered stakeholders and missing business rules surface, often sending business experts off to settle what the system should do.¹⁵ That discovery happens when someone who knows the system confronts someone who knows the intent. Cohn opens his book on the same point: requirements are a communication problem between two sides, and if either side dominates, the project loses.¹⁶ Detail written by one side alone is that dominance in document form.
The same route twice
Two forms travelling the same route could be a coincidence. These are not, because they sit at different altitudes of the same planning structure. Cohn is clear that a use case almost always covers a much larger scope than a story, and that a story resembles a single scenario within one.¹⁷ Cockburn uses use case titles as the unit of release planning, and discusses use cases whose delivery is spread across several releases.¹⁸ In the work-item hierarchies that organisations build around these methods, the use case, or its successor under another name, usually sits above the story. Each altitude acquired its own short form, and each short form lost its completing process in the same way.
The routes differ in one respect. At the altitude of the use case, the one-liner leaves the process entirely. It travels upward into portfolios and decks, far from anyone who would elaborate it. At the altitude of the story, the process stays within reach. The team that would hold the conversation is still there, and what happens instead is the correction already described, where text is added in place of a conversation that remains available and goes unheld. The mechanism is the same at both altitudes: an artefact circulates further than the process that completed it, and is then read as though it were complete. A backlog tool can sit as far from the conversation as a board slide does.
Get Bruno Baketarić’s stories in your inbox
Join Medium for free to get updates from this writer.
This is also why the problem cannot be put down to executives misreading slides. It appears wherever the artefact outruns its process, including places where nobody senior is looking.
Cohn’s book contains a small instance of the move, told as a success. Preparing to close a deal with a much larger company, his team was asked for a copy of the requirements. They took their stories out of the system that held them, pasted them into a Word document, and added a cover page and a signature page, after which, in his words, everyone was happy.¹⁹ It was a sensible thing to do in the circumstances, and nothing in the account suggests harm followed. It is worth noticing for what it shows: a set of placeholders, each designed to be finished later, turned into a signed statement of what would be built by changing nothing except the container.
Nor were the forms themselves at fault. Cockburn published the standard account of the fully dressed use case, and in the same book the phrase that marks a story as a promise of a conversation. He held both forms at once, and was clear about which job each was for. The distinction he kept is the one that organisations dropped.
What the reader of the slide cannot know
The consequence lands on whoever reads the slide. That reader cannot tell a one-liner that compresses weeks of work from one that compresses nothing, because the cue that once distinguished them was never in the sentence. It was in the sentence’s position: where it sat in a process, who had worked on it, what stage it had reached. The deck keeps the sentence and strips the position.
It is tempting to call the resulting risk invisible. That overstates it. Anyone can ask to see the use case behind a line, and the question has an answer: either there is a set of scenarios, a record of the failure conditions considered, a trail of conversation with the people who would build it, or there is not. The difficulty is that the setting does not invite the question. A deck is built for comparison across lines, and asking what stands behind one of them breaks the comparison the deck exists to make.
Little of this is new, but one thing has changed its proportions. Writing a plausible one-line use case has always been cheap. With an AI assistant it now takes minutes to produce a dozen, each as crisp as the one that took a month to earn. The share of unbacked lines on any given page rises, and the page looks exactly as it did before.
Both forms were built to be finished later. Their surface was never meant to record whether the finishing happened, and on the slide the surface is all that is left.
¹ COCKBURN, Alistair, [2001] 2011. Writing effective use cases. 23. print. Boston: Addison-Wesley. The Agile software development series. p. 11. ISBN 978–0–201–70225–5. The passage closes a comparison of the same use case written casually and fully dressed, and argues that any process which simply says “write use cases” is incomplete.
² Ibid., p. 143. The second level of precision is the brief. The chapter treats both as working media for managing a large set of use cases.
³ Ibid., p. 17. The four stages, from actors and goals to failure handling, are set out on the same page, with the recommendation to work through them in that order.
⁴ See also “The Detail That Prevents the Detail”, which develops the two measures and names what remains when grain is stripped from work at altitude: strategy in outline, which is to say the deck.
⁵ Ron Jeffries, “Essential XP: Card, Conversation, Confirmation”, XP Magazine, 30 August 2001. The same article notes that teams new to the approach tend to reach for use cases and near-specifications, and that Jeffries has rarely found them to be what was needed.
⁶ COHN, Mike, [2004] 2009. User stories applied: for agile software development. 13. print. Boston: Addison-Wesley. Addison-Wesley signature series. p. 4. ISBN 978–0–321–20568–1. Cohn describes the card as used for planning and as a reminder, and places the substance of a story in the conversation and the tests.
⁷ COCKBURN, Writing effective use cases, p. 224. The project is Chrysler’s payroll system, whose fourteen team members sat in two adjacent rooms; Cockburn cites it as a case where excellent communication made very little writing sufficient.
⁸ Ibid., p. 38. His later chapter on briefs and Extreme Programming (p. 187) adds the condition: this works only where the people who own the requirements sit close to those who design the system, and in most projects, he notes, they do not.
⁹ Ibid., pp. 15–16.
¹⁰ COHN, User stories applied, p. 104. The funding remark is in his chapter on gathering stories (p. 45).
¹¹ Ibid., p. 106. The warning is to use the release plan to set initial expectations and to reset them continually as information arrives.
¹² Ibid., p. 19.
¹³ Ibid., p. 179. Cohn treats the choice between cards and software as open, and recommends starting with cards (pp. 180–181).
¹⁴ Ibid., pp. 19–20. His remedy is to move settled details onto the back of the card as tests, leaving the front for the story and its open questions.
¹⁵ COCKBURN, Writing effective use cases, p. 16.
¹⁶ COHN, User stories applied, p. 3.
¹⁷ Ibid., pp. 137–138. Cohn also distinguishes the two by longevity and purpose, and treats them as different kinds of thing. The reading here, that they are the same mechanism at different altitudes, is this essay’s rather than his.
¹⁸ COCKBURN, Writing effective use cases, pp. 167–170.
¹⁹ COHN, User stories applied, pp. 184–185. The anecdote appears among several reasons Cohn gives for keeping stories after they have been implemented.
