A product owner's guide to acceptance criteria
'I want to create a practical guide for product owners to facilitate them in writing acceptance criteria for user stories so that their output is of value to the scrum team'
You'll find pages after pages describing what an acceptance criteria is and how to write a good one, what it should include or not, however this post takes a practical approach for Product Owners to follow.
You'll find post after post describing how product owners ought to use Gherkin script to develop/write an acceptance criteria, which in my opinion is not a practical approach, there are a few things wrong with that approach, a few come to mind right now:
a) not many product owners know Gherkin script and it's unreasonable to expect them to adopt it when the team itself is better placed to translate their acceptance criteria into Gherkin. Doing so has its merits, the team has to analyse the acceptance criteria and develop Gherkin based test scripts from it, furthermore the product owner's velocity for producing acceptance criteria is hugely improved as he/she is defining the fitness for purpose in a natural language.
b) calling out a product owner to write acceptance criteria in Gherkin or in a scripted fashion is prescriptive and goes against an agile approach, which is based on practicality and common sense. The Scrum master and team's role is to facilitate the process, don't assume your product owner can script!
Now that my preferred approach is set, lets dive into it:
For the newbies; acceptance criteria defines the intent of a user story, and is used to confirm if the user story is fit for purpose; the user story does what was intended, if so then the user story is complete. If you’re new to user stories please go here first.
Acceptance criteria must be developed by the product owner, it can be facilitated by the Scrum team but it's responsibility must rest with the product owner.
The Scrum team's expectations of the product owner to develop acceptance criteria must be realistic.
Things an acceptance criteria must cover (where relevant); usability, exceptions, desired output if the US is data driven, error handling, UX requirements, validations, any security and performance requirements as well as the function it's seeking to validate.
Furthermore where applicable insist that the PO adds a wireframe or screen grab of the desired outcome for the user story. For those of you interested in a working example, there is one detailed out at the end of this post.
For those wondering when an AC needs to be in place.... It's part of your *DoR (Definition of Ready) for the user story itself, your user story is not ready for technical decomposition or estimation without an acceptance criteria.
For product owners looking for guidance to write acceptance criteria, a starter for 10:
Focus on the what and not the how - the team is not looking for a ‘solution’ from you as the product owner, just the ‘what’ is it that you are asking of the user story.
Keep the end user (and user acceptance testing) firmly in focus, it's their point of view and value you are representing.
Develop acceptance criteria as a set of statements, each clearly stating a pass/fail outcome.
Specify both functional and non-functional requirements.
What are your security and performance requirements, need it be real time data display? Is the data sensitive?
Start with a sketch of what you are asking for, remember a picture paints a thousand words!
There is no such thing as partial acceptance: either the acceptance criteria is met or it is not.
What is your user story? Think about what your want is? Can it be visually displayed? Is it related to display of data? Sketch out the different data entities (columns) you want to see, do you need to sort the display/view of data? Think it through in detail.
Is it a form to capture data? What data entities do you want captured? In what format? Think about what you don't want in those fields (restricting input types), how would you validate the entries, what are the validation business rules?
This is a starting point for you and not a comprehensive list of do’s and don’ts, be pragmatic, and discuss the acceptance criteria with the Scrum team and your end user representatives; ‘conversation’ is a critical component of a user story and one that helps product owners bottom out the details of a user story’s acceptance criteria.
Your acceptance criteria must be acceptable to the Scrum team, if not then your acceptance criteria itself is not fit for purpose .
A tale from the trench
Our product owner’s requirement early on in the discovery stage was: 'I want a login page to authenticate users on the site.'
So our user story would have been a simple one: 'As a user I want to sign in to the site from a login page so that users can be authenticated.'
Then we began the deep dive conversation with our product owner; so what’s your acceptance criteria for the requirement?
and what we got was:
From on any page be able to access the login page via a sign in link.
On the site when I click the 'sign-in’ link, I am re-directed to the login page where I can enter my email and password for authentication
Upon successful login, I am re-directed to the homepage.
On the homepage my first name is displayed in the upper right hand corner along with the date and time of my last login.
If I enter an incorrect username and or password I should see an appropriate error message indicating my credentials are incorrect.
I should be able to retry authenticating myself three times before I am locked out of my account and must reset my password to unlock my account
My password needs to follow the company password policy for secure passwords
I must also see a link which allows me to re-set my password.
I must also see a link which allows me to register is i am a new user.
Can you spot the increased/emergent scope creep in the acceptance criteria as detailed by the product owner above?
Having seen the scope balloon we asked our product owner to sketch a wireframe for the login page, we were convinced there will be more that will emerge from a wireframe.
The wireframe
sketched out by our product owner:
Can you spot further scope that has emerged from the wireframe? How often has the above played out for you and your team?
We discussed the need for the additional user stories to capture the emergent scope as well as the necessity of keeping the acceptance criteria for the original user story narrow to the user story itself. The conversation helped us identify additional user stories we needed to capture.
Having been through the exercise/discussions our product owner revised the acceptance criteria and the package looked like:
The User Story:
'As a user I want to sign in to the site from a login page so that users can be authenticated.'
Its Acceptance Criteria:
On the sign-in page I can enter my email address and password and submit it for authentication.
My password needs to follow the company password policy for secure passwords
Upon successful login, I am re-directed to the homepage.
If I enter an incorrect username and or password I should see an appropriate error message indicating my credentials are incorrect.
I should be able to retry authenticating myself three times before I am locked out of my account and must reset my password to unlock my account.
I must also see a link which allows me to re-set my password.
I must also see a link which allows me to register is I am a new user.
I must see a CAPTCHA to protects the site against bots
The above user story and its acceptance criteria is independent, negotiable, valuable, estimable, small and testable within a single sprint, it is a user story and not an Epic that our product owner’s wireframe represented.
"Acceptance Criteria should not go beyond the scope of the user story, if so then additional user stories need to be captured that define the feature 'wants’."
Well thought out acceptance criteria help us better understand the original scope, the emergent scope and create a contract with the product owner on the user story's completeness and acceptability.
* Thank you B for pointing out the typo.
Lastly, If you got value from what I have shared please consider giving back by contributing towards Peace Through Prosperity, you can follow, broadcast or donate.
Peace Through Prosperity (PTP) improves the local/domestic environment for peace by nurturing prosperity in conflict affected geographies.
We work to alleviate poverty, prevent radicalisation through empowering micro-entrepreneurs with knowledge, skills, ability and increasing their access to income and opportunities.
We support small businesses, owned/managed by vulnerable and marginalised individuals/groups in society.
Peace Through Prosperity (PTP) is innovating social transformation design and delivery by using Agile principles and practices to create and deliver low cost, immediate and lasting impact social development programs in ‘at risk’ communities.
