Administrator

User Stories! they do sound simple when we hear them for the first time. Surprisingly, it is not the case when taking up the actual job. Writing user stories in such a way to minimize the ambiguity, inter-dependency etc.  while maximizing the value to the stakeholders is not always simple. 

I have encountered the same problem and came across a useful mnemonic, which gave me the right solution I have been questing for; the INVEST approach for user story writing.

Why do you invest in anything?

We invest in a wide range of things. Some invest in stocks, treasury bills or real estate. A Business Analyst can INVEST in writing good user stories, aiming for the best understanding of his/her stakeholders! 

In agile software development, the textual requirements usually come in the form of user stories. The common format of a user story is,

As a <user> I want <goal> so that <reason>

User stories are referred to by various stakeholders like customers, Project Managers, Developers, Quality Engineers etc.. Therefore, writing good stories brings an indispensable value, to maintain the mutual agreement between stakeholders on the requirements. 

One such approach to get user stories ‘right’, is INVEST! 

Why did Bill Wake come up with INVEST?

In 2003, Bill Wake in his book Extreme Programming Explored, coined the term ‘INVEST’ for the first time. He described a set of 5 aspects that should be taken into consideration when writing a good user story. 

The birth of a good user story began there!

Let us decode INVEST!

INVEST is an acronym that describes 5 fold aspects of a good user story.

• Independent:  When delivering requirements, two user stories should function as independently as possible. There are three types of dependencies that can exist between user stories as; 

1. Overlap Dependency

User stories should not deliver overlapping requirements. Such stories will create confusion on whether requirements were covered in at least  one of them.

1. Order Dependency

User stories should be able to work in any order- not “this feature should be implemented after that particular feature” way. Sticking to particular order will complicate the development unnecessarily.

1. Containment  Dependency

Though it is helpful to arrange user stories hierarchically for better understanding, it might not always list the most valuable stories on the top.

• Negotiable: A user story should grasp the cream of the requirement, not essentially the details. The negotiation between customer and the team will derive the actual result. The goal of the user story should be to reveal the true need of the customer. 

• Valuable: A user story should be valuable to the customer/intended user of the story. User stories should be prioritized in such a way to deliver value to the end user.  <So that> part in user story format usually unveils the reason for doing this. Any user story that does not carry a perceptible value to its user should not be done.

• Estimable: A user story can be prioritised after it is estimated. This estimation can be a rough value. In case the story cannot be estimated, breaking into a few other user stories will give more sharpness and clarity to the stories.

• Small: The user story should be a small chunk of work rather than a big chunk of work which is not scalable. They can be completed within a given time period(sprint). This time period varies depending on the methodology the team follows. E.g.: for agile, it is usually 2 weeks.

• Testable: A good user story should be testable to the team as well as end users. It ensures the shared understanding between the stakeholders. When writing the user story, the acceptance criteria  unveils the testable points in the story.

An Example is worth many hours of reading!

Let us see the following requirement.

User Requirement

“The ABC bank maintains a website for its customers. During the pandemic, the bank encourages its customers to use e-banking services offered via the website without visiting the bank premises in person. As a security measure, the bank expects to introduce OTP facilities for its customers.”

User Story

“AS AN ABC bank customer I WANT to use one-time access code to access e-banking services offered from bank website SO THAT I can securely complete transactions from my account online”

Does this user story INVEST-able?

It can definitely be improved!

Some of the questions that come to mind after reading above user story are,

• Do all the customers of this bank get web access? 
• If not, which type of customers(Existing/Inactive etc.) has the access?
• What should be the behavior of the system if the existing customer who has intentionally opted out from the above facility logs in?
• What should be the behavior of the system if the existing customer has opted in for the above facility and logs in?

Assuming that the existing account holders of the bank who have opted in to OTP facility will be using this feature, let’s recreate our user story.

“AS AN existing ABC bank account holder with OTP facility, I WANT to use one-time access code to access e-banking services offered from bank website, SO THAT I can securely complete transactions from my account online”

Now the above user story is Independent. 

It is also Negotiable because, if the bank decides to extend this OTP facility to its mobile application also, then we can further break down the user story as below.

“AS AN existing ABC bank account holder with OTP facility I WANT to use one-time access code to access e-banking services offered from mobile application SO THAT I can securely complete transactions from my account online”

The new user story brings Value to its account holders by allowing them to securely complete the monetary transactions online. From the perspective of the bank, it will ensure the authenticity of the transactions occurred and limit online frauds. 

The user story is now Estimable as we have broken it down into independent, negotiable, valuable and small chunks. 

It is also Small enough to be developed within a sprint. 

Finally, the user story is Testable with all above qualities acquired.

Towards excellent user stories!

As depicted in the above example, the INVEST approach to user story writing delivers a wide set of advantages to not only the Business Analyst but also to the entire pool of stake stakeholders.  

In practical terms, INVEST approach, 

• minimizes occurence of dependencies between user stories(most valuable stories first!), 
• identifies the right value and builds around it(we don’t build useless features!), 
• not going for big chunks of work but estimable and small work chunks. 
• helps maintain the shared understanding among stakeholders(Customer, Project Manager, DEV team, QA team etc.).

As someone who is already using this approach, I have been able to procure many of the above benefits.

Therefore, it’s high time that you INVEST on user stories you write!