In agile, the requirements are captured in the format ‘As a <role>, I want to <solution> so that <value>’.
Each C is incomplete without the other two. While the story cards represent the brief description of the feature, it is the conversation that holds the actual value of the story and recorded in the confirmation.
With the introduction of this format, throughout the project lifecycle, the customers and end users remain involved. There is the paradigm shift in writing software requirements and the focus is completely on discussing what is valuable to the people who are going to use the software.
The format helps remove the communication barrier between different teams and help them focus to the end users need but is it enough? There must be some set of criteria by which stories are judged and their quality is assessed. If, however, the stories fail to meet the criteria, the team might need to scrape these stories out and rewrite from the scratch, which takes double the effort.
INVEST is the set of criteria that encircles the following concepts:
Independent:
User Stories should not imbricate each other in terms of concept. User stories should be independent and discrete. They should be written that can easily be implemented in any order. ‘Order Independence’ helps achieve true prioritization.
The classic example of a dependent story:
In his article, User Story Dependencies are more Apparent than Real, Steven Thomas discusses the approach to identify and disrupt the natural order of the feature to achieve independence within user stories.
As a netflix user, I want to avail different packages offer by the netflix.
The above example can split into the following user stories.
As an admin, I want to create package.
As an admin, I want to edit a package.
As an admin, I want to delete a package.
Identify the dependence within the story by drawing out the natural order of the feature:
The natural order of the above example could be: Create a package, edit a package, and then delete a package. Because‘naturally’ you need to create something to edit or delete it later on.
Upset the natural order of a feature to identify independence:
The natural order is not the only possible order in which the feature could be built. It is not necessary to delete a package before editing it. These two could be done independently.
Identify business and technical dependency:
Often it depends on the priority of the story as well. Technically, availing a package and creating a package is not dependent. This can be built from the backend using SQL scripts. But, If the customer wants a UI interface than it is obvious that in order to show packages they first need to be created., introducing dependence.
An Independent Story:
As a registered user, I want to login to medium so that I can read articles of different categories.
As a registered user, I want to reset my medium account password if I have forgotton it.
In this example, ‘Login’ and ‘Reset Password’ are two different functionalities and can be built independently. Here, the identification of independence is easier, and both stories can be estimated easily.
It is worth noting that, the INVEST is a criterion, not a rule to follow. It allows teams to discuss dependencies within user stories and is effective for backlog refinement and grooming. One can consider, that a true independent story is when all of its dependent stories are already implemented.
Negotiable:
User Stories are not a binding contract. User stories are negotiable. Story cards are the reminder to have a conversation about the feature later on and because they are the reminders to hold a conversation, they do not need to include much details.
How much detail?
Story cards should have:
- A short description of a feature with enough details to have a conversation.
- Given there is important information at that point in time, It should be written as annotations.
Too much detail may lead to believe that there isn’t any discussion required further.
Negotiation allows teams to understand why of the feature and discuss or even challenge the story during a conversation with the customer.
A promise to have a conversation itself eliminates the term ‘binding contract’ from the picture. In fact, the only difference between user stories and the traditional way of writing requirements is the way they are written and treated.
When the focus is on the Why, the story shapes itself in a way that captures the essence of what is required. The value of that story is the outcome of ‘great conversation happens in the elegant room!’
Valuable:
As a new user, I want to register for a new Netflix account so that I can watch movies and entertain myself.
Value of any story is determined by the so that part of that user story. It is the exact value that we are trying to deliver. In our example above, if he is able to entertain himself by watching a movie, it is the intended business goal that this user story was trying to achieve. But not every story is valuable to the user. There are user stories that are created for development purposes, and they mostly focus on the technology and the benefits to the developer. User stories are prioritized according to the business value. In order for intelligent prioritization by the customer, these stories should be written in a format so that the benefits to the user is apparent.
It is a good practice that the customers or product owner (as proxy) should write these user stories as they are in a good position to describe product behavior and vision.
Estimable:
Stories should be estimable as they help in planning and prioritization. There can be multiple reasons that a developer can not estimate a particular story, as mentioned in the book ‘User Stories Applied’ by Mike Cohn.
- He is unable to understand the domain.
- He lacks the technical knowledge to implement a story.
- The story is too big or too small to estimate.
Unable to understand the business domain:
To cater to this problem, the developer should consult with the customer, PO or the BA to understand enough in order to give the estimate. This sort of activity usually happens in sessions like ‘Three Amigos’, in which a BA, developer and the QA sits together to make sure all three of them has the shared understanding of what needs to be developed.
Lacks technical knowledge:
Usually, this requires developers to go on a spike, to first acquire the technical knowledge for implementation of a story. This activity assigns a particular time and during the investigation, the developer learns enough to provide the estimates.
The story is too big or too small:
If the story is too big to estimate, they are broken down into smaller stories or combined into a single story for estimation.
Small:
The size of the user story does matter. They can be too big, too small or just the right size to fit into a single iteration, typically of 2 weeks, which helps in the planning. Since epics are treated as placeholders to the big part of the solution, it is obvious that they cannot be developed in a single iteration. They need to break into more smaller chunks, or perhaps combine into a single story to fit in the sprint.
Types of Epics:
In his book ‘User Stories Applied’, Mike Cohn mentions two types of epics: Compound Story and Complex Story.
1. Compound Story:
Compound stories can break into multiple shorter stories which can easily be developed within a single sprint. Each story itself becomes a distinct story.
Splitting Compound User Story:
As a registered user, I want to search for a movie on netflix.
The above story can split into:
As a registered user, I want to search for a movie by genre.
As a registered user, I want to search for a movie by title.
and so on…
2. Complex Story:
A complex story is difficult to break due to any uncertainty associated with it.
Splitting a Complex User Story:
- An investigation story called spike.
- A subsequent story for developing a feature.
If the story is too complex and requires developers to go on a spike, it is a good practice to:
- Make this activity time bound. It is possible that the spike story itself can’t be estimated but the rough idea about the time to spend on the investigation should be given by the developer.
- Add the developing of a feature story in subsequent iterations so that it will not increase the level of uncertainty in that sprint.
Combining User Stories:
There are cases where the stories are estimated to be about half a day or maybe less. In such cases, the stories of the same estimates can be combined that could take multiple days to develop within a single sprint.
As a new user, I want to pay for medium membership with Visa Card.
As a new user, I want to pay for medium membership with Master Card.
As a new user, I want to pay for medium membership with PayPal.
If a developer gives 3 days to implement one type of a payment method and one day each for other two types than it is good to combine these stories into a single story to fit in the sprint.
Testable:
Stories need to be testable and the best way to define the definition of done for a particular user story is to write ‘Acceptance Criteria’, that is the last C of the user story. This will help the developers to build the right thing. Quality ensures the feature built correctly and delivers what was promised.
Putting it all together
INVEST helps team write effective stories and encourage teams to eliminate problems such as dependencies between stories, helps in effective planning, and intelligent prioritization.
Reference(s):
- There is this series of articles ‘Why it pays to INVEST in User Stories’ by Dean Peter in which he explains each criterion in detail. Give it a read!
- Mike Cohn book ‘User Stories Applied’.
- Mike Cohn ‘s blogs: https://www.mountaingoatsoftware.com/blog
