How to Write Effective User Story with INVEST Principles?

Table of Contents hide

1 INVEST Principle for Creating User Stories

INVEST Principle for Creating User Stories

In addition to a standardized format and complete elements, a good user story should also follow the INVEST principles: 1. Idependent; 2. Negotiable; 3. Valuable; 4. Estimatable; 5. Small; 6. Testable.

1. Independent – It is important to make one user story as independent as possible from the other user stories. Maintaining independence between user stories not only facilitates prioritization and alignment, makes release and iteration planning easier, facilitates independent understanding, tracking, implementation, testing, and frequent delivery, but also makes the scope of the user story size estimation clearer and thus the estimation bias smaller.

2. Negotiable – The content of a user story is negotiable; a user story is not a contract. A user story is just a short description of the user story without much detail; specific details are produced during the communication phase. A user story with too much detail actually limits the user, the team’s ideas and communication.

3. Valuable – Each story must be valuable to the customer (whether it is a user, a buyer, or an internal company role). User stories are valuable to the end user, so they should be written from the user’s perspective, describing a FEATURE rather than a TASK.

This feature facilitates a shift from the traditional directive-based work style to a self-driven value-oriented work style for the development and testing members of the team, so that everyone on the team knows the value of the work they do every day.

4. Estimatable (can be evaluated) – A very important part inside the planning meeting is the estimation of story points. It is actually a coarse estimate of the User Story to be developed so that the team can know the complexity (workload) of this user story.

The focus is on whether the user story can be completed in the current iteration according to the reception conditions of that user story and the DoD (completion criteria) defined by the team, and if it cannot be completed, the reason is given and the PO decides whether to split or redesign the user story.

Problems that make it difficult for developers to estimate the story come from: lack of knowledge of the domain (in which case more communication is needed), or the story is too big (in which case it needs to be cut into smaller pieces).

5. Small – A good story should be as short as possible in terms of workload, preferably no more than 10 ideal people/day, at least to ensure that it is completed in one iteration. The larger the user story, the greater the risk in scheduling, workload estimation, etc.

6. Testable (testable) – A user story should be testable in order to confirm that it can be completed. If a user story is not testable, then you cannot know when it will be completed. An example of a non-testable user story: the software should be easy to use.

Three Guidelines

A user story is basically a good user story when the INVEST principles are followed. Then we focus on three guidelines to help better comply with the principles when producing user stories.

The three guidelines are: one user, complete value, and no dependency.

1. One Type of users – Include only one type of users, as multiple users often have nuances. It is usually a typical user, often with a common need of some kind.

2. Complete Value – Deliver a customer value in its entirety. A complete user story means that when this story is complete, the user can reach a clear and meaningful goal.

3. Non-dependency – The three common types of dependencies are: overlap, sequence, and containment.

In general, overlapping functional points between stories are to be avoided; sequential relationships are a reality and can be resolved by some means in most cases; and inclusion relationships are helpful for complex systems, with implications for scheduling releases and iteration plans that need attention.

Overlapping dependencies

Overlapping dependencies are the form of dependencies that cause the most trouble, especially when multiple user stories contain multiple different overlapping parts. It is difficult to find a set of user stories that can represent the set of features for that minimum viable product, which should contain and only contain the features needed once.

Solution

Strip out the overlapping parts as separate user stories.
Rational splitting of user stories and keeping the overlaps in only one of the most cohesive user stories.
Use the Scrum development model.

Sequential Dependencies

Sequential dependency means that in order for a user story to be completed, one or more other user stories must be completed before it. Sequential dependencies are usually harmless, and there are ways to mitigate such dependencies.

From an agile development perspective, the entire system evolves gradually from an initial minimum viable product to a robust product, with each later step building on the previous ones.

But from another perspective, unnecessary sequential dependencies make it more difficult to rank and prioritize, which in turn affects the development of release and iteration plans and makes it more difficult to estimate the size of user stories.

Solution

Make user stories within an iteration as free of intrinsic dependencies as possible.
Keeping only one-way dependencies between iterations, with only one-way dependencies in time from stories in later iterations to stories in earlier iterations (forward dependencies).
Stripping out core dependencies as separate stories and not mixing dependent and non-dependent requirements in one story.

Inclusion of dependencies

Contained dependencies refer to the use of hierarchical management in organizing user stories, such as the common two-level feature-story management, where a feature contains multiple user stories, thus constituting a contained dependency of the feature on its subordinate stories.

Solution

The user-story level is used for iteration planning, avoiding coarse-grained iteration planning with the feature level, which can be used for release planning.

The feature level can also be split until it is at the level of a minimum marketable feature, and the user stories it contains can be separately grouped into the newly split features.

Following the minimum viable product concept, a feature is implemented in multiple iterations of multiple user stories, each of which can result in a potential deliverable or provide internal or external feedback.

References