Write Better Stories

The 5 Key Ingredients to Write Better Stories

Every time we teach a GSD Scrum Training workshop, one of the most difficult concepts for students to grasp is how to write a story.
On the surface, the concept seems quite simple:

Describe the user’s functional requirement from their point of view and include acceptance criteria, so quality assurance testers know the finished product meets the user requirement.

The story and acceptance criteria format below looks simple enough, right?

Story format:
As a <user role>
I want <to perform some function>
So that I can <achieve some goal/benefit/value>

Acceptance criteria format:
Given that <I am able to perform the new function>
When <I complete the function>
Then <something happens to show success/failure>

Then, why do so many people have trouble writing stories? We think it’s because scrum assigns the Product Owner responsibility for writing the stories, and most Product Owners have never written functional requirements. That’s why we recommend scrum teams include a Business Analyst or Systems Analyst to work with and train the Product Owner.

Even if an analyst helps write the stories, a story is a very specific type of functional requirement. I like to compare it to a mini use case. The story begins with an event and follows a process through to a successful or unsuccessful outcome.

Well-written stories meet the following criteria:

  1. Stories deliver a completed slice of working functionality.
  2. Stories describe the user experience, not how to build it.
  3. Stories contain clear functional requirements and acceptance criteria.
  4. Stories are small enough to be completed within the time allotted to the sprint.
  5. Stories do not leave the application in an unstable state.

An example high-level use case would be Customer Account Maintenance. A good way to identify the stories that comprise this use case is to brainstorm all the reasons that a customer would access the application to execute this module.

Some candidate stories for Customer Account Maintenance:

  • Create a New Customer Account
  • Update Customer Account Information
  • Change Forgotten Password
  • Retrieve Forgotten Username

Each candidate story is a single slice of functionality that represents a small slice of the overall functional requirement. Each story requirement is small, so it can be completed within the sprint boundary. The team can start by implementing Create a New Customer Account, and then add the new functionality described in the other three stories at any time. That’s because each story can stand on its own and, if described correctly, will not leave the application in an unstable state.

Let’s write a story together. We want to be sure to clearly describe the user experience and quality assurance criteria. Although traditional scrum says that acceptance criteria are optional, we disagree. Everyone needs to understand both the requirement and how to tell if the product works as intended.

A well-written story for Update Customer Account Information:


As a customer
I want the ability to update the personal information on my account
So that I can keep the system up to date and continue to receive timely statements and product offers.

Acceptance criteria 1:
Given that I have previously logged into the system
When I access the personal information update page
Then I am able to update my first name, last name, address, phone number and email address

Acceptance criteria 2:
Given that I have updated my personal information
When I click Save
Then the system checks the validity and format of the data entered. If there are no issues with the entered data, the system updates the database. If there are issues with the data, the system displays an appropriate error message(s) and does not update the database.

The requirement is clear. Everyone understands what the customer wants to do and what information is considered personal account information. In addition, the application validates the customer entry, so invalid data does not get saved to the database to ensure data integrity.

The completed story for Update Customer Account Information meets all our criteria and, if it passes quality assurance, it could be moved to production at the end of the sprint.

Another thing to keep in mind is that the story’s requirements cannot depend on another team to perform work in order to close it. If a high-level use case contains functional requirements with dependencies across teams, the Product Owners of the affected team must clearly divide the experience into independent functional descriptions.

Once you understand the rules, the art of story writing becomes more straight-forward. Be sure to read and review each story at Story Grooming before sizing, so everyone on the team understands the requirement.

Want to better understand how to successfully practice scrum in the real world?
Then you should read our GSD Scrum Handbook.



Cynthia Kahn

Cynthia Kahn

Cynthia Kahn
CynthiaK@gsd.guru  503.799.5500

read more

3 Tips to Close More Stories

Want to Close More Stories on Your Scrum Team?

The scrum team’s job is to decide how many story points to bring into the sprint, determine the right stories to accept into the sprint backlog, and close all stories in the sprint backlog by the end of the sprint. Most scrum teams think they know their velocity or how many story points they can complete in a sprint. They also do a pretty good job of prioritization, so they bring in the right stories.

Then, how come so many teams fall short of their sprint commitment? Why is it so hard to close stories?

I could talk to you about risk and uncertainty. I can also advise you on how to reduce risk, but you probably already know the drill. That’s why you already reduce your risk by practicing scrum and time boxing your commitment into a 2-4 week sprint. Good start.

What I am going to talk about is a change of focus.

These 3 changes can dramatically improve your team’s ability to close stories:

  1. Focus on closing stories not completing tasks
  2. Take advantage of the benefit of small batches
  3. Try pair programming

1. Focus on Closing Stories not Completing Tasks

Most teams setup a manual or automated sprint story board to track sprint progress. A typical manual story board is illustrated below:

Manual Story Board

At the start of the sprint, the Product Owner prioritizes the stories along the left side of the story board and the Development Team identifies the tasks required to complete each story.  At daily standup, the Development Team reports progress on the stories and tasks.

A common practice at standup is for team members to report on the status of their assigned tasks in a round-robin manner. This traditional task focus often causes the team to lose sight of the real goal: quickly closing the story.

The key is to change your focus from task to story. At standup, try going round-robin by open story, starting with the highest priority story at the top of the story board. When the team changes focus to the overall status of the story instead of the individual tasks, the entire team has visibility and input to completing it.

2. Take Advantage of the Benefit of Small Batches

Lean manufacturers like Toyota discovered that small batches made their factories more efficient. It seems counter-intuitive that starting and completing one story at a time from start to finish is actually more efficient than every developer on the team opening their own story at the start of the sprint.

The practice of opening fewer stories works because there is less work in progress (WIP). Combine that with the synergy of multiple developers working to complete each story and your team begins closing more stories and improves its burndown.

This concept goes hand-in-hand with the team’s new focus of closing stories.

3. Try Pair Programming

When the team decides to open fewer stories, how do multiple developers constructively work together? In the spirit of self-managing teams, I suggest the Development Team research and learn about pair programming techniques and determine the best way to apply them.

The benefit of pair programming is higher quality code and shared knowledge. The formal definition of pair programming has 2 developers work together at the same workstation, with one developer programming or driving and the other developer navigating or focusing on overall design. The developers can switch roles.

I’m not suggesting that your developers share a single workstation, but I am suggesting that 2 developers can work together, share the work required to complete a story and close the story more quickly.

How many times has work stalled because the developer has questions about requirements? If 2 developers shared the story, one developer could meet with the Product Owner while the other developer starts writing automated tests and begins high-level design.

This is just one example. There are many creative ways we can work together and get more stuff done.

We’re agile.

We’re experimenting.

We’re getting more efficient.

What are some techniques your team uses to increase velocity?
I’d love for you to share in the Comments.

Cynthia Kahn

Cynthia Kahn

Cynthia Kahn
CynthiaK@gsd.guru  503.799.5500

Contact Us read more