Cohn M., User Stories Applied (2004)

 |  Book Reviews

In a requirements flow, user stories come after use cases and before requirements specifications (whether SbE or traditional). This book is a foundational resource for exploring the 'how' and 'why' of user stories.

Contents

Summary

The core of the book is the explanation of what user stories are, how to gather them (Part I. Getting Started) and how to estimate and plan them into the development process (PART II: Estimating and Planning).

The book as well includes a basic example (PART IV: An Example) and considers various topics like, why apply user stories, using them with Scrum and user stories smells (PART III: Frequently Discussed Topics).

Each chapter contains a concise summary section listing key ideas. Many chapters contain sections "Developer Responsibilities" and "Customer Responsibilities" for better process alignment.

The book is a little wordy. To an extent, it dismisses traditional requirements gathering as a rigid, nonsensical process—which it has never been. My review focuses on key aspects of user stories that are relevant to beginners, filtering out what’s obvious or purely argument-driven.

What User Stories Are

A user story describes functionality that will be valuable to either a user or purchaser of a system or software. User stories are composed of three aspects:

  • a written description of the story used for planning and as a reminder;
  • conversations about the story that serve to flesh out the details of the story 1;
  • tests that convey and document details and that can be used to determine when a story is complete (ch. 6);

Format

Here is the widely accepted format (p. 81):

I, as a (role), want (function) so that (business value)

In practice it could sound like:

As a (software developer) I want to (understand user stories) to (improve the quality of products) I develop.

Note the format is adapted for more convenient wording but the sequence of notions (role, function, business value) should be always kept the same across projects and teams for uniform understanding.

User Roles

(p. 31)

Here are the example roles for a user story.

user roles example

Six Attributes

Six attributes of good stories (INVEST) (p. 17):

  • Independent
  • Negotiable
  • Valuable to users or customers
  • Estimatable
  • Small
  • Testable

Guidelines for Good Stories

(ch. 7)

Guideline Short Description
Start with Goal Stories Begin by identifying the goals user roles have for the system.
Slice the Cake Split large stories to provide end-to-end functionality.
Write Closed Stories Write stories that finish with a meaningful, accomplished goal.
Put Constraints on Cards Annotate cards with "Constraint" for non-functional requirements.
Size the Story to the Horizon Write smaller stories for near-future work, larger ones for distant.
Keep the UI Out as Long as Possible Avoid user interface details early to prevent premature constraints.
Some Things Aren't Stories Use other formats for requirements not suitable for user stories.
Include User Roles in the Stories Use the identified user roles when writing stories.
Write for One User Write stories from the perspective of a single user.
Write in Active Voice Write stories using active voice for clarity.
Customer Writes The customer should have responsibility for writing stories.
Don't Number Story Cards Avoid numbering story cards; use short titles instead.
Don't Forget the Purpose Keep stories brief as reminders for conversations; don't add excessive detail.

Gathering Stories

Here are the techniques to gather user stories (p. 45), that are basically business analysis and marketing techniques:

  • User interviews
  • Questionnaires
  • Observation
  • Story-Writing workshops

[VS]: In fact there are much more user stories gathering techniques that expand and build on the basic approaches above:

  • Focus Groups: Small, diverse groups of users discuss their needs and pain points;
  • Job Shadowing: Observing users in their real work environment over time;
  • Prototyping & Usability Testing: Early mockups or prototypes help users articulate needs;
  • Customer Journey Mapping 1, 2: Visualizing user interactions to identify pain points and opportunities;
  • Role-Playing: Acting out user interactions to uncover implicit needs;
  • Analytics & Log Analysis: Reviewing usage data to identify common workflows;
  • Social Media & Community Feedback: Gathering insights from forums, reviews, and discussions;
  • Competitive Analysis: Studying competitors' products to identify missing features;
  • Feature Mining: Extracting insights from existing documentation or legacy systems;
  • Mind Mapping: Brainstorming user needs in a visual, hierarchical format;
  • Behavior-Driven Development (BDD) Workshops: Collaborative sessions using structured "Given-When-Then" scenarios;
  • Event Storming
  • Domain Storytelling

User Proxies

We do not have to limit user stories gathering only to users (p. 55). We want to use user proxies for that to better understand or verify the business values obtained from users. Proxies and business experts are helpful in cases when users do not exist yet.

Here is the exemplary list of user proxies:

  • The Users’ Manager
  • Salespersons
  • Domain Experts
  • The Marketing People
  • Former Users
  • Trainers and Technical Support
  • Business or Systems Analysts

Acceptance Testing

(p. 67)

The Extreme Programming suggested test-first approach in 1999 then becoming TDD and later A/TDD.

In line with the principles from the above resources, though a bit dated, here is the by-the-book checklist for acceptance testing:

  • Write tests before coding
  • The customer specifies the tests
  • Testing is part of the process
  • The number of tests must cover all the known cases;

[VS] The acceptance testing with no specified requirements followed by usage scenarios is quite awkward endeavor. The modern acceptance A/TDD is great using BDD/Gherkin scenarios and SbE 1.

Estimations and Planning

(p. 85)

[VS] This part of the book presents the brief introduction of estimation and planning that goes well along the main subject of the book - user stories. For more detailed info on the subject refer to Cohn M., Agile estimating and planning (2006) book.

The Agile estimations are vague because of agile iterative 2 nature, they are not commitments. Each project estimations fail at the beginning and expected to get better as the team gets farther into the project provided it applies whatever the simplest way of estimations it choses, inspects and adapts and follows other effective agile techniques.

Estimating User Stories

Goal: Estimate size/effort of user stories using story points (relative measures like complexity or effort). Done as a team, with developers estimating and the customer clarifying. Techniques like Wideband Delphi and triangulation (p. 90) ensure consistency.

Planning a Release

Goal: Balance functionality with timeline by allocating stories to iterations. Uses prioritized stories, release date, and velocity (expected story points per iteration). Plan adjusts as more is learned.

Planning an Iteration

Goal: Refine upcoming iteration’s stories into tasks, estimated in ideal time. Entire team + customer discuss, break down work, and developers commit to tasks.

Measuring and Monitoring Velocity

Goal: Track progress using velocity (story points completed per iteration). Charts (Planned vs. Actual, Cumulative Story Points, Burndowns) visualize progress. Only finished stories count.

Other Topics

User Story Smells

(p. 157)

Smell Name Description
Stories Are Too Small Estimates for small stories change dramatically based on implementation order, complicating planning and scheduling.
Interdependent Stories Difficulty planning iterations because stories rely on one another, often due to incorrect sizing or splitting.
Goldplating Developers add unplanned or unnecessary features beyond the agreed-upon scope.
Too Many Details Excessive upfront detail gathering or documentation, reducing conversation and shared understanding.
Including User Interface Detail Too Soon Stories contain user interface design specifics prematurely, potentially limiting design flexibility.
Thinking Too Far Ahead Trying to define too many future details, contrary to the iterative nature of stories and emergent requirements.
Splitting Too Many Stories Stories are frequently split during iteration planning, often indicating an underlying issue with story size or preparation.
Customer Has Trouble Prioritizing Difficulty for the customer in ordering stories, possibly because they are the wrong size or lack clear business value.
Customer Won't Write and Prioritize the Stories The customer avoids taking responsibility for defining and ordering stories, often due to organizational or cultural factors.

Using Stories with Scrum

(p. 165)

I urge you to study the chapter yourself along with McConnell S., More Effective Agile (2019) book that describes Scrum application for better understanding.

Footnotes

  1. It is not defined explicitly enough where and how to capture the results of the conversations - that in fact must become the requirements specifications - within user story process. The book suggests "jotting down the details of the story on the back of the card". The explanation from 1999 that is hard to accept in the 2020s. The least you can do here is to write the conversation details on Jira's (or similar software) user story item. However Agile tries to be flexible, the software requires completely deterministic requirements otherwise you never create the final product. So you better arrive at formal requirements specification (e.g BDD plus Specification by Example) early to not waste time with Agile vague approaches. ↩ ↩2

  2. The iterative nature of Agile manifests in gradually acquiring knowledge about the system being developed. As a result, later stages may reveal insights that contradict earlier findings. This inevitably leads to wasted effort, rework, and replanning. Hence, commitments in Agile are highly uncertain.

    If you want better estimations, less waste in reworks and doing things right from the first time (principle #5) you will inevitably end up applying requirements specifications (BDD/Gherkin scenarios and SbE) and other engineering approaches (modeling, code design with UML etc.) ↩