User Story = Persona + Need + Purpose
User stories are one of the core components of an agile program. User stories help us fit our user personas into the context of the product we’re designing. While the bio of a user persona describes their life and woes, the user story describes how they use a feature of your product — in layman’s terms!
A user story is an informal, general explanation of a software feature written from the perspective of the end user. Its purpose is to articulate how a software feature will provide value to the customer.User stories are probably the most popular agile technique to capture product functionality.
Working with user stories is easy. But telling effective stories can be hard. It’s tempting to think that user stories are, simply put, software system requirements. But they’re not.
User stories are simple, yet extremely powerful constructs: they describe pieces of functionality from a user’s point of view, expressed in a solid, compact way. They reflect what a particular class of user needs and the value to be gained. The format is very simple and easy to use.
The User Story should answer 3 questions:
- Who are we building it for? — As a <type of user>
- What are we building? — I want to <be able to perform/do something>
- Why are we building it? — so that <I get some form of value or benefit>
Consider the following when writing user stories:
- Acceptance Criteria
- Start with Epics
- If possible write user stories collaboratively
- User stories ≠ tasks
- Tag stories, add metadata
- Refine the stories until they are ready
- Outline subtasks or tasks
- User personas
- Include Test Scenarios
- Exclusion Criteria
- Have Technical Description
- How to test (Optional <filled out by developer> )
- UX/UI Designs
- Definition of “done”
- Timelines
These factors will help you decide if your user story is actually making a conversation or not.
Generally, Product Owner is responsible for User Stories. But there are often doubts about who can write them — And the answer is “Anybody”. Anybody who has clarity on the requirement can add details in, usually, if there is a Business Analyst in the team, they would document requirements, and in other teams the team member documents them. In the end, the Product owner should, however, review and accept them.
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.
For practical user story examples please refer the link
That’s it!
But don’t forget creativity is the key. Find what suits the culture of your team, what you can do to enhance your user stories.
Stay tuned to know more! See you later!
