Purpose of user stories
User stories are concise, user-focused descriptions that capture requirements from the user's perspective.
They ensure all stakeholders have a shared understanding of what needs to be built. By articulating user needs simply, user stories keep the team aligned on delivering value that meets customer expectations. They act as a bridge between product discovery and implementation, translating insights into actionable tasks. User stories facilitate a product that satisfies both user needs and business goals.
Guidelines for writing user stories
Align with KPI and goal
Each user story should be directly linked to a achieving the specific goal it sets out to achieve, as identified in the prioritisation process.
Reflect insights from product discovery
Incorporating customer insights gathered during the product discovery phase enriches the user stories.
Use findings from data analysis, customer interviews, feedback sessions, and prototypes to inform the content of each story.
Use the standard user story format
Adhering to the standard user story format enhances clarity and consistency. This format typically follows:
As a [type of user], I want [an action or feature], so that [a benefit or value].
Being specific in defining the user's need without prescribing a particular solution allows for flexibility in implementation while keeping the focus on delivering value to the user.
Include acceptance criteria
Defining acceptance criteria is a vital component of each user story. These criteria specify what conditions must be met for the user story to be considered complete.
By using clear and testable statements, acceptance criteria provide measurable benchmarks and form the basis for developing test scripts. They ensure that designers and engineers have an understanding of what successful implementation looks like.
Ensure feasibility
Considering the feasibility of each user story is essential. Take into account any technical, compliance, or resource constraints identified during the product discovery process.
Collaboration with the engineering team during product discovery should have validated the feasibility of user stories already.
Include unhappy paths
Prior to handing off products and designs to engineering teams, all paths- happy and unhappy- should be specified.
Each should then have user flows and designs intentionally created for it. Designing for unhappy paths and variant platforms should be done fully by PMs and designers, and not require engineers to have to create them.
Prioritise user stories
Prioritising user stories based on their contribution to KPIs and strategic goals ensures that the most impactful work is addressed first. Order the user stories by value and impact, and group related stories into epics or themes when appropriate. This organisation aids in planning and helps the team focus on delivering the highest value features.
Include necessary metadata
Each user story should include essential metadata to aid in tracking and context. Assigning a unique identifier to each story facilitates reference and management throughout the development process and into Jira.
Providing links to relevant prototypes, design documents, or research findings maintains context and supports the development team in understanding the broader picture.