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

The Product Owner Puzzle

A dedicated and effective Product Owner is critical for a Scrum Team to deliver exceptionally successful products that delight customers, gains market share and yields high ROI for the organization.

Jenny is a director of product development at a global organization that is in the midst of a massive transformation. The market they operate in, is evolving rapidly, the customer needs they specialize in serving well are fast changing and the way they organize and run the enterprise must adapt to demands of the newer generation of knowledge workers.

Jenny is smart and thoughtful leader. She is responsible to serve millions of users every day via a portfolio of web and mobile applications. Her annual budget sits north of $20 millions and brings in close to a $1 billion in revenue.

To help their organization become adaptable, Jenny and her team started implementing Scrum framework a year ago.

I am Kamlesh, Agile/Lean coach and trainer. Jenny, her team members and I are meeting this morning at 9. Our discussion will focus on the opportunities for her team to get better at adapting to changing requirements and aligning a large number of team members, partners and vendors. Jenny responded to a brief questionnaire I sent her last week. In her response she mentioned, gaining better Net Promoter Score is one of her primary focus. Jenny and I have known each other for some time and I’m looking forward to meet her.

Me: Good Morning! How are you?

I’m well. Thank You. Jenny is energetic. She introduces her colleagues Alex, Srini, Deb and Priya.

We greet each other, and walk to a conference room. Freshly brewed coffee is waiting for us. Jenny and team has come ready for our conversation and I can guess, is eager to go to the next level in their Agile journey. Priya has nice visuals of their products on two flip chart sheets. She is posting these sheets next to the whiteboard while we sip the coffee and share couple of laughs.

Jenny kicks off the meeting with a brief 30,000 feet introduction of her portfolio. After her, Deb gets up to give us an overview of the product and their SCRUM implementation.

“It (the Product) comprises of multiple applications which are tightly coupled. We aim to reduce delays due to one team waiting for another team to deliver a service or functionality. One cross-functional team supports one application. All teams follow Scrum except one team. Jenny works with the marketing and Priya assists her. Priya also works with the BSAs to refine the requirements. Alex acts as a Program Manager, manages the budget, hiring, procurement and working with outside interfaces. Srini and I play the Scrum Master role.

So who is the Product Owner? I eagerly posed the question to Deb.


“Who is the Product Owner?”


Deb is looking at Srini with a question mark on her face. Srini turns toward Jenny.

There is a pause and a shift in the energy in the room.

What do you mean?” Jenny jumps right in. She opens up her shoulders and re-adjusts herself on the chair.

I continue to look at her without any reaction.

“We don’t have a “separate” Product Owner; Jenny indicates in quotes.

“No Product Owner?” I take a pause. “Please help me understand, who talks to the customers? who owns the Product Backlog?” I continue with curiosity. “and who prioritizes features?”

Priya pitches in, We all work on that. Priya’s response brought relief on everyone’s face. Srini adds, We have shared ownership of the Product Backlog. Anyone can add user stories, defects, technical debt to the Product Backlog. Team members collectively refine and volunteer to pull the items.

It’s great to know that you’ve a culture that encourages collaboration and shared ownership.

Does that mean you all play the role of a Product Owner?”, I ask firmly.

“We, Product Owners? not really” Srini replies.

Let me ask you couple questions to clarify this further,

“Who tracks the release? I ask.

I do. Jenny says it calmly and confidently. “Alex helps me.”

And who decides, what’s the most valuable thing the team should work on first?”

I decide that. Jenny replies with a firm voice.

Would you say, you are the Product Owner? I ask.

I, Product Owner?” Jenny thinks and carries on, “Priya helps me with the information and with making decisions. We both remain in tight sync our marketing group. They give us the priorities.

And who talks to the customers?

Marketing. Priya has a clear answer.

 

“From what I’m hearing, no dedicated Product Owner supports this product.”

Everyone nodes. I clear my throat and explain,

From my experience, I can say, it’s critical to have one dedicated Product Owner supporting one product. The Product Owner ensures that customers are served well and the organization gets a higher ROI from it’s investment. She collaborates with customers, stakeholders and the team members. She is responsible to identify and create high customer value and make budget allocation accordingly.”

Everyone is silent and curiously listening. After a brief pause, Jenny goes,

“I think,” she looks at everyone, “if we’ve got a dedicated Product Owner, we can resolve some of our pressing challenges immediately.”

I ask, “How will your customers feel?” Everyone nods and smiles!!

 

Hey, I invite you to explore within your team and organization.

    Who’s the Product Owner?

Want new articles as they get published? Subscribe to our Awesome Newsletter.

Subscribe To Our Newsletter

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

Awesome. You've successfully subscribed.