Effective User Stories – 3C’s and INVEST Guide

Effective User Stories – 3C’s and INVEST Guide

4-5 minutes

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 Story Template: Role-Action-Benefit

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.

• Be as specific as possible
• The development team is NOT a user

Action – The behavior of the system should be written as an action.

• Usually unique for each User Story
• The “system” is implied and does not get written in the story
• Active voice, not passive voice (“I can be notified”)

Benefits – The benefit should be a real-world result that is non-functional or external to the system.

• Many stories may share the same benefit statement.
• The benefit may be for other users or customers, not just for the user in the story.

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.

User Story Examples

• As < a recruiter > I can < post new jobs > so that < applicants can find those jobs via search >
• As < a job seeker > I can < limit who sees my resume > so that < I have privacy >

The 3 C’s (Card, Conversation, Confirmation) of User Stories

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.

Examples of Bad User Stories

The software is written in C++ The database will have a connection pool How to Write Good User Story with INVEST Guidelines 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 au ser story mapping tool, Affinity Estimation tool, sprint management tool, and task management.