INVEST Guidelines – Independent User Stories


INVEST Guidelines are a set of recommendations, put together by Bill Wake (see original article here), to evaluate good quality user stories (or more general, Product Backlog Items). Each of the letter from INVEST mnemonic refers to a quality characteristics and for the next six articles, each characteristic will be presented in detail. 

The first characteristic is Independent. An independent user story can be estimated, developed, tested, and demonstrated to the client, independently. This allows it to be positioned in the product backlog by its priority, independently valued, and not dependent on any other user stories before it can be implemented. 

According to the INVEST guidelines, a high-quality user story can be understood, implemented, tested, and demonstrated on its own. It can also be independently valued by itself in the product backlog. This allows it to move up and down in the product backlog as its priority changes, without affecting any other user stories. The priority assigned to the user story should be the only factor to determine when is implemented so if its priority is lower, the user story goes lower in the backlog and therefore implemented later while if it is higher, it can be moved up in the backlog so it is implemented sooner. Ideally, the time when the user story will be implemented should be determined only on its priority, independent of other user stories in the backlog. If user stories are dependent on each other, then the dependency will determine when the user story is implemented, rather than the priority. 

At the beginning, those user stories that define the system's foundation are written. These early user stories will deliver a slice of functionality to the user that can be demonstrated. After that, each story will be somehow dependent on functionality or architecture being in place. This is sequential dependency, which is expected. The base functionality will need to be delivered first before the enhanced features that depend on it. However, even with the sequential dependency on existing infrastructure, each user story should contain an independent feature slice. 

Independent feature slices of functionality mean a feature may need several user stories to be complete. Let’s consider a common case: a user needs to be able to register himself in an online application. This feature can be implemented, tested and demonstrated independently on other user stories. Together with this user story, an application usually also has view, edit and delete registration. All these should be done after the registration feature is completed; this is a sequential dependency. These user stories, though related, are independent of each other, each describing an atomic unit of work. The actual dependency to the user registration feature is more on the infrastructure level (they need to use the same data model). However, the concepts described in these user stories do not overlap. Each user story is independently valuable, delivering value that can be demonstrated on its own. What are important to eliminate are non-value dependencies. This often shows up as infrastructure stories. In the example below that would mean to have a user story just to implement the common data model for all the other features. In this case, there is no real value for the customer to have this separation, even if, from the technical point of view, might make sense in order to optimize the implementation flow. The recommendation here is to make this user story part of the others (usually part of the one with the highest priority) and implement it there.

The 'I' in the INVEST guidelines stands for Independent, where each user story can stand on its own and can be developed, tested, and delivered independently. Related but independent user stories can be combined within a single sprint or they can be split across different iterations depending on their priority. That's the flexibility delivered by writing independent user stories. And with independent user stories the Product Increment will be potentially shippable at any point in development without requiring or being dependent on another user story's functionality.