Monday, October 5, 2020

User Story - INVEST criteria

 

User stories describe one thing a user wants the system to do.

They are written in a structured way typically using the form As a type of user I want to do something so that I can get some benefit.

Another commonly used form is - given some context when I do something then this should happen.

So, when writing stories give each story a title that describes its purpose as a starting point follow this with a concise one sentence description of the story that follows.

One of the forms just described this form describes the user role what they want to do and why they want to do it as an example consider a banking system and a story to determine the available balance of a bank account the title of the story could be balancing Korea then

Following the template we describe the storyà As an account holder I want to check my available balance at any time of day so I am sure not to over draw my account.

This explains the role what they want to do and why they want to do it

user stories provide a clear and simple way of agreeing to requirements with a customer / end user D invest criteria can be used to evaluate good user

User Stories let me go through each letter of these criteria

Evaluate the stories with the INVEST criteria

Independent - A story should be independent to prevent problems with prioritization and planning

Negotiable - They are not written contracts but are used to stimulate discussion between customer and developers, until there is a clear agreement, they add collaboration

Valuable stories should provide value to users. Think about outcomes and impact, not outputs and deliverables

Estimatable - The story must be estimated. If it is not, it often indicates missing details or the story is too large

Small - Good stories should be small. This helps keep scope small and therefore less ambiguous and supports fast feedback from users

Testable stories must be testable so that developers can verify that the story has been implemented correctly and validate when the requirement has been met/is done


Created for my quick reference only.

ref: google documents