Best Practices to Succeed with User Stories

Lots of teams started to use the term "user story" after moving to Agile. A User Story is a simple and elegant technique to gather customer requirements. Nevertheless, it requires a certain understanding and practice to build great software with User Stories.

Let's have a close look at what a User Story is and how to succeed with this technique.

What is a User Story?

The User Story is a short and simple description of a piece of functionality which brings value to the user or customer, and which the team can deliver in an iteration.

The User Story should answer 3 questions:

• Who are we building it for? — As a <type of user>
• What are we building? — I want <feature>
• Why are we building it? — So that <value or benefit>

Following this, a typical format of the User Story is:

As a <type of user>, I want <feature>, so that <value or benefit>.

Example of the User Story: As a registered user I want to be able to download my picture to my profile so that other users can see what I look like.

Is There Any Procedure for Creating a User Story?

There is no formal procedure to create the User Story. Nevertheless, there is a guideline which should be followed to create a good User Story. It's called the 3 C's and was proposed by Ron Jeffries, one of the founders of Extreme Programming.

• The Card is a written description of the User Story. It does not capture all details about what should be built. It is instead a reminder, a promise for subsequent communication that must take place.
• The Conversation is used to discuss details of the User Story. It may be supplemented by some documentation.
• The Confirmation is represented by user acceptance tests, which ensure that the User Story satisfies acceptance criteria of the user/customer.

How to Write a High-Quality User Story

A good practice to make sure the User Story is of proper quality is to adhere to the criteria of Bill Wake's INVEST acronym. INVEST also helps to determine whether the User Story is well understood and ready for the development team to start working on it.

• Independent – the User Story should not depend on another User Story, so User Stories can be developed in any sequence.
• Negotiable – details of the User Story are negotiated in a verbal conversation between the Product Owner and the development team.
• Valuable – the User Story should bring needed value to the user/customer.
• Estimable – the User Story should be understood well enough by the development team to estimate it.
• Small – the User Story should be small enough to fit in an iteration.
• Testable – proper acceptance criteria should be written for the User Story, so it can be validated.

What is Not a User Story?

Let's be honest with ourselves: the User Story cannot be a "technical User Story" by its definition, as in such a case it will not bring direct value to the user/customer. Still, lots of teams like to create User Stories when they need to do some technical task like code refactoring. I recommend to use other work items for such tasks, and agree on this type of work with your Product Owner for him to see why it is necessary. The same relates to nonfunctional requirements tasks, interface design tasks, complex user interaction tasks, or bugs. You are free to create other work items for these tasks. For example, a Constraint Story may be used to represent nonfunctional requirements. The User Story is a great technique to capture product functionality, but we are not obliged to use it for all purposes.

Who is a User?

Prior to writing User Stories, there should be a clear understanding of who is the user for whom the User Story is created. Sometimes it is overlooked by teams new to the User Story technique and they end up creating software with needless features. So, do a proper user research to have all your user types or user roles or personas writing down and described. Two techniques that can help you with this are User Role Modeling and Personas.

Who is Responsible for Writing a User Story?

Generally, customer representative such as a Product Owner is responsible for User Stories. Nevertheless, User Stories are not specifications given from the top level to the team, but more a collaboration technique between the Product Owner and the team. That's why it is better if User Stories are written collaboratively. A great way to do this is a story-writing workshop.

Where are the Details?

As User Stories are not specifications, details are conveyed in a different way:

• The second "C" in the 3 C's guideline is Conversation. Conversation is one of the most important aspects of Agile. So, most details are conveyed via verbal communication between the customer representative and the development team.
• The third "C" is Confirmation. User acceptance tests are confirmation that the User Story satisfies acceptance criteria of the user/customer, and they serve as formal documented details. BDD (Behaviour Driven Development) is a great technique to write acceptance tests.
• Some User Stories may contain additional written details if needed.

How Do You Know When a User Story is Done?

Use the Definition of Done technique. Simply put, Definition of Done is as a shared understanding between team members of what it means for work to be complete. Definition of Done is usually created in the form of the checklist of activities, which demonstrates agreed value (user acceptance tests to satisfy user acceptance criteria) and quality (to satisfy quality criteria). Teams sometimes neglect the last one, what can make the User Story not potentially shippable to the customer at the end of an iteration. Definition of Done technique helps to avoid this.

Example of Definition of Done:

Done is when:

• Unit tests are passed
• Code is peer-reviewed
• User acceptance tests are passed
• Integration tests are passed
• Regression tests are passed
• User guide is updated

How to Start Defining a Product Scope?

At the beginning of a project, we need to define a rough scope of a product to have a global vision of it. This can be done with Epics. An Epic is a big chunk of work that has one common objective. The Epic can be thought of as a placeholder for more detailed User Stories which are created later. The Epic usually takes more than one iteration to complete.

What Is the Best Way to Organize User Stories?

Use the Story Mapping technique, invented by Jeff Patton. Story mapping represents a top-down approach to requirements organization and also is a great way for prioritization and planning.

Agile Extension to the BABOK® Guide v2 states:

"Story Mapping provides a visual and physical view of the sequence of activities to be supported by a solution. It uses a two-dimensional grid structure to show sequence and groupings of key aspects of the product on the horizontal dimension, with detail and priority of stories on the vertical dimension. Story Mapping is a decomposition technique which allows for the evolutionary understanding of a solution starting with an end-to-end view and drilling down to the detailed user stories."

Example of Story Mapping (created by Steve Rogalsky):