In previous two articles, we discussed:

Becoming user centric with User Stories and

How to write good User Stories

In this article, lets understand the fundamental benefits of good User Stories. I challenge teams that I coach to strive to realize all of these User Story benefits.

While you read the article, I encourage you to think: how can you get maximum value from applying User Stories? It could be a competitive advantage for your team!!

Don't forget to take your User Story Benefits Assessment at the end of this article.

Without further ado, here are the

Good User Story Benefits: 

1. Highest Value Delivery:

This User Story Benefit is the mother of all benefits. Done well, User Stories help deliver the highest value by focusing on small and immediate customer needs.

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 delivering 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 into small features or tasks that can be implemented and delivered from few hours to few days. The ProductOwner 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.

Delivery of highest value early in the product development allows the Product Owner to:

a) Start earning returns early.

b) Reduces the amount of investment that the organization needs put in - as the return from the product starts to pay for the new feature development at some point during the development.

c) Significantly increase the ROI.

2. Fosters Collaboration:

Good User Stories due to their minimalist characteristic, inherently give way to collaboration among the product development team, the Product Owner and the users of the product. While the traditional teams depend heavily on detailed documents and electronic tools, most Agile Teams collaborate with users to plan, implement and deliver customer value.

Minimal writing of the user's needs encourage the team members to talk to the user(s) or the Product Owner when they are ready to implement a UserStory. These discussions allow room for diverse business-technical perspectives to come to light and gives way for creative and innovative ways of solving customer's needs.

3. 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 end 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 users by demonstrating implemented User Stories as soon stories are DONE.

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

4. 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 a 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.

User Stories allow for easy addition and removal of features from the Product.

If the Product Owner decides to remove a non-performing feature from the product, it becomes easy to immediately toggle off a feature that was built as a small user story.

During development, when a user story acceptance criteria do not pass, the Product Owner can exclude that one story and still release rest of the features to production.

5. 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.

Order of User Stories creates transparency about,

a) the priorities set by the Product Owner and

b) the customer segment / persona that is being addressed through a particular user story.

If any story has dependencies and is stuck, the impediment becomes immediately visible to all.

Transparency reduces a lot of waste from the process and improves team's effectiveness.

It is not uncommon for teams transitioning from traditional software development practices to Scrum, to write user stories as long documents.

Prompting these teams to store (freeze) these long written stories in electronic document repository or a tool. Most of the tools are not designed to radiate information or improve transparency. Severely reducing the transparency of User Stories and related information.

Any practice that hampers the transparency effectively slows down a team and increases churn.

The most effective tools - Index Cards and Sharpies are not meant for writing long documents.

Improved Transparency is a serious advantage teams can get from user stories. Higher transparency could be a game changer for teams new to Scrum.

6. Shared Understanding:

How can better 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, and split the user stories.

Working collaboratively improves the shared understanding of:

a) what is expected by (need of) 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.

7. Reduced Risk:

Bonus benefit number 7. There is one more important User Story benefit that is Reduced Risk.

Most traditional teams are not equipped with and lack proactive measures of reducing risk.

Effective User Stories by creating transparency, improving collaboration, creating shared understanding and orienting the teams to focus on customer needs, eliminates various potential risks such as - lack of communication risk, technical risk, financial risk, business risk, etc.

While getting all these user story benefits would be sexy, many teams have asked me questions such as:

> Are these user story benefits achievable?

> Do other teams get these benefits?

> Does any team fully realize all these benefits?

> What are usual challenges that prevent teams from getting all these benefits?

To help you explore your own answers, I've created User Story Benefits Assessment. In about a minute, you can self-assess and get instant scores.

I just want to say, many times the appreciation of these User Story benefits come only when any risks arise from not having these benefits.

Actionable Tip: Let me invite you to identify and share in comments below - potentials risks for your product and team if these benefits of good user stories are missing.

Evaluate the User Story Benefits You Get Today!!

Evaluate and get your score now!!

Disadvantages of User Stories

Yes, while the User Stories are good and beneficial to a team's agility, it also carries certain disadvantages.

Compliance Needs - Should you need a requirements document for compliance needs - User Stories will not suffice in most cases. Though I would highly recommend you first talk to your auditor or compliance team proactively before making a call on this.

Knowledge Transfer - Should a major shuffling happen within your team or suddenly 2-4 team members leave your team and new members join - User Stories will not help with the knowledge transfer. Well, neither do the detailed requirements do it fully. At least index cards won't be sufficient in this case to get started. Some team member or the Product Owner will need to take out time to get the new team members up to speed.

Interpretation - Minimal detail subject the User Stories to different interpretations. It may sometimes happen that the team members may miss having a detailed conversation on every aspect of the story. This may invite assumptions and interpretations which may cause errors.

Acceptance Criteria Definition

Acceptance Criteria defines how a particular feature could be used from an end user’s perspective. 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 for the success of the feature.

Acceptance criteria could establish a boundary that helps team members 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 behavior in happy path scenarios, it also guides the user experience when things don’t work as intended. It describes what would be verified by the acceptance tests.

When the product owner verifies particular user story acceptance criteria and the developed feature passes it, 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 team 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 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 must have 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 – when relevant.
7. Team members write acceptance criteria and the Product Owner verifies it. It confirms the PO and the team have shared understanding of the user story.

Acceptance Criteria examples

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.’

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).

Challenges with writing Effective Acceptance Criteria

Despite being simple to write, yet powerful, the task of writing acceptance criteria looks challenging for most teams. It’s not uncommon for teams to make simple mistakes and repeat errors when writing Acceptance Criteria. Some of the most common challenges and mistakes I’ve noticed with acceptance criteria from user stories I’ve seen in the real world are:

Pretty Narrow: Acceptance criteria is written very specific to a particular use case, scenario or technical approach.

Keep in mind, when you already have a solution in mind while writing the acceptance criteria, you end up leading your developers in that particular direction. In most cases, that may not be the optimum / best way of solving the challenge. Also being too narrow may mean that your testing may skip other user behaviors not specified in the AC. This increases the chances of missed testing, increases the risk of failure.

Very Broad: Acceptance criteria is written pretty broad.

Too broad acceptance criteria usually increase the risk of the user story being too bulky and may introduce fat in the features. Good acceptance criteria as discussed above should establish boundary so that the developers know how much to code and where to stop.

Complex: Acceptance criteria is complex, includes jargons and technical details.

Good acceptance criteria should be written in simple English and should be easy to understand. The key is to keep it simple.

What are the challenges you find with writing acceptance criteria?

Let me know in comments and I’ll address your most common challenges.

Who writes Acceptance Criteria?

Let me first burst a common myth that the Product Owner should write the acceptance criteria.

In fact, I recommend, you try ‘avoiding’ the Product Owner writes all the acceptance criteria. Why so?

Who writes the acceptance criteria, or who defines the acceptance criteria is not a matter of rules, availability 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.

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

Writing the acceptance criteria 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.

Alternately, Acceptance criteria may also be developed jointly by the development team and the product owner.

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 can, please go ahead and split the user story right there. Thank me later 🙂

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 critera 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 for User Stories 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 LinkedIn, Twitter, Facebook and Email