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

Estimated Time

• 60 minutes for the workshop (full team)
• Two hours of preparation (Agile Project Manager)

Materials Needed
Index cards or Post-It notes; pens.

Outcome
Everyone knows the standard story format, knows some of the INVEST acronym, and can a write a user story.

---

Preparation

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.

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” >

---

Workflow

Believe it or not, one of the critical technologies for a successful workshop 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.

Activities

Choose a project goal for the workshop from the list above. If you are running these workshops with your development team it may serve you throughout this curriculum to have a consistent project for each workshop — so choosing a site or app that you will eventually build in a later workshop is a good idea.

Make sure you have at least one end-user present, and at least one developer. One person must be designated the Product Owner — their job is to know what the end users want and to prioritize the work. Another person must be the Agile Project Manager — their job is to coach the team throughout the workshop and to keep the workshop on track.

You can also practice without a technologist. For this, you might want to choose the “Clean out the garage” project goal. Anyone can act as both the end-user (who needs work done) and the developer (who does the work) for this project. It makes a good one-person practice project.

It is absolutely essential that everyone has pens and cards. Sharpies are best, because they can be read from far away.

The phases of the 50-minute workshop are:

1. Review of the user story format (1 minute)
2. Review of the INVEST mnemonic (4 minutes)
3. Open brainstorming — write at least 3 stories (5 minutes)
4. Backlog grouping exercise (5 minutes)
5. Backlog prioritization exercise (5 minutes)
6. Quick estimation (60 seconds per story)
7. Reprioritization (3 minutes)
8. Format checking (2 minutes)
9. INVEST checking (5 minutes)
10. Discussion of the workshop (5 minutes)

If time allows, you may repeat this workshop to create an even better 2-iteration workshop. You can go through the whole process again and build out more user stories.

Note that the Agile Project Manager should encourage changes to the stories and the creation of new stories at any time during the workshop, and during any phase. The goal is to get a creative set of stories. Generally, the process of story writing is a process of discovering things you didn’t realize you needed or wanted, and sometimes it is the discovery of surprisingly simple solutions.

In greater detail, here is what happens in each phase:

Review of the user story format and INVEST mnemonic (5 minutes)

The Agile Project Manager is responsible for keeping fairly strict time. Agile teams must accept the discipline of time-limited iterations, on both large and small scales. In this phase you present the structure of the workshop, the roles, the project goal, and a brief introduction to the story format and the INVEST acronym, which are ideally written on a flip-chart or somewhere where everyone can see them. You will not have time to fully explain this, but you will explain it more as the workshop progresses.

Open brainstorming – write at least 3 stories (5 minutes)

Everybody takes a sharpie and cards. Everybody writes stories for 5 minutes that they believe will advance the project goal. The Agile Project Manager should walk around answering questions during this time. People “publish” their stories on the wall or table as soon as they are written, but no criticism of stories is allowed during this phase. The developers participate in this phase just as the Product Owner and end-users do.

Backlog grouping exercise (5 minutes)

The cards are presented to the whole group. Stories that are duplicates or very closely overlapping are grouped together. Note that upon reading the stories of others in the group, anyone may write new stories on the spot (and in fact this should be encouraged during any phase). If a story is consensually deemed to be obsolete or going in the wrong direction, it can be thrown away or moved into a reserve pile. During this time stories can be rewritten or reworded to make them more Independent.

Backlog prioritization exercise (5 minutes)

The stories are force-ranked into order, with the highest priority at the top. There are no ties; a specific order must be chosen. Open discussion is allowed. In the end the Product Owner sets the actual priorities. His or her authority to do this is absolute.

Quick estimation (60 seconds per story) – as much as 15 minutes

In priority order, everyone produces a Small, Medium or Large estimate for the time to implement each story. Even the non-developers do this. We have a separate workshop for estimating, so this exercise is meant to practice evaluating if the story is estimable — no need to spend too much time quantifying the story’s size. The Agile Project Manager must keep the discussion to 60 seconds, which will be very hard. People will want to discuss the stories far more. Under no circumstances can you spend more than 120 seconds on a story. If 120 seconds goes by, the development lead writes something down no matter what. If any stories seem too long or large, they can be quickly split into multiple smaller stories.

Reprioritization (3 minutes)

Given the estimates, the stories may be reprioritized or adjusted. This is usually an important learning phase. Usually, there are stories which are surprisingly easy or surprisingly hard, and, given their cost, the order in which they are to be accomplished clearly changes.

Format checking (2 minutes)

Confirm that each story is in the correct format: “As a ____, I need a ____ in order to ____”.

INVEST checking (5 minutes)

Try to make sure that each story is testable by writing a description of the test on the back of the card. This should lead to a lively discussion between the developers and end-users.

Discussion of the workshop (5 minutes)

Spend 5 minutes quickly discussing not the stories, but the process of story writing. Talk about what worked and what didn’t work. Make a list of action items that the team will do differently next time.

---

Outcomes

• Some people will have a hard time producing 3 stories.
• Some people may object to moving so quickly with so little explanation. Push through this. They will come around when they see the results.
• Some disagreement on product direction may be uncovered. The Agile Project Manager should respect this. The Product Owner has the final authority on prioritization. Ideally, the disagreement will result in a creative compromise which synthesizes the results.
• It is possible that this will all fall apart and you will have to try again. Be willing, it’s worth it.