đź’ł Secure Payment

Full-Service Web & Software Agency · Klamath Falls and Redding

Practical exercises in creating user stories

Work with Sean

Writing user stories is a craft, and a craft takes reps. Here are eight exercises, from finding a need to writing a criterion a test can fail. Use a real project if you have one; a made-up one works too.

Exercise 1: Identify user needs

Objective: Identify user needs and pain points.

  1. Select a real or hypothetical software project.
  2. Create a list of user roles or personas that might interact with the software.
  3. For each user role, brainstorm and document potential user needs and pain points.
  4. Prioritize these needs based on their importance and potential impact on the user experience.

Exercise 2: Craft user stories

Objective: Practice writing user stories.

  1. Take the prioritized user needs from Exercise 1.
  2. For each need, use the user story template: “As a [type of user], I want [an action] so that [benefit/value].”
  3. Keep each story to one sentence that names one person, one action and one reason.
  4. Include acceptance criteria that define the conditions for completing each story.

Exercise 3: Review and refine user stories

Objective: Collaborate to improve the quality of user stories.

  1. Form a group with the people the stories affect: the owner, the webmasters on the job and anyone else with a stake.
  2. Share the user stories created in Exercise 2.
  3. Read each story aloud, run the INVEST check on it, and ask what it leaves out and how a test could fail it.
  4. Refine the user stories based on the feedback received.

Exercise 4: Prioritize user stories

Objective: Practice prioritizing user stories based on user impact and business value.

  1. Take the user stories as refined in Exercise 3.
  2. Sort the stories into required and optional, the two lists a written scope keeps apart, by their importance to the user and the project.
  3. Ask of each story what its users lose while it waits; the answer sets its place in the order.

Exercise 5: Create a user story map

Objective: Visualize the flow of user stories.

  1. Take a set of related user stories.
  2. Arrange them in a logical sequence to create a user story map.
  3. Make the map the user’s journey through the software, in the order they meet each story, so you can see how the stories connect and build on each other.

Exercise 6: Create an “epic” user story

Objective: Practice creating higher-level user stories known as “epics.”

  1. Identify a broad user need or feature that encompasses multiple related stories.
  2. Write the epic as one story for the whole goal, and leave the details to the smaller stories beneath it.

Exercise 7: Refine acceptance criteria

Objective: Improve the clarity and testability of user stories.

  1. Take a set of the user stories refined in Exercise 3.
  2. Review the acceptance criteria for each story.
  3. Mark each criterion a test couldn’t fail, or that two people would read two ways.
  4. Rewrite each criterion until a webmaster could write a test from it.

Exercise 8: Simulate user feedback

Objective: Experience the role of a user providing feedback.

  1. Select a user story from your project.
  2. Act as a user and use the user story to interact with a prototype or the software.
  3. Give feedback in the user’s voice: what felt easy, what got in the way and where you got stuck.
An epic split into stories An epic, As a customer, I want to order online, splits into three stories side by side: choosing, paying and confirming. A highlighted arrow under them runs left to right, in the order the customer meets them. an epic in a story’s clothesAs a customer, I want to order online.choosingpayingconfirmingin the order the customer meets them
The epic from the exercise, split: choosing, paying and confirming are three stories, each a line of its own. The violet arrow is the customer’s journey, the order a user story map lays them out in.

Each exercise ends in something another person can check: a list of needs, a story in the template, a criterion that can fail. For practice on the code side, the lecture Basic Functional Programming TypeScript Knowledge ends with an exercise of its own: one pure function over a product list.

The next lesson, on collaborative sessions, reviews the stories with the people they affect.

Copyright Sean Paul Payne Dinwiddie
All Rights Reserved