User Stories are the de-facto standard of capturing feature wishes in agile teams. User stories are often written from the perspective of an end-user or user of a system. In other words, a user story describes the type of user, what they want, and why. A user story helps to create a simplified description of a requirement. Depending on the project, user stories may be written by various stakeholders including clients, users, managers, or development team members.
User stories only capture the essential elements of a requirement. in the format “As a <who> I want <what> so that <benefit>”:
Role – The user should be an actual human who interacts with the system.
Action – The behavior of the system should be written as an action.
Benefits – The benefit should be a real-world result that is non-functional or external to the system.
Notes:
User stories are written in everyday language and describe a specific goal (what) from the perspective of an individual (who) along with the reason (why) he/she wants it.
Card – a written description of the story used for planning and estimation.
Conversation – Discuss your ideas with others. Let them ask lots of questions. Work together to come up with ideal solutions. The goal is to build a shared understanding.
Confirmation – Work towards agreement on what to build. Record that agreement as a set of confirmation tests.
The acronym INVEST helps to remember a widely accepted set of criteria, or checklist, to assess the quality of a user story. If the story fails to meet one of these criteria, the team may want to reword it, or even consider a rewrite (which often translates into physically tearing up the old story card and writing a new one).
Independent – Each User Story should represent a distinct and independent set of business values such that, were it released on its own, it would deliver incremental value over the previous state.
Negotiable – While the end-goal may be clearly described, the methods by which that goal is achieved should be negotiable – between the Product Owner and the Development Team, the Product Owner and the Customer, or any other involved stakeholders – so as to prevent unrealistic constraints on the feature or functionality.
Valuable – The business value of any User Story should be readily recognizable by reading the story, and each story should represent some sort of value to a specific user type.
Estimable – We must have enough information that we can properly size a story so that we may properly plan and commit to our work. (But no more!)
Small – User Stories should be small enough that they are able to be completed within a sprint.
Testable – All members of the team need a clear and precise way to verify whether or not a User Story has been completed.
Note That:
INVEST are guidelines for quickly evaluating the quality of user stories originated in an article by Bill Wake, which also repurposed the acronym SMART (Specific, Measurable, Achievable, Relevant, Time-boxed) for tasks resulting from the technical decomposition of user stories.
Want an agile tool that can manage your scrum projects well? Visual Paradigm features a user story mapping tool, Affinity Estimation tool, sprint management tool, and task management.
