User stories provide agile practitioners with great success because they help focus on the value being delivered to users. As Mike Cohn writes in his book, User Stories Applied: For Agile Software Development: “Rather than allowing product backlog items to describe new features, issues to investigate, defects to be fixed, and so on, the product backlog must describe some item of value to a user or to the product owner.”

And that’s why a key component to agile software development is effectively managing the user story backlog.

Typically in an agile operation, an initial set of user stories is defined as part of the discovery process, and additional user stories are continuously added by the team as needed during delivery. Defining user stories is a convenient way of capturing requirements at a high level of detail while focusing on user goals—which is why they can be so successful at helping you determine what is valuable to your uers.

Good user stories are much more than just statements. A good user story consists of three elements, commonly referred to as the three C’s:

1. Card

The user story should be able to fit on a 3”x5” note card, efficiently capturing the most important information. While this “C” sometimes refers to an actual note card, we mean it to refer to the optimal size of a user story. As Jeffries writes, the card should not contain all information about the requirement, but rather just enough to be used in planning to identify the requirement and remind the project team of the story. Each user story should follow the standardized format of:

 “As a [particular user], I want to [perform this action], so that [I can achieve this goal.]” 

Focus on gathering user stories for each user type to create a set of the most representative user stories possible. Whenever possible, user stories should be written directly by the users. However, depending on the type of project and organizational specifics, user stories may be written by project team members and/or the product owner, as well. A complete set of user stories can be gathered using common elicitation techniques such as interviews, questionnaires, observations, and user story writing workshops to ensure that the user stories accurately reflect user needs.

2. Conversations

Before user stories are about to be placed into a sprint, the product owner should talk to customers about their user story (or a user story that pertains to their business domain) for elaboration and validation. Elaborative conversations with users are necessary because a user story may be difficult to interpret, some background knowledge could be needed for implementation, or the requirements could have changed since the story was written.

Conversations represent discussions between the project team and the product owner or other stakeholders and business SMEs. In these conversations, the product owner informs stakeholders of what is going on, and stakeholders or team members exchange thoughts, opinions, and feelings. Conversations should take place throughout the project lifecycle. While we’re mainly talking about verbal discussions here, conversations can also include electronic communications through email, internal chat programs, or a via a requirements management and business analysis tool such as Enfocus Requirements Suite™.

3. Confirmations

The final component of a user story is the acceptance criteria used to confirm that the user story is implemented correctly and successfully delivered. Acceptance criteria must be defined before development begins to determine when each user story is finished and working as the user intended. Acceptance criteria can be used to demonstrate a user story’s boundaries, and are often thought up during conversations between the product owner, project team, and users. It is recommended that users are the ones to write acceptance criteria because each user story was written from a user’s point of view—therefore the tests ensuring a user story’s completion and satisfaction should be written by the users, too.

It is best to define details like acceptance criteria just in time before user stories are placed in a sprint. Providing too much detail is wasteful and time consuming because if a user story changes, the details will need to be changed, as well. However, providing too little detail often results in significant rework and forces developers to make incorrect assumptions. They should be written to be barely sufficient; that is, user stories should only contain the absolute minimum amount of information required to enable development and allow testing to proceed with reasonable efficiency. The rationale for this is to minimize time spent on anything that doesn’t add value to the end product.