A simple method to audit your User Stories

Overview

INVEST testing your stories ensures that when they are discussed with the team that will build the product or feature, they can appropriately discuss and agree how to go about creating that value.

In order to perform the test, you first need to gather all the User Stories created as part of the design process

Independent

Pick a User Story and confirm that it relates to a product or feature that is not reliant on any other User Story. This is to ensure that when this User Story is built, it produces something complete. If it is not independent, make it so by editing the User Stories and splitting out aspects of value that can be delivered separately.

Negotiable

On the same User Story, now analyse whether is gives the Build team the ability to propose a number of different ways this product or feature can produce the value required. For example, and if possible, a User Story should state “On the Move” rather than “On my mobile phone”. “On the Move” gives the build team the option to look at any personal device (tablets, watches, glasses) whereas the latter will be strictly Mobile. If it is not, look to re-write aspects of the User Story to provide the build team with any available flexibility.

Valuable

On the same User Story assess that it clearly depicts value from either the customers perspective or the businesses (or both). It must be possible for the build team to identify tangible value. If it doesn’t, in theory you should throw the User Story away (it doesn’t add value!), in reality it was probably just poorly worded, re-write accordingly.

Estimable

On the same User story, now assess that it is sufficiently detailed for the development team to understand it’s size and complexity and in turn the amount of effort and expertise that will be required to deliver it. If it doesn’t, add the clarity required

Small

On the same User Story, now assess that it is possible to deliver this feature within the confines of a Sprint (or iteration). Ideally, no User Story should span multiple Sprints. If it cannot, the User Story should be split into multiple, independent, stories

Testable

On the same User Story, now assess that it is possible to test the build delivers the value required by the story – this is similar to Valuable in that it relates to tangibility, but focuses on a means of evidencing through testing that the value exists.