Focusing on Value With Agile User Stories

If you’ve had any exposure to Agile project management or simply walked past a group of people talking about software development, it’s likely you’ve heard about user stories. At the core of Agile project management is the user story.

Focus on creating value for the user is the highest principle of the Agile methodology. User stories are a general description of a product value or feature written from the perspective of the user or customer.

This method of defining work by user needs creates a focused attention on the user, within the project and for the project team. The user story is not defined by technical requirements or specific technologies. By centering work around user needs, the answer to a user story allows methods that may not have been considered if work were to start from a predetermined technical method.

How is a User Story Defined?

User stories are written in simple easy-to-understand terms that clearly states the user, their need, and the value established for the user. A common pattern to follow in writing a user story is:

As a [user], I want [the users need], so that [reason for the need].

This pattern quickly answers three main points. It tells who the user is to allow understanding from the user’s perspective. Also defined is the user’s goal in what they want to accomplish. And finally, the user story provides why the user needs to achieve their goal and the value the user will gain.

A quick example:

As a [restaurant owner] I want to [be able to quickly reply to customer reviews] so that [I can address customer concerns.]

If we break this down we can understand a few things:

• The user is a restaurant owner which likely brings to mind a person and what their day-to-day may be like. They are often dealing with bursts of being very busy and juggling numerous tasks at once.
• The users needs to quickly reply to customer reviews of their restaurant. The need to quickly reply goes back to the previous point and gives direction in how the need could be best answered.
• The need exists because the user wants to address any concerns presented by customers. The value is provided by allowing the user to address customer reviews that could negatively effect their business.

A user story should be small enough to be completed within a reasonable time period. This is often defined by the sprint length in Scrum methodologies. Otherwise, it could be limited by hours or story points that makes sense within the project release or review cycle. If a story is too large it should be split into smaller stories or turned into an epic containing multiple user stories.

The majority of initial user stories are defined by the product owner during project initiation meetings. The product owner would define user stories from user research and product knowledge. Throughout the project additional user stories will be created and existing stories refined through user and development team feedback and suggestions.

Getting into the details of a User Story

Once the general description of the user story is created, further specification is needed to provide clarity for stakeholders to complete the story. This means expanding on who the user is and defining a clear criteria for fulfilling the user’s need and providing value.

The user in the story description often needs further explanation, given in a user persona. The user persona goes into further detail of this fictional user to provide a broader understanding of the users common traits. These personas are defined by the product manager early in the project initiation and refined over time. For most stories you will be applying a preexisting user persona.

Often the largest work in providing detail for a user story is establishing the acceptance criteria, or the definition of done. This outlines all of the criteria that the team agrees are needed to meet the need of the user story. Here is where you may determine a story requires further definition or is possibly too large and requires splitting into smaller user stories.

From the acceptance criteria, sub-tasks can then be defined. This is where you may get technical with design or technology requirements needed to meet the user goal. Most Agile focused project management software will support user story sub-tasks that can be tracked through development.

Finally, if your team is using story points, you would establish an estimated difficulty of completing the required tasks and assigning points to the story. I’ve written more on this if you’re interested in learning more about story points and how to establish them with your team.

I hope this was helpful in giving you a better understanding of Agile user stories. If you have any feedback or questions, feel free to contact me on Twitter or fill out the contact form.

Photo by Leon