User Stories in Agile Product Development

In agile product development teams, Business Analysts or Product Owners are often tasked with the responsibility of writing clear and meaningful user stories.

Today I thought of sharing my two cents on user stories - What they are, and why and how you use them in Agile development.

What is a user story?

In Agile a user story is a short, informal, plain language description of what a user wants to do within a software product to gain something they find valuable.

 They typically follow the below narrative:

As a [type of user],

I want [an action]

so that [a benefit/value]

Real world examples of user stories:

Example 1: As a frequent flyer, I want to see all the flights from point A to point B so that I can make an informed decision.

Example 2: As an ecommerce shopper, I want to filter my searches so that I can find products quickly as per my preference.

Example 3: As a WhatsApp user, I want to create a group and add people in it so that I can connect with all of them at once.

Why write user stories? What are their benefits?

• Simplified format: User stories are written in easy-to-understand language. This eliminates confusion and makes it easier to grasp what the customer is looking for.
• Better context: With user stories you give a development team the context and the why of what they’re creating. Doing so helps them understand how they’re providing value for the business and to keep the user/customer top of mind.
• Improved collaboration: When team members are aligned on one goal, they can work better together and collaborate easily with other project stakeholders.

Who writes them?

In Agile, creating and writing user stories is a collaborative effort. You get the most benefits from user stories when they’re created in open discussions between customers, business professionals, developers, testers, designers, and other people with a stake in the software.

When are they written?

User stories are written throughout the agile project. Usually a story-writing workshop is held near the start of the agile project. Everyone on the team participates with the goal of creating a product backlog that fully describes the functionality to be added over the course of the project or a three- to six-month release cycle within it.

 What makes a good user story?

So you’ve written your user story. But how do you know if it’s any good? Agile teams assess the quality of stories by using the INVEST acronym. This stands for:

• Independent: The user story should be independent of all others. Because they are not connected, they can be worked on in any order.
• Negotiable: A user story should be flexible enough to allow for negotiation between the customer and product owner.
• Valuable: What value does the user story bring? If you cannot find any value, the story should not be completed.
• Estimable: You should be able to estimate how long a user story will take so that you can effectively manage your time.
• Small: The user story must be small enough to be completed within a single sprint.
• Testable: You must be able to test your user story in line with quality assurance standards.

If a user story does not meet the INVEST criteria, it should be rewritten or removed from the epic. However, if it does, your team members can get to work.

With all this information, I hope you’d be able to write beautiful user stories while working on your next project and collaborating with team members and other project stakeholders.

All the best!

Check out these resources to learn more about users stories:

• User stories
• User stories: What are they and how to use them
• How to promote your colleagues to write better user stories