Tips for writing Acceptance Criteria

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. Acceptance criteria form the basis of acceptance testing which establishes the condition of success.

When the product owner verifies particular acceptance criteria and the developed feature passes the criteria, the development is considered a success.

Tips for writing Acceptance Criteria

Writing good acceptance criteria is the key to effectively testing the developed functionality. It allows the team members writing tests to understand the scope of the Product Backlog Item (PBI). Acceptance criteria could establish a boundary that helps to understand what’s included and what’s excluded from the scope of the PBI.acceptance-criteria-tips-agile-for-growth

Here are some useful tips for writing acceptance criteria. Some of the Scrum teams I’ve worked with preferred to use it as a checklist for writing good and consistent acceptance criteria. 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.

Here are some tips for writing acceptance criteria:

  • Each product backlog item or user story should have at least one acceptance criteria.
  • Acceptance Criteria is written before implementation – this is obvious yet frequently missed by teams.
  • Each criterion is independently testable.
  • Acceptance criteria has a clear Pass / Fail result.
  • It focuses on the end result – What. Not the solution approach – How.
  • Include functional as well as non-functional criteria.
  • 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.

Usually, acceptance criteria are developed jointly by the development team and the product owner. Who writes it, is not a matter of rules – what matters is – it should help to establish and communicate shared understanding between the product owner and the development team about solving a customer’s challenge or building product capability.

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 acceptance criteria for a single product backlog item (PBI), chances are you could split it into multiple PBIs. Have too many acceptance criteria as part of one story and chances are you’ll easily run into acceptance criteria that aren’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 🙂

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

acceptance criteria detail for user stories

Scrum Master Focus Survey

The survey aims to compare the Scrum Master's role as described in the Scrum Guide with the reality in organizations. With that aim, I'm set out to collect the real world insights from practicing Scrum Masters, about the Scrum Master role and the focus of Scrum Masters.

If you are currently performing the Scrum Master role, please answer this survey to maintain a high relevance of the answers collected. We value candid answers based on real world facts over answers based on future aspirations or opinions.

What is a Scrum Master, How to Become a Certified ScrumMaster?

What is a Scrum Master

Scrum Master is one of the three roles that make up the Scrum Team as described by the Scrum Framework. The Scrum Master role is specific to Scrum and is a critical aspect in achieving the ambitious goals of helping the team and the organization be adaptable to rapidly changing customer needs through continuous inspect and adapt. To be adaptable the organization must develop the capability to continuously seek feedback from the customers about their needs and adapt their approach to meet these needs gracefully. The Scrum Master acts as a catalyst to this capability development within the team and the organization. Scrum Master achieves this by educating, facilitating and coaching the development team, the Product Owner and the organization.

While the Product Owner focuses on improving the product ROI by defining what is right to build, the development team focuses on building the product right, the Scrum Master acts as a servant-leader and focuses on building a high performing team to maximize the value created by the Scrum Team.

Master service

As per the Scrum Guide, the Scrum Master collaborates with the Scrum Product Owner and serves by:

  • Finding techniques for effective Product Backlog management;
  • Helping the Scrum Team understand the need for clear and concise Product Backlog items;
  • Understanding product planning in an empirical environment;
  • Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value;
  • Understanding and practicing agility; and,
  • Facilitating Scrum events as requested or needed.
Master service

The Scrum Master serves the Development Team in several ways, including:

  • Coaching the Development Team in self-organization and cross-functionality;
  • Helping the Development Team to create high-value products;
  • Removing impediments to the Development Team’s progress;
  • Facilitating Scrum events as requested or needed; and,
  • Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood.
Master service

The Scrum Master according the Scrum Guide, is also responsible to serve the organization in below ways. However, most Scrum Masters fall short on serving the organization.

  • Leading and coaching the organization in its Scrum adoption;
  • Planning Scrum implementations within the organization;
  • Helping employees and stakeholders understand and enact Scrum and empirical product development;
  • Causing change that increases the productivity of the Scrum Team; and,
  • Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization.

How to become a Certified ScrumMaster

The Scrum Alliance is one of the most reputed and popular certification body. The Certified ScrumMaster certification from Scrum Alliance is the most credible certification as Scrum Alliance carefully through a rigorous process wets out the Certified Scrum Trainers. This is how you can get a ScrumMaster certification:

  • Attend the 2-day Certified ScrumMaster (CSM) training facilitated by a Certified Scrum Trainer (CST).
  • Read the Scrum Guide and review the CSM participant workbook/reading content provided.
  • After successful two days workshop, the CST recommends your name to Scrum Alliance.
  • Scrum Alliance emails you a link to take the online CSM test.
  • Take the CSM test and get 24 (out of 34 multiple choice questions) correct answers to pass the test.
  • Upon passing the CSM test, download your Certified ScrumMaster certification from your Scrum Alliance member account dashboard. And here you are a Certified ScrumMaster 🙂

Living without TechDebt

Living without TechDebt

I grew up in an educated middle class family and was taught to #Save rather accrue #Debt. I don’t remember my family applying for a loan to buy an expensive house hold appliance or to go for a luxury vacation abroad. I guess most parents teach their kids to manage their spending and live within means.

I saw my parents live debt free. That encouraged me to think what was really important to buy.

It forced me make sound choices.

The need to live without debt taught me to say No.

No to unwanted stuff. No to things that were not urgent. No to things that were appealing on the surface but didn’t fit in to the bigger scheme of my world.

If you’ve read Robert Kiyosaki, you may be familiar of his advise of using Other People’s Money (OPM) and one of the traditional way is to get a loan. Many got sucked in to the trend. Now they can buy everything they may need and get it on loan.

I would like to call is a systemic dysfunction.

Systemic dysfunction is created not by one person or one institution. It also doesn’t develop just because of one or few instances.

Systemic dysfunction may manifest in the system in various forms and we start to see symptoms.

Sure we all remember the 2007 financial crash and it’s ripple effect on most of the economies of the world.

I observe similar and growing trend in the world of software product development.

Everywhere there is pressure to deliver more. More than the available time at hand. More than the people (at front) can practically deliver.

In the pursuit of Growth, the Sales teams is assigned sales quota that’s beyond challenging.

Marketing and Product Development usually find themselves dragged in the game to deliver more.

The product delivery teams and IT teams are usually at the receiving end of this rat race.

To secure their job, they end up saying Yes, more often than is realistic.

The Product Team creates a pipeline of requests to add more features. More new features in the product.

The product developers end up delivering new features.

There is less time to think of quality and developing these features right.

The code is just good enough to work. There is mountain of unfinished and poor code that the products are build on.

The developers are accruing more Technical Debt.

It’s a systemic dysfunction.

Not created by one developer or one team. Not created during the implementing of one feature or one product.

TechDebt is in every code poorly developed and is being accrued with each new request that needs to be delivered in rush.

What if your product owners and teams collectively agreed and pledged to live #Techdebt free!!

How will living #TechDebt free look like in your organization?

Hiring an Agile Coach

Hiring an Agile Coach

If you’re a leader of product development and/or delivery, you would’ve found self hunting for an Agile Coach at some point of time. Hiring an Agile Coach to help your product development teams becomes a natural step in mid to large size organizations, after you’ve trained your people and they’ve been breaking their head for sometime – trying to solve the How to Become Agile puzzle on their own.

I can share a list of 20 things to look for when hiring an Agile Coach, however, I’ll be generous and I’ll only share with you my top two.

Why only two?, you ask. Well, Agile Coaches can come from a wide variety of backgrounds and can have strengths in wide ranging aspects. So there isn’t a single checklist on which you can measure each of the Agile Coach candidate.

Here are my top two areas that I look for when hiring an Agile Coach,

First point to look for in an Agile Coach (when looking for a process coach** – the most common one) is if they’ve helped build high performing teams as a Scrum Master (when following Scrum) – replace Scrum Master with a XP / Kanban /…. practitioner based on the framework you follow. This aspect works and is very common-sense type, however it’s also most frequently ignored, I’ll tell you why, how and in which cases – later.

Coming back to the point. If someone has worked in the trenches before getting into coaching they can very well foresee many systemic / deep rooted challenges within the team and the organizations while looking at the symptoms. Let’s be practical – in a product based organization, there isn’t much time allowed for the development team to do a root-cause analysis of each impediment or issue they come across. Here you can benefit from having an Agile Coach who has past experience working as Scrum Master and can help the team pick, which are high impact issues worth spending time on and resolving. Just to be clear – I’m not saying that your teams should always do what the Agile Coach says or completely transfer this responsibility to her, as sometimes she would be wrong as well – due to having little context of your situation and challenges than your teams. Your experienced Agile Coach would also be able to share real life stories from his past experiences when they see your teams struggling at the Sprint planning, or splitting PBIs or not getting much value from retrospectives, or struggling to order the product backlog, etc.

Without having real experience as a Scrum Master, your agile coach could possibly be coaching the organization in to a completely incorrect direction. If she doesn’t have real experience of facing a wide array of challenges such as helping teams transition from command-and-control to self-organization, from silos to collaborative work, from top-down to shared ownership, from single function expert groups to cross-functional teams, of shielding the team from traditional mindsets and people in power, of battling with internal politics and resistance, of removing impediments, of influencing without having authority, of serving the team and keeping the team ahead of their own interest, etc…. the coach would only play based on what they’ve read and heard from others – significantly limiting team’s potential to produce great results.

Once in a while, I came across Product Owners who took interest in mastering Scrum and were really interested in helping the teams get better at implementing Scrum. They cared for the team performance. I guess such Product Owners can also make effective Agile Coaches.

Second aspect to look for in an Agile Coach (assuming the team is developing software products and using Scrum) is if they’ve ever worked on a Scrum Team where the PO and the dev team were in one building and collaborating on daily basis. Without having experienced this is like talking about Switzerland without having visited it. While reviewing candidates who worked particularly in service based (vendor) organizations lacked this knowledge. They were only experienced working with the vendor team at offshore, but didn’t have real experience working with a Scrum Team. Their experience and knowledge is limited to 1/3rd of the actual Scrum Master responsibility as listed in the Scrum Guide. These candidates significantly lacked in skills to influence any significant change with respect to how the Product Owner (usually from the client organization) worked as well as how the organization (client organization) transformed.

These candidates almost always oblivious to the actual organizational level challenges due to which the transformation initiatives were getting failed or stalled. What they knew was, my project ended and I was moved by my employer to another project. This person simply is a facilitator of the Scrum meetings (when implementing Scrum), not much more than that – in most cases.

Both of these points usually filter out all types of less than deserving Agile Coach candidates.

Now, what else I would look for in the Agile Coach candidate?

  • Experience working with leadership team,
  • Experience with organization design,
  • Experience Facilitating-leading change initiatives, (not the top-down change initiatives)
  • Knowledge of more than couple of Agile frameworks / techniques, etc…..

that list is long and your list should be specific to your situation.

What is your experience with hiring Agile Coaches for your product development teams?

Subscribe To Our Newsletter

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

Awesome. You've successfully subscribed.