User Stories – Invest

The Six Attributes of a User Story and Why They All Count

The current best practice in Agile Software Development to clearly and briefly describe the functionality from the end-user’s perspective is the User Story. High quality User Stories will become part of the product backlog iteration. Weak User Stories are a waste of time and should be avoided at all cost.

This article will teach you the six attributes every effective user story must possess to pass the backlog quality check and ensure you spend your time right.

The INVEST Mnemonic To Writing High Quality User Stories

This simple, yet profoundly powerful mnemonic is a creation of Bill Wake the co-inventor of Extreme Programming.

I = Independent
A great User Story has the potential to stand for itself. By following this criterion the story can be scheduled and implemented in any desired order. This makes the story usable in different contexts and for multiple concepts.

N = Negotiable… and Negotiated
Outstanding User Stories are co-created by the programmer and the user. Only the main essence is captured, while the details are steadily added and influence the whole backlog in an iterative manner.

V = Valuable
All great stories add specific value to their target audience, in this case: the user. Especially when splitting stories, each individual piece should address one very specific area in which value is created, while telling the overall conceptual story.

E = Estimable
Every User Story must be estimable in order to be considered for a ranking by the customer. The degree of ratability is directly linked to the story being negotiable. Only stories that are understood by all stakeholders are estimable in scope and budget.

S = Small
A Story should not be overwritten and only focus on one key value adding idea. Keeping it within the range of a few person-days and at most a few person-weeks ensures that the story will be estimable.

T = Testable
Stories must be testable in order to be considered for the product backlog. If a story is not testable due to a lack of information it probably is not estimable and does not provide specific value to the customer.
All of the six attributes have to be considered in order for the User Story to be implementable. They affect each other in an iterative manner. Shortcomings in one area may lead to an information deficit in another and towards an unusable story.

Take the time to check your User Stories for all of these attributes. Time has shown that a Feedback Circle of Proposing – Estimating – Implementing is the most effective way to produce a great User Story, implementable in many different contexts.

Where to go with the user story when completed

A user story is typically functionality that will be visible to users, by users this includes end users, administrator’s manager. To create a user story will require a number of tasks to be completed. These tasks are often shared out among a range of people such as analysis’s, designers, programmers and testers so each has their own task. When put together the tasks complete the user story.

User stories appear on the Product Backlog and tasks appear on the sprint backlog.

Include INVEST workshops as part of good Scrum Master training and coaching.