Scrum Rules: Product Backlog Items Are Written as User Stories

The User Story is a tool developed with Extreme Programming that is almost universally accepted as part of Scrum. Product Backlog Items formatted as User Stories express the desired functionality and system behaviour from the perspective of the user interface; therefore, User Stories are a lightweight and conversational way of communicating end user value to the Scrum Team.

User Stories tell any reader the “who”, the “what”, and the “why” — who cares about this, what is the need/action, and why is this valuable to the product, the business, or the end user. This information can then be put into a template: “As a <user role>, I can <action> so that <benefit>” The first part of the template is a user: a person, not a system, the second part is the unique action of the story, and the third part is the benefit for the user or any other stakeholder, and outside the system.

A User Story is made up of three “C’s”: Card, Conversation and Confirmation. The Card is the written version of the story (usually a physical card on the wall). It is considered to be an \”invitation to a conversation\”. The Conversation is where the real value resides and potentially involves all stakeholders. The Conversation can cause changes to the Card. Confirmation is the acceptance criteria that, when tested against, confirms the valuable result of the story. A User Story is an extremely effective way of creating light and conversational PBIs – this is why many Scrum teams use them.

The User Story format helps to ensure that PBIs are:

1. Independent of each other. That is, each PBI can be implemented independently of one another and represents functionality through the system which, in itself, is complete.
2. Negotiable. That is, design decisions and implementation details are not prescribed in the PBI. Rather, the implementation — the “how” — is negotiable.
3. Valuable to the customer. Each PBI must add value to the product and provide a return on the customer’s investment.
4. Estimable. If business stakeholders cannot estimate the relative value or the Development Team cannot estimate the relative effort required to implement the PBI, these are signs that the PBI is not provide enough clarity about the desired functionality or usage.
5. Small enough that the Scrum Development Team members have high confidence they can implement the item completely within a single Sprint.
6. Testable — the team and stakeholders clearly foresee ways they can test both the functionality and benefit.

The INVEST acronym is a guide to help a team write clear and effective Product Backlog Items; User Stories, due in part to their brevity and simplicity, are a well-known method to write INVESTable PBIs.

Writing User Stories takes practice. The Product Owner learns to write User Stories first. Here are three simple example User Stories that are well written:

1. As a Job Seeker, I can upload my resume so that I get a job.
2. As a Small Business Owner, I can purchase an advertisement so that I make money.
3. As a Manager, I can approve a TPS report so that I feel important.

These User Stories follow the format “As a <user role>, I can <action> so that <benefit>”. This is one of the most common formats, but there are alternatives. A good reference on alternative User Story formats is the Wikipedia page and the book “User Stories Applied” by Mike Cohn.

Here are some examples of badly-written User Stories with an explanation of why they are unsuitable:

1. As a user, I can use an iPhone to access the system.
   Problems: “user” is too generic, “use an iPhone” is not a feature of the product, “access the system” is redundant, and this story is missing the “so that” benefit part.
2. As a Job Seeker, I can upload my resume so that Employers can find it.
   Problems: “so that Employers can find it” is actually a separate feature (a search feature) and should be written as a separate User Story.
3. As a Developer, I can write the UI for purchasing advertisements.
   Problems: “a Developer” is not a user of the product, “write the UI” is a non-releasable layer of the product rather than a functional slice through all the layers, and again, this User Story is missing the “so that” benefit statement.

One very common and important pitfall to avoid is providing too much detail. The format is meant to be brief and fit easily on a single 3×5 note card when written with a marker. A User Story longer than about 25 words is unusual, and more than 50 words is just too much detail.

Eventually, the Product Owner should enlist other Scrum Team members and stakeholders of the product in writing User Stories. The technique is relatively simple and can be taught with a few examples and practice with a bit of feedback.

Certified ScrumMaster® – Guaranteed to Run! ✅

Certified Scrum Product Owner® – Guaranteed to Run! ✅

All virtual learning events run from 9am to 4:30pm Toronto/New York time and are 100% virtual.  Both CSM and CSPO courses have approximately 2 hours of required pre-work through our e-learning portal, and require you to have high speed internet for Zoom video conferencing and Miro virtual white-boarding.

Maybe attending a virtual training session isn’t for you, but you would like to acknowledge that this article helped you out somehow…