Concept 1 of 4

Requirements and use scenarios

4 questions test this

The Build course covers three framework boxes, and Pragmatic Institute names them directly. Requirements, Use Scenarios and Stakeholder Communications. The first two are the handover from market knowledge to the team that will build something.

What a requirement is here

The framework's wording is worth reading twice. A requirement articulates personas and their problems so that the appropriate products can be built. It does not describe a mechanism.

The reason is division of expertise. The product manager knows the market. The development team knows what is cheap, what is expensive and what will break in two years. A requirement that arrives as a specified solution collapses those two into one and discards the half that was better informed about implementation.

A useful requirement carries the persona, the problem in their terms, evidence of how widespread and urgent it is, and what would count as the problem being solved. What it does not carry is the shape of the screen.

Use scenarios

A use scenario is the problem told as a story with the context still attached. Who the person is, what they are trying to accomplish, what is happening around them, what they do today and where it goes wrong.

The context is the point. A requirement stripped to a single sentence loses the facts that decide the design, such as the fact that this happens on a phone in a loading bay, or during a two hour window at month end, or while three other people wait for the result.

The framework calls use scenarios one component of requirements rather than a substitute for them. The requirement states the problem and its prevalence. The scenario makes it concrete enough to design against.

What this gives development

Room to solve it better. A team that understands who has the problem and why it matters will often propose something cheaper and more effective than the solution the product manager had in mind, and can make sensible calls on the hundred small decisions that never make it into any document.

It also gives them something to check against. When a question comes up mid sprint, the scenario answers it more often than the acceptance criteria do.

Prioritising the requirements

The framework wording includes prioritise as well as articulate. Requirements compete for the same capacity, and the ranking is done with the market evidence attached to each one rather than by who asked. That is the subject of prioritising with market data, and the reason requirements are written with their evidence in the first place.

Common misconceptions

A requirement specifies what the system must do.

In this framework a requirement articulates a persona and their problem. Specifying the mechanism removes the design decision from the people best placed to make it, and hides the reasoning that would let them make a better one.

A use scenario is a test case.

A test case checks that a built thing behaves correctly. A use scenario describes the situation the person is in before any solution exists, which is what makes it useful as an input rather than a check.

Development does not need the market context, only the acceptance criteria.

Acceptance criteria say when to stop. Context says which of the several valid implementations is the right one. Teams given only the first make reasonable choices that solve a slightly different problem.

4 questions test this concept

The framework describes Requirements as articulating and prioritising personas and their problems so that the appropriate products can be built. What does this rule out?

  • AIncluding acceptance criteria in a requirement
  • BInvolving developers in writing requirements
  • CPrioritising requirements against one another
  • DSpecifying the mechanism, since that removes the design decision from the people best placed to make it and hides the reasoning that would let them make a better one
Check whether it stuck.

One per page, with a worked explanation.

Start the set
Related material
Book
User Story Mapping, On keeping the whole journey visible while breaking work down.
Book
User Stories Applied, On writing items that carry the user and the intent.
Book
Fifty Quick Ideas to Improve Your User Stories, On concrete improvements to items that have gone vague.
Book
Impact Mapping, On connecting a deliverable to the persona and the goal behind it.
Template
PRD, one page, Problem statement, supporting evidence, the proposed change, success measures, and an explicit out-of-scope list. Fits on a single page.