Best Practices for Writing Agile User Stories

Instructor: Stephen Meyer

Stephen has worked as a Project Manager and is PMP certified, as well as certified by the Scrum Alliance.

One of the factors that dictate success for a project is the quality of project requirements. In Agile, project requirements take the form of user stories. Learn the best practices for writing quality user stories.

User Stories Defined

Whitney is an experienced project manager who has been using Agile for years. She has been hired at a company to help the project team transition to Agile. One of the first things she does is train the development team and stakeholders on user stories. While there are various components to Agile, it is the creation and completion of user stories that drives projects. She decides to start with the basics: what is a user story and where do they come from?

A user story describes functionality for a specific individual or user. It also describes what that functionality accomplishes. User stories answer questions like who, what, and why but do not answer how. The intent is to generate discussion of and collaboration about the functionality, rather than dictate how it needs to be created.

User stories are typically written by the product owner, who is the sole decision-maker for project requirements and direction. Even if other individuals, such as stakeholders or development team members, write user stories, the product owner determines if the functionality is needed. In addition, the product owner prioritizes user stories in a collection called the product backlog. Most of the user stories are written around the beginning of a project but this is not a rule. They can also be written during the project.

User Story Structure

Once Whitney helps her team understand what a user story is and where it comes from, she moves on to describing its structure. When working on different requirements within projects, as well as working on different projects, it is important that user stories have a consistent structure. This helps the team focus on understanding the desired functionality, the reason behind it, and for whom it is desired.

The most common structure for a user story names the user, the functionality, and the reason. They are often written in the following format: 'As a <type of user>, I want <functionality> for this <reason>.' For example, in a project to build a website for a bank, a user story might be, 'As an account holder, I want to view transaction history so that I can track the funds in my account.' The focus is on the end user and end result along with the purpose.

In addition to the high-level requirement provided in the user/functionality/reason structure, user stories contain low-level requirements as well. The low-level requirements provided in a user story are called acceptance criteria, or conditions of satisfaction. Acceptance criteria list specific actions and results that demonstrate the functionality for the user story. An example is, 'When I deposit money, I see the account debit.' Each acceptance criteria must be met before the product owner accepts the user story as complete. This is why acceptance criteria are also referred to as the definition of done.

Qualities of a Good User Story

As Whitney's team gets a grasp of how to write user stories, she makes sure they know that it takes more than structure. Other qualities of the user story are just as important. To help them remember these qualities, Whitney teaches them a mnemonic device INVEST, which was originated by Bill Wake. INVEST stands for independent, negotiable, valuable, estimable, small, and testable.

The first two qualities, independent and negotiable, are related to how the development team engages with user stories. Independent means that the user story does not overlap with another and does not need to be worked on in conjunction with other user stories. This allows the development team to order user stories in the way that makes the most sense. Negotiable refers to flexibility so that the details can be changed. This is why the how is not in the user story.

The next quality, valuable, means that the functionality being created should provide a benefit to the end user. This is important to both the product owner and the development team. The product owner should only be focused on projects that provide value to the end user. From the development team's perspective, work is not worth doing unless it has a purpose. Valuable user stories help the team to be equally invested as the product owner.

To unlock this lesson you must be a Study.com Member.
Create your account

Register to view this lesson

Are you a student or a teacher?

Unlock Your Education

See for yourself why 30 million people use Study.com

Become a Study.com member and start learning now.
Become a Member  Back
What teachers are saying about Study.com
Try it risk-free for 30 days

Earning College Credit

Did you know… We have over 200 college courses that prepare you to earn credit by exam that is accepted by over 1,500 colleges and universities. You can test out of the first two years of college and save thousands off your degree. Anyone can earn credit-by-exam regardless of age or education level.

To learn more, visit our Earning Credit Page

Transferring credit to the school of your choice

Not sure what college you want to attend yet? Study.com has thousands of articles about every imaginable degree, area of study and career path that can help you find the school that's right for you.

Create an account to start this course today
Try it risk-free for 30 days!
Create an account
Support