Exercise 1, Writing User Stories 2017-04-23T23:02:13-08:00

Lesson 3, Exercise 1: Writing User Stories

Need help? Contact us!

Stories are the building blocks of Agile projects and represent the fundamental unit of communication and tracking progress.

Estimated Time
60 minutes

Materials Needed:
Index cards or Post-It notes, pens

You know the standard story format and can a write a good user story.


One of the most important aspects of moving to Agile is understanding “stories”. It takes practice to write good stories, and this exercise allows you this practice. As the Product Owner, you must deliver your customer’s or stakeholder’s perspective and share with the project team what is needed and why.

A user story must provide value to some user. An Agile process is driven by the completion of stories, each of which provides tangible, demonstrable value to the user/customer/stakeholder. A sprint consists of a set of conscientiously prioritized stories. Experience will show that it’s best to use a format for each story that identifies who the user is, what they need, and for what purpose (the why). Such stories are written in this format:

“As a ____, I need a ____ in order to ____”.

The who in a user story could be someone with a particular functional role, who holds a certain title, comes from the perspective of a persona, or embodies the needs and behaviors of a hypothetical user.

The what in a user story details in specific terms the need, feature, or functionality desired by the who. This is what your project team will build into the product or service.

The why in a user story states the value. It presents the needs of your users and customers up front and center.

Here’s an example of a user story that clearly defines the who, what, and why: “As a jazz fan, I need a tuning knob in order to find a jazz station on the radio that I will enjoy listening to.”

Keys to a Valuable User Story

  • Product Owners must have courage to ask for what they believe their users/customers/stakeholders really want.
  • A story must have value to someone. It must make the product better in some way.
    • The story when complete will make a real-world task faster, better, easier to understand, have fewer steps, or collect better info.
    • The high priority stories affect the most users or procure the highest value data.
    • Avoid exotic/one-off stories (i.e. edge cases).
  • “Clean up the bugs we introduced in the last sprint” is NOT a user story because it does not add anything to the product.
  • Remember the INVEST model! Good user stories are:
    • Independent
    • Negotiable
    • Valuable
    • Estimable
    • Small and
    • Testable

Read more about how to make user stories “INVEST-able” >


Grab a colleague (or several) and use a current project or directive (or choose one from the list below). As PO, you want to be able to communicate to the development team what users need. You don’t need to be a technical person to do this, you just need to know what a user wants and why.

These user stories will provide the team with starting points to discuss how they might accomplish something. Instead of saying “I need an event calendar” you might say “A user needs to be notified of upcoming events that are related to topics of interest in her user profile so that she engages with the community about things that matter to her.” This story is more descriptive and gives the team a better understanding of the goal so they can base their solution on intended outcomes.

Believe it or not, one of the critical technologies for this exercise is either index cards (3×5 or 4×6) or Post-It notes. Part of the reason you use paper technology is so you can easily move stories around, reorganize and reprioritize them, and throw them away when done. The small size of the cards and notes ensures that you will not write too much into each story.

A story is a promise to have a conversation later between the end-user and developers. Your goal in writing stories is not to work out details, but to discover the most important goals for your project and to organize a project into discrete, testable chunks.

Potential project goals that will help you practice story-writing

  • Clean out the garage
  • Develop a static website that informs people about dietary impact on breast cancer
  • Develop an app for playing “Conway’s Game of Life
  • Develop an app for playing tic-tac-toe
  • Write a how-to guide for planting a garden specific to your locality

Choose a project goal for the workshop from the list above. If you have a project or directive in mind, feel free to use that.


Everyone writes stories for 15 minutes that will advance the project goal.

As new stories are written, you may discover ways to improve previously written stories. You may realize that many small, specific stories can be rolled up into a bigger story; or a big story might be split into two or three pieces.

During this time, stories can be rewritten or reworded to make each story as self-contained as possible. This means that a developer should be able to read the story, understand what a user is hoping to do, and create a feature that enables the user to do it. Additionally, a self-contained story should be understandable when read back to the user, without a lot of explanation needed.

The stories are prioritized into an absolute order.

There can only be one #1, with the highest priority at the top. There are no ties; a specific order must be chosen. Open discussion is allowed, but in the end, you as the Product Owner have authority to set the actual priorities. Things might change as you discover new information, and the backlog can be re-ordered — but at any one time it is an absolute ranking.

Check the format of the user stories.

Remember to keep them in the correct format: “As a ____, I need a ____ in order to ____”.

Think about grouping the stories into sprints.

Now that your stories are prioritized, do you see how you might group them into sprints? The grouping is usually done by the project team, but it’s a good exercise for you to review now to get an idea of how complete your stories are and to recognize if there are gaps.


  • It may feel overwhelming to create user stories to describe everything you are imagining for this project. Start from where you are and remember your product backlog will continue to grow throughout the life of the project.
  • You will get better at creating user stories over time, but this exercise should produce enough user stories that a sprint could be planned. If not, keep trying.

Back to Lesson 3