INVEST – on how to write a good User Story

Posted on by

In one of my previous blog posts, I have described a technique called User Story, where I also expressed my take on what it should be used for and the case where it is best not to consider it. The User Story at first glance, seems to be fairly simple technique to use, mostly due to its short and concise form and a template-like structure. But is a User Story really such a banal technique? It certainly is not.

I often come across User Stories written on the go, without a sound think-through, only aimed at meeting requirements arising from adopted template. Obviously, this often entails serious negative consequences. If the only goal of the author is to fit the User Story into a template (‘cause they told me to’ or ‘cause this is our standard’), this means that you should not make this effort. In all these situations it is probably best to describe the requirements in another form, for example, using a natural language.

INVEST – traits of a good User Story

How should you then write a User Story so it is both effective and useful? It is worth paying extra bit of attention to the quality of the User Story. In order to help you focus on the quality there has been a very useful abbreviation invented – INVEST.

I for Independent

And so the User Stories should be independent of each other. This means that it is possible to understand and implement them autonomously. They should also add value when analyzed as a standalone element.

Off course, this does not mean that User Stories should not be related in any way. Just as the mutual relations may appear between the requirements (described in any form), so it may happen that the User Stories are linked. These relations may, for example, indicate that a given User Story must be implemented before another, or when you implement one of them first, the implementation of the other will be far more easy. It’s all about making your User Story a specific, self-contained logical unit.

You may compare it to building a house: laying foundations and erecting walls. Off course, there is a certain relation between these tasks and one activity must be completed before the other one. However, they are examples of standalone, logically distinguishable stages of construction process.

An example of a wrong use of the User Story would be presenting the radiator fitting and the central heating pipes works as separate stories. These elements do not add value on their own.

N for Negotiable

User Story should be negotiable, in other words, it should leave room for discussion and negotiation as to the possible ways of delivering a solution. It is incorrect to create User Stories that are detail-heavy and too technical as you already impose a specific solution on your dev team. This kills creativity and puts you at risk of missing a potentially more viable solution.

V for Valuable

A well written User Story expresses the value which is to be delivered through  its implementation. The structure of User Story actually compels the analyst to indicate ‘Who?’ ‘What?’ and ‘Why?’ The ‘Why?’ here is extremely important as it represents the clue of the underlying business need and the value which is being delivered. If, however, the implementation of User Story does not bring any value, why bother? It only leads to an increase in the implementation cost without any explicit gain, therefore represents a waste.

E for Estimable

Properly specified User Story must be subject to reasonable estimation. This means that it must be possible to determine the effort required to its implementation. It is obviously not about a precise estimation in working days, or worse even, in hours. It’s about a relative estimation, which is based on relative units (such as Story Points) and is based on previous experience of the dev team. Estimation process is much easier when clear and unambiguous acceptance criteria are specified.

S for Sized Appropriately

The ‘smaller’ the User Story, the better it is – this may be a general rule – off course within reasonable limits. Such reasonable size limit (being a consequence of relative estimation) may be specified as possibility of delivering it within one iteration (Sprint). If, according to the estimation, it is clear that a given User Story cannot be delivered within one iteration, it should be split into smaller pieces.

T for Testable

Just like any other requirement and its definition, also a requirement specified in form of a User Story must be testable. Simply put, this means that there must exist a way to objectively verify if given User Story have been implemented and have delivered the desired value to a particular stakeholder. In other words, one must be able to design and conduct a test aimed at verifying the original requirements in an unambiguous way.

My recommendations

  • Use the User Stories consciously, pay extra attention to their quality
  • Remember (or have handy) a list of traits of a good User Story, which create an INVEST abbreviation
  • When designing your User Stories, try to consider and include all listed traits
  • Pay attention to these traits when reviewing User Stories created by your colleagues-analysts