6 Benefits of Good User Stories

6 Benefits of Good User Stories

In previous two articles, we discssed:

Becoming user centric with User Stories and

How to write good User Stories

In this article, lets understand the benefits of good User Stories and how you can turn it in to competitive advantage?


Without further ado, here are the 6 benefits of good user stories.


Highest Value Delivery:

User Stories help deliver highest value by focusing on the small and immediate customer needs. The traditional product development teams may spend months on a single function such as analysis, design, implementation etc, carrying a significant amount of work in progress without deliverying anything that is directly valuable to the customer immediately.

How could you take the old school requirements approach and turn it upside down?

Agile Teams break down user needs in to small features or tasks that can be implemented and delivered from few hours to few days. Product Owner actively prioritizes these user stories in terms of user value, risk and business value to significantly increase the value delivered by a team within first few sprints.


Fosters Collaboration:

Good User Stories due to their minimalist characteristic, inharently give way to collaboration among the product development team, the Product Owner and the user of the product. While the traditional teams depend heavily on detailed documents and electronic tools, most Agile teams collaborate to plan, implement and deliver customer value. Minimal writing of the user’s needs encourage the team members to talk to the Product Owner or the user when they are ready to implement a user story.


Brings User Closer:

By focusing on delivering highest customer value with each user story, the Agile teams are compelled to regularly connect with and collaborate with users. Minimally written detail also encourages for the team members to talk to the user. The team members directly connect with the user to understand the user’s perspective, challenges, pain points and opportunities that need to be addressed. The team members also get early feedback from the user by demonstrating implemented User Stories as soon they are Done.

In case if you haven’t read yet, check out my article – Becoming User Centric with User Stories

Building Blocks of the Product:

With each customer value delivering User Story, the product is built incrementally. Building the product incrementally allows to rapidly adjust it to new direction. When sliced in smaller ideas to experiment, user stories allow for quick implementation and user feedback. With each successfully implemented feature, the product gets shaped and the value of the product keeps increasing. If the Product Owner decided to remove a not-so-popular features from the product, it becomes easy to toggle off a feature that was built as a small user story.


Boost Transparency:

Written collaboratively on index cards, User Stories increase transparency among with the team member, Product Owner and stakeholders. The index cards remain visible to everyone and allow for better collaboration and faster decision making. Improved transparency also increases the Trust within the environment. User Story also create transparency of the priorities set by the Product Owner and the customer segment / persona that is being addressed through a particular user story. If any story is has dependencies and is stuck, the impediment becomes immediately to all. Transparency reduces a lot of waste from the process and improves team’s effectiveness.

It is not uncommon for teams transitioning to Scrum, to write user stories as long documents that is stored (frozen) in an electronic document repository or a cloud based tool. Any practice that hampers the transparency effectively slows down a team and increases churn. This benefit of good user stories could be a game changer for teams new to Scrum.


Shared Understanding:

How can User Stories create shared understanding? Unlike the traditional approach where the business team writes requirements and hands over the documents to the development team to implement, the Agile approach is for the Product Owner and the Development team members to collaborate and collectively develop, refine, split the user stories.

Working collaboratively improves the shared understanding of:

a) what is expected by the user and what is feasible from technology and business perspective.

b) what is intended by the Product Owner and what is understood / implemented by the development team.


Reduced Risk:

Bonus benefit number 7. There is one more important benefit of good user stories that is Reduced Risk. Most of the times the teams are not equipped with proactive measures of reducing risk. Good user stories by creating transparency, improving collaboration, shared understanding and orienting the teams to focus on customer needs, eliminates a lot of risks.


Actionable Tip: Many times the appreciation of these benefits comes when we realise the risks of not having these benefits. Let me invite you to identify and share in comments below – 5 potentials risks for your product and team if these benefits of good user stories are missing.

How to grow your leadership impact?

One of the essential aspects of being a leader is that you constantly reflect and adapt your leadership impact on the people you lead. Evaluate...
Read More

Top 21 Scrum Master skills

Top 21 Scrum Master skills in 2020? The use artificial intelligence in product development and corporations is growing significantly. With the help...
Read More

6 Benefits of Good User Stories

Read More

Essential Building Blocks of an Agile Organization

Creating cross-functional and self-organizing Teams is one of the essential element of building an Agile Organization. Both aspects require...
Read More

How to write Good User Stories?

storytelling user story

Why care for writing good User Stories?

Good User Stories are easy to understand and implement. Crafting valuable and small user stories could in most cases solve the biggest challenge of Scrum Teams – delivering shippable product increment every Sprint.

Mastering the art of crafting good user stories isn’t easy.

When crafted well, good User Stories form the building blocks of a successful product envisioned by the Product Owner and desired by the customer.

In traditional product development environment, the Product Owner / Business Team would write a requirement they want to be implemented and the team would simply implement it, to the extent they understand it. The User Story challenges this rationale. 

It requires identifying who (a user) exactly will use the feature being asked to develop and specifies what benefit the user will get. This helps remove ambiguity and offers clarity in understanding the User’s story.

As discussed in my article becoming user centric with User Stories – A User Story is a promise to further communication that should happen between the Product Owner and the team to create a shared understanding of the story of a user. A user story card may outline “why” – the benefit, “who” – the user and “what” – the feature or action.

A user story card may outline “why” – the benefit, “who” – the user and “what” – the feature or action.

What makes a good User Story?

In order to understand what makes a good User Story, it is important to understand what the User story means for everyone involved in creating and implementing it.

Product Owner: For the Product Owner, User Stories are a way of putting user’s needs, wish list items, hypothesis and everything else required of the product on a set of cards. The Product Owner refines and orders these user story cards for the development team to work on. User Stories open avenues for the Development team to understand what they are implementing, who will benefit from it and how. For the Scrum Master, User stories also help track the progress of the team within a sprint and imbibe transparency within the team members. It makes planning the sprint possible.

Development Team: User Stories open avenues for the Development team to get closer to the user’s need, who will benefit from it and formulate how they would implement it to achieve the desired outcome. Completion of User Stories helps track the progress of the team within a sprint.

Scrum Master: The Scrum Master ensures that the User Stories are transparent and that the team members and the Product Owner have a shared understanding of the User stories. If the Product Owner and the development team are bound in written contracts called requirements documents or the User Stories and are not collaborating, the ScrumMaster can facilitate communication and collaboration. Scrum Master would take responsibility to help everyone understand the importance of keeping the user stories small, being flexible and allow for the most relevant user needs to emerge while discovery and development.

Most novice ScrumMasters end up doing just the opposite. They start helping the Scrum Team to write detailed user stories (kind of mini requirements documents), police around to ensure the electronic tool is filled with all 16 types of user story fields, detailed descriptions are written and every possible acceptance criteria are listed. Writing detailed user stories is 1st step to stifle collaboration within the Scrum Team. Traditional mindset, lack of trust in the work environment, geographical distance between the PO and the DevTeam, and client-vendor setup, all such factors encourage writing detailed requirements. The Scrum Master should be able to pick up early smells and help the Scrum Team avoid falling into such trap.

User Stories encourages the Product Owner and the development team to collaborate with the User and to stay close to what the User needs. Scrum encourages collaboration by face-to-face communication. This makes User Stories a logical fit (as a practice) with the Scrum framework.

A simple User Story template, widely used by Scrum practitioners involves these three elements:

As a <<USER>>,

I want <<FEATURE>>,

So that <<VALUE>>.

This simple template narrates the value for the User. The primary focus of the User Story written using this template should be the Business Value that the Product Owner is trying to achieve by having the User Story implemented.

How to write a good User Story?

Here are three characteristics that help craft a good User Story.

1. Identify the Business Value:

To make a product successful, the Product Owner tries to maximize the business value being delivered by the User Story. In order to maximize the business value, its important to first identify whats the Business Value that the team is trying to achieve by implementing a User Story and all the effort that goes around it. Understanding the Business value also helps the Product Owner to prioritize User Stories and have the User Stories with the highest Business Value at the top of the Product Backlog.

Example: For a new e-commerce website to launch, the highest Business Value will be when a new user is able to buy an item from the website. Let’s take a closer look. Traditionally, the line of thought for the sequential functionality being made available would have been in the below sequence:

1a. New user can register on the website

User Story Example 1:

As a First time visitor to the website,

   I want to be able to register on the website,

   So that I can browse and buy listed products from the website.


1b. Registered User can Browse items listed

User Story Example 2:

   As a Registered Website User,

   I want to be able to browse listed products from the website,

   So that I can make my choice and buy a listed product from the website.


1c. Registered User can add items to the cart

User Story Example 3:

   As a Registered Website User,

   I want to be able to add items to the cart,

   So that I can buy a listed product from the website.


1d. Registered User can make payment for the items added to the cart.

User Story Example 4:

   As a Registered Website User,

   I want to be able to buy listed products,

   So that I can use the product I buy.


Looking closely at the User Stories above tells us that the website visitor would not be able to make a purchase on the e-commerce website till the time User Story 4 is implemented and made available at the website.

The Human brain thinks sequentially, step-by-step and the above User Stories are evidence that the Product Owner writing the above user stories is looking at the website from the perspective of the end user and trying to depict his/her sequential line of thought.

Now if you wear the hat of a Product Owner, you must think about how can the highest Business Value be delivered early?

That requires prioritizing user stories in a way that the highest Business Value User Story finds its place at the top of the Product Backlog.

If you thinking out of the box and not sequentially as the human brain is trained to think, here is an alternate option to craft the User Story:

User Story Example 5:

   As a First-time visitor to the e-commerce website,

   I want to be able to buy listed product,

   So that I can use the product I buy.


This means that the First-time visitor to the e-commerce website should be able to make the payment as a guest user without having to register – User Story Example 1.

Does buying the product has more value than Browsing products – User Story Example 2? Sure, any day.

Adding chosen products to the cart – User Story Example 3 is a nice to have and allows the user to buy multiple items at the same time. However, being able to buy the product – User Story Example 5 without registering, browsing or adding the products to the cart has the highest Business Value.

2. Identify the “who”:

It’s important and imperative to identify the Customer being served before you craft a User Story. One of the most common mistakes done by novice Scrum Teams is to generalize the User segment being served by a User Story.

Identifying a narrow and specific User segment being served by the User Story, helps reduce the size of the User Story.

The User Story becomes specific and clear as to who is being targeted. Many Scrum teams use User Personas for their product and specify a particular persona for each user story.

Example: I had once worked on a capability that was available for all Credit Card users on the desktop. Our team was developing the set of features to make the capability available on an App for Tablet and Mobile users.

The team started with this format:

   As an App user,

   I want <<FEATURE>>,

   So that <<VALUE>>.

Now we had an option to split as a “Mobile App User” and “Tablet App User”. The Product Owner prioritized the “Mobile App User” over the “Tablet App User” since that User Segment had higher volume and more business value. So, the PO chose to go with:

   As a Mobile App user,

   I want <<FEATURE>>,

   So that <<VALUE>>

Then, we had an option to split the user story as an “Andriod Mobile App user” or “iOS Mobile App user”. The Product Owner prioritized the “iOS Mobile App user” over the “Android Mobile App user” since that was a User Segment with even more business value. So, we chose to go with:

   As an iOS Mobile App user,

   I want <<FEATURE>>,

   So that <<VALUE>>.

In addition to this, we had Silver, Gold and Platinum Credit Card, holders. The Product Owner prioritized the “Platinum Credit Card holder” since that was a User Segment with highest business value. Our user story looked like:

   As an iOS Mobile App user holding a Platinum Credit Card,

   I want <<FEATURE>>,

   So that <<VALUE>>.

This is the level where the Scrum team was clear as to who was served by implementing the User Story.

Identifying a very specific user segment provides clarity, creates shared understanding, reduces risk and results in improved ROI for the efforts.


3. Understand the “what”:

Communicating clearly “what” will be delivered as a part of the User Story is crucial too. This is the part of the User Story where the customer has an avenue to communicate his/her perspective of what s/he needs – feature, enhancement, etc.

Example: In another implementation that I had a chance to work on, we were implementing the approval system of a large Custodian bank. Can you believe they were dealing with Billions of Dollars yet the process was pretty much manual?

Anyways, using this Business Process Management tool, various departments involved would review and approve the application from a Sub-custodian bank to become a registered Sub-custodian to the Custodian based in the United States. The end goal was to create an automated system where:

  1. The interested Sub-custodian would apply online with all the details and documentation required by the Custodian, once that is done
  2. The Custodian would do multiple levels of review within the departments that existed in the Custodian bank.
  3. The application would then be sent to the regulatory body for their approval.
  4. Once approved by the regulatory body, the Custodian Bank would revert to the Sub-custodian requesting additional documentation required to formalize and close the registration process with the Custodian Bank.

As it appears, this was a huge task by itself. The team decided to break it down into bite-sized features. Although the team was going to use an off the shelf product with most of the functionalities required, yet there was a lot of customization required at each step.

With the array of features required to be implemented, we chose to first target the internal audience with the Custodian bank and the various departments within the bank whose approval was required as part of the registration process. We narrowed down the User to one department within the whole approval flow. We then decided to drop off the option of being able to attach the documents to the approval flow. Now the User Stories looked like:

   As a Registration team member,

   I want to be able to review the Sub-custodian application,

   So that <<VALUE>>.


   As a Registration team member,

   I want to be able to approve the Sub-custodian application,

   So that <<VALUE>>.


   As a Registration team member,

   I want to be able to reject the Sub-custodian application,

   So that <<VALUE>>.


These were easier to understand and also gave the Scrum Team a perspective into what’s being sought. Each User Story was crafted in a way that it could be implemented within a Sprint. Breaking it down to the specifics removed ambiguity.

In summary, nailing the “who”, “what” and “why” of the User Stories, making them transparent, valuable and small makes them viable survivable experiments for the Scrum team. It allows the Scrum Team to learn fast and inspect and adapt, resulting in reduced risk and better alignment with customer needs.

Do you have a story to share that your team crafted well and delighted the customer?

7 Tips for writing Acceptance Criteria

7 Tips for writing Acceptance Criteria

Acceptance Criteria

Acceptance Criteria defines from an end user’s perspective, how a particular feature could be used. It focuses on business value, establishes the boundary of the feature’s scope and guides development. These are unique to a user story and form the basis of user story acceptance testing which establishes the conditions of success of the feature.

Acceptance criteria could establish boundary that helps to understand what’s included and what’s excluded from the scope of the user story. The criterion of user story acceptance not only informs the product behaviour in happy path scenarios, it also guides the user experience in the case if something doesn’t work as intended. It describes what would be verified by the tests.

When the product owner verifies particular user story acceptance criteria and the developed feature passes the criteria, the development of the user story is considered a success. Pass / fail type results allow AC to form the basis of creating tests that can be automated and executed.

Tips for writing Acceptance Criteria

An essential aspect of writing good user story involves writing good acceptance criteria. It is the key to effectively testing the developed functionality. It allows the acceptance-criteria-tips-agile-for-growthteam members writing acceptance tests to understand the scope of the user story or Product Backlog Item (PBI).

How to define acceptance criteria? Here are some useful tips for writing AC for user stories. Some of the Scrum teams I’ve worked with preferred to use these ac tips as a checklist for writing good acceptance criteria. Acceptance criteria checklist helped with consistency and acted as training wheels for new team members. I encourage the teams to keep revisiting and revising these tips to fit their need. I would also forewarn to avoid using these tips as fixed rules.

7 Tips to write Acceptance-Criteria

Here are 7 tips for writing acceptance criteria:

  1. Each product backlog item or user story should have at least one acceptance criteria. Hey don’t take writing acceptance criteria lightly or think of skipping it.
  2. Acceptance Criteria is written before implementation – this is obvious yet frequently missed by teams. Write acceptance criteria after the implementation and miss the benefits.
  3. Each acceptance criterion is independently testable. Why shouldn’t it be?
  4. Acceptance criteria has a clear Pass / Fail result. Write complex and long sentences at your own risk.
  5. It focuses on the end result – What. Not the solution approach – How.
  6. Include functional as well as non-functional criteria.
  7. Team members write the acceptance criteria and the Product Owner verifies it. It confirms the PO and the team have shared-understanding of the user story.


Who writes acceptance criteria?

Acceptance criteria are usually developed jointly by the development team and the product owner. Who writes the acceptance criteria, or who defines the acceptance criteria is not a matter of rules or convenience.

What matters is – writing acceptance criteria (AC) should help establish and communicate shared understanding between the product owner and the development team about solving a customer’s challenge or building the product capability.

One practice your can try avoiding is where the Product Owner writes all the AC. Why so?

When you encourage the team members write the AC, they must first understand the intended purpose of the feature and the outcome it must generate for the users.

Writing AC clarifies the scope for the team and also allows for the Product Owner to verify if the team and the PO have a shared understanding of the feature.

Acceptance Criteria examples

Product Backlog Item (User Story) example

acceptance criteria example for Pay Balance Due PBI

Example 1: User story and it’s acceptance criteria:

As a credit card holder, I want to view my statement (or account) balance, so that I can pay the balance due.

the acceptance criteria for this story could be:

  • Display statement balance upon authentication. Say for example $1560
  • Display total balance. For example $3560. Here the balance due from the current period is $2560 and past balance due is $2000.
  • Show Minimum payment due. For example $140
  • Show Payment due date. For example May 16th of the current month
  • Show error message if service not responding or timeout. For example ‘Sorry, something went wrong with the service. Please try again.’
User Story example 2

acceptance criteria example for student performance PBI

Example 2: User story and it’s acceptance criteria:

As a teacher, I want to generate assessment report, so I can evaluate student performance.

the acceptance criteria for this story could be:

  • Show a student’s current assessment score.
  • Display past assessment score of the student.
  • Provide an option to Print / Save / Share. (By the way, this could be split as a separate user story by itself).
  • Display error message if service not responding. (If a team chooses to add the Error Message as their definition of done for all stories – where ever applicable, it could be omitted from the acceptance criteria).

What is the right amount of Acceptance Criteria?


Well, if you’ve too many AC for a single product backlog item (PBI), chances are you could split it into multiple PBIs.

Tip: Have too many criteria as part of one story and chances are you’ll easily run into at least one criteria that isn’t passing.

That delays the delivery of that user story, which delays the feedback, ultimately increasing the risk of failure. I recommend, whenever you have got a chance, please go ahead and split the user story right there. You can thank me later 🙂

acceptance criteria detail for user stories

Splitting user stories helps in keeping each user story small, improves chances of delivering it early, seeking feedback faster, hence reduces risk. Yes, there is effort involved in splitting the user stories as well.

Hence, the PO and the development team have to identify for each user story, what is a barely sufficient detail of AC. Photo source: Kenny Rubin, Innolution where Ken discusses the pros and cons of adding too many details versus no detail and establishes the need to identify what is barely sufficient detail to get started.

It’s important that your team members spend a little time and get good at writing acceptance criteria. It’s benefits are long lasting and ROI of the effort is simply too high to ignore.

Rule of Thumb: My rule of thumb for number of acceptance criteria is to have between 1-3 per user story. If a user story have between 4-5 of these, I start exploring options to split the story. If there are 6 or more criterion then the chances are the team won’t be able to implement it all in one sprint, definitely this story needs to be split in more than one.

Remember small user stories with lesser scope can be delivered comfortable within a sprint and presented to users for feedback. Early feedback reduces risk and impact of failure.

When to write Acceptance Criteria?

Acceptance criteria (AC) should be written anytime before the user story is deemed ready to enter the Sprint Planning. Usually it is written during the product backlog refinement meeting. AC can be progressively developed and added to a user story during the refinement. However it should not be kept for when the development team start implementing a user story.

“If we write and review the acceptance criteria before implementation begins, we’re more likely to capture the customer intent rather than the development reality” writes Steve Povilaitis.

To ensure the AC is defined for each user story upfront, many teams add writing acceptance criteria to their User Story Readiness Checklist. User Stories that do not have at least one AC can’t enter the Sprint Planning itself. Well, that shouldn’t prevent the team from exploring the intent or refining the AC after the Sprint Planning / before the implementation when the team members have conversations with the Product Owner.

What you should do now

1. If you’d like us to work with your teams — to dramatically improve your product management, product development, organizational agility, and growth (like we did for many clients from fortune 500s to young startups), then leave your inquiry and claim a free Agile Coaching strategy session. On this free phone consultation, one of our expert coaches will discuss your agility goals and suggest strategies to improve your team and organizational agility.

2. If you’d like to assess your team agility for free, go to our Agile Assessment, where you can instantly evaluate the current agility of your team and identify the gap between their current state and desired state. Or, if you’d like us to build your company’s in-house capabilities to be Agile (not for free), then contact us and we’ll discuss your requirements.

3. If you’d like to read further —  see our recent insightful Scrum articles

4. If you enjoyed this article, so will your friends. Why not share it on LinkedInTwitterFacebook and Email

Subscribe To Our Newsletter

Join our mailing list to receive the latest news and updates from our team.

Awesome. You've successfully subscribed.