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.
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:
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.
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.
Photo by Leon