Want to Delight Your Clients? Create The Acceptance Criteria With User Stories

When collaborating with clients who had their first glimpses of agile methodology, I always tend to look at their product backlog first. Why is that? Because most of the time, the quality of the backlog is equal to the quality of the team’s work. To be honest, the majority of the backlogs prepared by the beginning product owners don’t have this “high quality” feature. In most cases, the primary reason for that is lack of acceptance criteria in the user stories.

Inside this article you will learn:

• What are the acceptance criteria.
• What’s the big deal about them.
• Why implementing them can lead to greater success.
• How to prepare them.
• How can you define acceptance criteria?

In most simple words, buying criteria are the requirements set from the vantage point of the end user to determine when a story is considered “finished” and everything is working properly. That’s very helpful because it enables risk reduction and creates more transparent set of expectations between the client and the team that’s working on the project. Of course, the acceptance criteria are not set in stone and can change with the evolution of client’s needs and requirements (at least until the the team commences the work on the story).

All members of the team, including developers, QA and business analysts can assist the PO in preparing and reviewing the acceptance criteria.

The benefits of acceptance criteria:

• They make you think about how different features will look from the end user’s perspective.
• They enable the team to create viable test cases without any doubts about the business value that has to be provided.
• They minimize scope creep that will not contribute any more value to the story. Saying it another way – it will enable the team to define the right content for the project.

Preparing acceptance criteria:

Acceptance criteria include three parts: input, process, and outcome. How to think about the acceptance criteria? “After (input) X and (process) Y, I will arrive at (outcome) Z as a result.”

The “inputs” in acceptance criteria might be considered as something like “typing in the value” or “entering a command.” The “process” in acceptance criteria consists mainly of checking the actual computations. Most of the time, in each user story we want a specific thing to happen for every set of inputs given. Maybe this process is not observable every time, but it’s verifiable for each set of inputs and outputs. The “outcome” (results) in the acceptance criteria always needs to be distinguishable enough to be testable without any doubt.

When considering user stories, quite often people think just about the story description. Yet the story is not entirely complete until it’s embellished with acceptance criteria. Acceptance criteria also make it possible to measure up a user story. Once everyone knows the verification process of the story, they will know how to make it happen, so please try to combine acceptance criteria with every user story.