Schedule Time to Talk

How to Write the Best User Stories with Story Cards

by Todd Cotton, on Mar 17, 2020 11:11:07 AM

How to write effective story cards

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”  

- The Agile Manifesto

Put simply, as agile practitioners, our primary priority is to continuously deliver value to the customer. How does effective story card writing—a seemingly simple agile method—ensure delivering customer value is at the center of all activities?

Starting with a simple template and basic guidelines, your team can regularly deliver customer value and turn instructive user stories into actionable story cards.  

Start with a clear, succinct user story.

A user story is a short, simple description of a function needed by the customer. It can be based on conversations with the user, feedback surveys, or any method that gets the customer’s honest perspective. 

User stories involve a simple template or formula: “As a [who], I want [what] so that [why].”

Story card template

Let’s break down these three elements:

1. Who will receive value from the feature? Agile teams must start with the customer; delivering value to key stakeholders is at the center of the methodology.

  • Examples: first time visitor, regular app user, consumer loan originator

2. What does the stakeholder want that helps him or her accomplish a goal? This is a brief description of the feature the customer wants. 

  • Examples: to sort available products by price, a new report, to save my progress

3. Why does the stakeholder want this feature? Even more important than what the feature is, we need to identify how that feature helps the user accomplish a goal. 

  • Examples: find the right folder, browse product options, see my purchase history

Without unnecessary detail, this formula ensures we focus on the key stakeholder, emphasize the value delivered, and know the feature that will turn the user story into a project.

Effective story cards have 5 elements.

With the user story created, we can now turn those stories into story cards. 

A story card is one unit of delivery for an agile team. We recommend each has five basic elements, which intentionally give enough detail for the team, but also leaves room for a conversation to later fill out the details (more on that in INVEST rule). 

The five basic elements to include:

  1. Title or phrase. Quickly signifies the task for the team to see on the storyboard, kanban board, scrum board, or other progress visualization tool. 
  2. Value statement. This is a condensed user story, showcasing the stakeholder and what the benefit of the feature is.
  3. Basic requirements for the story. In a sentence or two, provide initial expectations for what this feature should be.
  4. Size or estimation. Sizing helps teams make predictions on when work will be completed and is vital for scrum teams to plan. On your story card, this may be a number (e.g. 3, 5, 8, etc.) or a size (e.g. small, medium, large).
  5. Acceptance criteria. This is the basic benchmark that must be met to consider this card complete.

Story card example

The INVEST Rule: Perfect User Stories Every Time

At LeanDog, we use the INVEST rule to ensure our user stories and story cards contain enough, but not too much, information to complete the task. Coined by Bill Wake, INVEST is an acronym that simply and concisely instructs the story writing process. 

Well formed user stories should be:

  • Independent: Story cards should be independent of each other, meaning each can be completed on its own.
  • Negotiable: The card should be a short description of the deliverable without too many details. Specifically, it should:
    • Be short, sweet, and to the point.
    • Just one or two sentences long.
    • Avoid wordiness.
    • Avoid unnecessary details.
    • Allow details to be worked out through conversation. 
  • Valuable: Each story must provide value to the customer and is informed by feedback or conversations with that user.
  • Estimable: To plan and prioritize, developers should ballpark or estimate the effort required to complete the story. Many different estimation techniques can be used.  
  • Small: In terms of scope, each story should take no more than 2-3 days to complete, though the maximum allowable size depends on the team.
  • Testable: If you cannot test the story, you’ll never know when it’s done. A story must be testable to confirm it is complete.

How to turn story cards into work with the 3 Cs.

With your notecard in hand, and the five elements and INVEST rule guiding you, you may wonder how the story card turns into a task or project. 

We use the 3 Cs to ensure the card is ready to turn into a project.

  1. Card. This involves physically writing out the story card, including the 5 basic elements and following the INVEST rule. Story card writing can be done by anyone on the team. 
  2. Conversation. User stories are intentionally simple and brief. Any unknowns can be answered through a quick conversation with the product owner or teammate. The card gives the premise, and the conversation gets into detail that wasn’t necessary to write out beforehand.
  3. Confirmation. Finally, define the story’s acceptance tests, which specify up front what has to work in order for the feature to be acceptable. 

Following the three C’s, you have all the necessary information to get to work on creating the feature for this story. 

3 common story card writing mistakes to avoid...

Hidden within the INVEST rule are critical guidelines that seem obvious on the surface, but are commonly neglected until you’ve mastered the art of user story and story card writing. 

Why your user stories might not be effective:

  1. The story is not valuable. Agile teams must choose work that delivers value to the customer quickly. When you write a new user story, ask yourself: 
    1. “What is the value of this?”
    2. “Who does it create value for?”
    3. “Is the customer asking for it?”
  2. The story includes too much detail. A developer I once worked with said, “I don’t feel like the user story I write is good unless it leaves no question unanswered.” While he meant well, this runs counter to agile, which is designed to be adaptable, not predictive. Thinking you need everything answered upfront on a single notecard is a traditional waterfall tendency that you need to avoid.
  3. Your team has not established a culture of psychological safety. Teams with psychological safety allow for risk and are built on mutual trust. It gives you the freedom to spare the technical details on the card because you trust your teammates to either a) know how to get the task done or b) know when to ask questions to fill in the blanks. 

Over time, teams become proficient in this process, and can even simplify story cards further for improved efficiency. 

Put continuous improvement into practice.

LeanDog has led agile transformations at Fortune 100 companies, startups, and small businesses. Subscribe to our blog to receive tips, best practices, and overviews of agile principles from expert practitioners and coaches.

Access agile discussion guide 4.0
Topics:scrumAgile Processes