Writing user stories with INVEST criteria

You’ve probably heard about user stories at some point thanks to how common they are throughout the IT Industry, and depending on your role, at some point, you’ve probably even thought: “How are User Stories written? Is there a correct way to do it?” – as it turns out, there are indeed some widely accepted criteria for that, also known as “INVEST”.

What is a User Story?

Before we go any further, let’s make a quick reminder of what a User Story actually is. A user story is a representation of a written requirement from the perspective of an end user. User stories are normally short, not too specific, and are written using natural language that the user can easily understand – in other words, it’s important to avoid using jargon or specialized terminology that can confuse an end user.

Let’s take a look at the structure of a regular User Story:

As a (user or persona) I want (some goal) so that  I can (some reason/ benefit).

These components can be divided into:

Who: This typically represents the user persona.
What: This is the goal that the user is looking to achieve.
Why: This is the reason why the user is requesting the what.

And now, here we have an example of that structure applied to an actual User Story:

As a Sales Rep, I need to see the total number of deals closed for the current year on the homepage, so that I can easily keep track of my performance.

Notice how this user story can easily be understood as it doesn’t contain any specialized terminology; an example of a User Story that you should avoid would be:

As a Support Agent, I need an Apex Batch for Accounts to run every morning at 8:00 am, so that I can have updated values in my owned records.

Using terms like “Apex Batch” might end up being confusing for users that are unfamiliar with Salesforce Development, so it would make more sense to replace that word with something such as “Automation”.

With all that said, let’s check what this “INVEST” is all about.

What is INVEST?

As detailed by Agile Alliance, INVEST is an acronym that originated from an article by Bill Wake, published in 2003; he repurposed the acronym SMART (Specific, Measurable, Achievable, Relevant, Time-boxed) for User Stories; the acronym itself stands for:

“I” ndependent -> Ideally, the story should not depend on other stories, as this can negatively impact planning.
“N” egotiable -> Remember we said to avoid using specialized terminology and to avoid being too specific? We want to allow users to understand the story since this will allow conversations about it which normally result in more details or changes to the story.
“V” aluable -> The user story needs to add value to the customer.
“E” stimable -> A good user story should be estimable with enough precision so that it can be used when planning.
“S” mall -> User stories need to be as small as possible; an unnecessarily long user story will take more time to be completed, and will definitely affect the other items previously mentioned. Try to think of it as taking the requirement or problem, and splitting it into the smallest possible parts.
“T” estable -> User stories should be easily testable. If the QA or the user are having issues testing it, it will be hard to know if it’s fully completed and it might lead to users thinking that maybe it’s not what they wanted.

Making sure your user stories comply with INVEST will allow you to deliver more high-quality
products, and will provide you and your team with a lot of benefits. To close this up, let’s review an example of a user story and let’s check if it complies with INVEST:

As a Sales Rep, I need to be able to see more details on an Account record, so that I can see all required information in just one place.

ACCEPTANCE CRITERIA

A new automation is created which will update the “Custom Name” field whenever the Account record is created or updated.
The following fields are added to the page layout under the “More Information” section:

• Custom Term

• Custom Date

• Custom Notes

Now, this story complies with being independent since it can be completed right away. It’s negotiable since it’s not very specific or uses special terminology so that end users can easily understand it. It’s valuable since it will allow the Sales Reps to save some clicks to see all data in one place. It’s estimable since we can measure how much the acceptance criteria items will take to complete. And finally, it’s testable, since a QA or User should be able to understand it; however, this story fails in that it’s not small enough.

As we can see, the acceptance criteria is mentioning automation first and then an update on the page layout. If we take a closer inspection at those two items, we can quickly realize that these are not dependent on each other (the automation doesn’t rely on the page layout to run or update the required field), which means that the story can be split further and ideally, we should have one user story just for the automation and one just for the page layout updates.

Finally, as a reminder, it’s key to keep practicing so you can get a better understanding of INVEST, so start with some examples and you’ll notice how eventually you’ll even remember what the acronym stands for and if you need help, or are looking for Project Managers that you can rely on, reach out! We will be happy to help!

---