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

How to Get Your Boss to Pay for Scrum Training

Convincing your Boss to Pay for Scrum Training

With businesses tightening their budget, it’s getting harder and harder to convince your boss to pay for professional scrum training. People ask us all the time how we suggest they get their boss to cough up the tuition.

The traditional response is to explain paying for professional training helps employees become better prepared to do a better job. Armed with new tools and techniques, not only does the employee’s performance improve because the employee is better equipped to do their job, the team’s performance improves because the employee shares these new techniques with the rest of the team.

To be more effective you can modify the traditional response to include concrete benefits. If your boss pays for the class, then after the class, you offer to create a plan that applies one or two of the new techniques you learn and metrics to measure improved performance.  Who can say no to concrete benefits?

I also recommend these additional three reasons to pay:

  1. Continuous learning
  2. Professional development and certification
  3. Find out how the competition does it


1. Continuous Learning

We’re agile and agile is all about continuous learning, right? Is your team stagnating a bit? Do the same problems continue sprint after sprint, retrospective after retrospective?

If you answered “Yes” to any of the above questions, then the continuous learning reason may just get your boss to pay for scrum training. Everyone can use some fresh insight. Explain to your boss that scrum is evolving. New tools and techniques come out every day.

After you attend the class, you can bring back process improvement suggestions that the entire team can benefit from. The next few retrospectives after scrum training can result in process changes that increase productivity. Isn’t that worth the cost of admission?

2. Professional Development and Certification

Most professional certifications require continuing education hours in order to renew, such as the PMI PMP. If your boss paid for your initial certification or your boss pays for the renewal of your certification, then paying for the continuing education hours required to maintain your certification should be a no brainer.

Even if your boss does not pay for your certification, you can argue that your boss definitely benefits from employing someone who cares enough to obtain and maintain professional certification. If your boss shares the benefit, then your boss should share the cost. #Justsaying

3. Find Out How the Competition Does It

We all enjoy going to scrum training because we meet people from other companies, network and learn the techniques they apply to maximize their team performance. Some of the students we network with at class may work for our competitors. We get insight into how they practice scrum. You may never get that detailed insight at a professional dinner.

Discussing what works and what doesn’t with others at training class is a natural way to share ideas and learn real life application of the techniques discussed in class. Even if none of the attendees work for direct competitors, learning how the other companies practice scrum and what techniques they’ve tried, allows you to leverage their experience in your own practice. You can’t get that information in a book!

I hope these suggestions start you thinking about how to apply business reasoning to encourage your boss to pay for scrum training.

If you have some other techniques do share!

Cynthia Kahn

Cynthia Kahn

Cynthia Kahn
CynthiaK@gsd.guru  503.799.5500




read more