User Story — The What, Why, & How?

With the advent of Agile software development, the concept of user stories has replaced the need to write lengthy documentation on functional requirements. Keeping in line with this trend, Product Managers adopt user stories to communicate features of a product to engineers while keeping a user-centric perspective.

A User Story is a simple, yet extremely powerful unit of work in Agile: It describes a functionality from a user’s point of view, It is geared towards an end goal and the format is very simple and easy to use.

Photo by Etienne Girardet on Unsplash

Also attached to User Stories are…Acceptance Criteria

In Agile, the acceptance criteria sometimes called the “definition of done” refers to a set of predefined requirements that must be met to mark a user story complete. Acceptance criteria also determines the scope and requirements that must be implemented by developers to consider the user story finished.

As a product manager or product owner, you may be responsible for writing acceptance criteria for the stories in your product backlog.

A User Story takes this format :

As a <persona>, I want to <be able to perform/do something> so that <goal>

Acceptance Criteria format:

“Scenario: <explain scenario>. Given <how things begin>, when <action taken>, then <outcome of action>.”

eg of a User Story and Acceptance Criteria for a Medium user-

As a Blogger, I want to be able to see comments from my readers, so that I can receive feedback or improve etc.

Scenario- A blogger has posted a story and received a comment from a reader

Given that a Blogger has published a story, when s/he clicks on a notification about a comment dropped by a reader, then s/he should be able to view comment dropped by a reader.

Benefits of User Stories

1. User stories help the team achieve clarity on what to build, for whom, and why.
2. User stories help remove technical dimension, so any member of the team can contribute, simply by thinking ‘as a user’.
3. User stories allow for quick implementation and user feedback.

Some guidelines to consider while writing great User Stories -

The format is simple, and easy to use. But writing great stories can be tricky. Some guidelines to consider:

User stories are not tasks

A story might need hundreds of single tasks for it to be successfully delivered. Tasks have to do with implementation, while user stories have to do with definition.

All about your users

Users of your product need to be discovered and studied — research their profiles, points of view, expectations, and the associated pain points. This helps to generate insights to help you better understand the users and their needs.

They should be high-level

They need to be high-level, accurate and precise. Stories must be simple, in order to help the team and stakeholders deeply understand the user needs, and avoid using buzzwords, terminology, and acronyms.

Don’t forget epics

Epics are higher-level stories, which describe large units of functionality — A feature. Epics require a significant amount of work, across multiple sprint cycles. Epics are a combination of related, smaller stories, all gearing towards a common goal.

Think big

When working on your product backlog, there is no reason to limit your creativity or ideas by budget, time or cost.

A good operation is to think big and let ‘crazy’ user stories enter the backlog.

Target success — not just acceptance

Acceptance is great but not enough — you need to also target success. As a product manager, you need more than a ‘it works as it should’. Don’t forget about your product metrics that links to user feedback, capturing how happy, engaged and how often your users come back to use your product.

Some Characteristics of a good User Story

Bill Wake introduced the INVEST in 2003 to help us remember the characteristics of a good user story:

1. Independent- they should be independent of each other so you can freely move them around your product backlog as priorities shift.
2. Negotiable- Details of a user story should be laid down in order to foster collaboration between your customer and the team that’ll implement it. This collaboration includes negotiating the scope: what the implementation will and won’t include.
3. Valuable. A good user story has value to the customer (which may be an internal user). Without that value, there’s no point in putting any effort into the story.
4. Estimable. If a story cannot be estimated, it means the scope isn’t understood well enough, or the scope is too big to estimate easily. You don’t need exact estimates, but when you can estimate a story it’s also more negotiable. Plus you’ll be able to differentiate between valuable low effort and not so valuable high effort stories.
5. Small. User stories should require small efforts to implement. At most a few weeks (by a single person), though many teams use ‘a few days’ as their limit. Smaller stories are easier to estimate. Big stories are harder to estimate, and thus less negotiable.
6. Testable. If your user, in collaboration with the implementing team, can’t tell you how to verify you’ve implemented what s/he wants, you haven’t created enough clarity about the story yet. Writing down the acceptance criteria, also known as specification makes a team more productive by avoiding rework as a result of misunderstandings.

The 3 C’s in User Stories

• Card- stories are written on cards and these are used for prioritizing, estimating, and scheduling. You can add notes about priorities and costs etc.
• Conversation- conversations, open discussions, between the customer and those involved in implementing it are conducted in order to come up with specific requirements and provide the clarity needed for implementation.
• Confirmation- Confirmation are the acceptance tests that confirm whether the acceptance criteria are met by the software.

Well written user stories provide a solid basis for communication and collaboration while focusing on what matters most to the user.