Use Case vs User Story

Allen Holub explains the difference between a use case and a user story -

Bob Martin describes use cases pretty well in his book Clean Architecture: 

"A use case is a description of the way that an automated system is used. It specifies the input to be provided by the user, the output to be returned to the user, and the processing steps involved in producing that output." Put another way, a use case describes how a user uses a computer program. A use case describes how to use an existing program, or, if the program can't do everything necessary, it identifies aspects of the program we'll have to create. Use cases live in the implementation space.

A user story, on the other hand, is a description of the user's work. It is literally the user's story. The story describes a domain-level problem and, when fleshed out, describes how a user solves that problem when working at the domain level. The story describes the user's work, not ours. A story does not describe or specify a computer program at all. It does not describe how a computer program works. Stories live in the domain—in the problem space.

Neither use cases nor stories specify programmer tasks. You cannot represent them as "tickets" (despite what Jira claims). They are part of the architectural process, not the construction process. That's true even when architecture and construction are concurrent. You cannot estimate either because neither has anything to do with the construction.

Both use cases and stories are useful in different ways. Both are elements of the architectural process, but you cannot even think about implementation until that architecture, or a portion of it, is at least roughed out in your head. A skilled programmer can work on both simultaneously.

Comments

Post a Comment

Popular posts from this blog

A Guide to Spec-Driven Development: Plan, Implement, and Validate

Image
The DeepLearning.AI short course on  Spec-Driven Development with Coding Agents  introduces a professional paradigm shift in how we build applications using agentic coding assistance.  Rather than "vibe coding"—where developers rely on quick, high-level prompts that often lead to technical debt—SDD brings engineering rigour back to the process.  Agent is the muscle, but the SPEC is the brain - In this workflow, the human takes on the role of a senior architect, providing the "blueprints" (specifications), while the AI agent acts as the "muscle" to implement those designs.   The 1 Hour 20 Minute video course has 15 short lessons - Introduction - 4 mins Why spec−driven development? - 4 mins Workflow overview - 3 mins Set up your environment - 5 mins Setup - 1 min Creating the constitution - 10 mins Feature specification - 3 mins Feature implementation - 1 min Feature validation -...
Read more

This Week I Learned - Week 16 2026

This Week I Learned -  * From The Batch - - Alignment training teaches LLMs to behave like assistants, but it tethers them to that behavior only loosely. Beyond alignment training, system prompts act as behavioral guardrails, but motivated users can bypass them.  - The lengths of tasks completed autonomously by AI agents have doubled roughly every seven months, according to METR, an independent testing organization - LLMs' knowledge is still relatively limited with respect to infrastructure and the complex tradeoffs good engineers must make...finding infrastructure bugs — say, a subtle network misconfiguration — can be incredibly difficult and requires deep engineering expertise.  - Research involves thinking through new ideas, formulating hypotheses, running experiments, interpreting them to potentially modify the hypotheses, and iterating until we reach conclusions. Coding agents can speed up the pace at which we can write research code. - Meta has pivoted from its ope...
Read more

Uncle Bob vs. Grady Booch: Rethinking Code Reviews in the Age of AI

Image
In response to a question about the feasibility of effective code reviews for large (e.g., 500-line) AI-generated PRs like those from Claude, especially when reviewers lack deep codebase familiarity in new projects or fast-paced environments, Uncle Bob Martin and Grady Booch have contrasting views Uncle Bob Martin advocates metrics-based oversight (test coverage, complexity, dependencies) and higher-level management over line-by-line AI code review, while Grady Booch stresses manual verification for vulnerabilities, dead code, and performance factors. Uncle Bob Martin : " I don’t review code written by agents . I measure things like test coverage, dependency structure, cyclomatic complexity, module sizes, mutation testing, etc.  Much can be inferred about the quality of the code from those metrics. The code itself I leave to the AI.  Humans are slow at code. To get productivity we humans need to disengage from code and manage from a higher level." Grady Booch : "Unlike B...
Read more