• Nnenna

Acceptance Criteria: A BA's Guide

In the previous post, I explained the importance of User Stories to the Development/Scrum team. This article explains the importance of Acceptance Criteria to the Development team, especially the QA Testers.


In Management, delegation is one of the best ways of getting work done through others. This means that when building a technology solution as a Business Analyst or Product Owner, you need to do this successfully through others (unless you're a BA with Dev super-powers). Therefore, when working on a software business solution, you need to delegate the tasks needed to meet the Customer + Business needs by:

  1. Communicating the task clearly: Remember the article about User Stories being SMART, this is why.

  2. Communicating a context for the task: Back to the article on User Stories, this is why the "so that" part of the User Story is important.

  3. Determining standards for the task: ok, this might be hard to do using a User Story (I assure you, it is!), but that is why Acceptance Criteria exist.


================================================================

A little story about my Christmas dress:

I asked a dressmaker to make me something pretty for a Christmas Day party. I told her, "As a Nigerian party lover, I want an outfit that would make me stand out, so that I can make all the women at the party stare at my dress". I communicated SMART-ly, and after 2 weeks, I received my dress, which the Quality Assurance Officer promised had met my request.


One thing was for sure though, I couldn't sue because the outfit was certainly going to make me stand out. Why?


It seems I may have forgotten to inform the dressmaker that the tone of my black skin didn't sit well with lemon and orange. I also forgot to tell her that it was going to be an outdoor event, so a short gown was suicidal in the winter. What's worse, I may have forgotten to communicate my measurements, so the dressmaker assumed that the voice she heard over the phone, was that of a size 6-lady.

================================================================


How to Write Acceptance Criteria:

There are two methods of writing Acceptance Criteria:

  1. Rule-based: simple English. Literally, simple English that describes your desires. It is flexible.

  2. Gherkins: also known as BDD style (Behavioural Driven Development). Follows the structure: Given <>, When <>, Then <> (Gherkins can be used to create user stories as well).

I am sure you can guess correctly that my laziness would prefer the least brain-power consuming method-- Rule-based-- It is simple, clean, flexible and straight to the point.


Example:

Below is a User Story and a corresponding Acceptance Criteria (a Gherkins and a Rule-based) example:


As an Admin Staff, I want a platform to allow me to add new courses & dates, so that other users can view these new courses and dates.


Gherkins:

Given that the admin staff is logged in,

When the admin staff clicks on “Add New Course” button

Then the admin staff can paste or type in information concerning the new course

And the information to be collected will include: Title, Course Code, Course Description, Course Deadline, Pass Mark and Tutor Name.

And ensure that the fields "Course Code" and "Pass Mark" must be numbers only.

Then provide a button called "Save" to allow the user to save this newly added course.


Rule-based:

Provide a button called "Add New Course"

On click, load a new page called Add New Course page.

On the New Course page, provide a cancel and back button

Provide Text fields to allow the user type in information about the new course

The information to be collected will include: Title, Course Code, Course Description, Course Deadline, Pass Mark and Tutor Name.

Ensure that the fields "Course Code" and "Pass Mark" must be numbers only.

Provide a button called "Save" to allow the user to save this newly added course.


So:

I hope you can note the difference between the User Story and the Acceptance Criteria, whether Gherkins or Rule-based. The User Story explains enough to power creativity but does not set restrictions or constraints for the developers. Acceptance Criteria are also very important for the QA Testers because it guides them on how to mark what the Developers have done. Asking a QA to test without an Acceptance Criteria, is like closing your eyes and searching for something that is "shiny and pointy" (to be fair, you are likely to find it when you step on it!).


Therefore, with a clearly stated Acceptance Criteria, if the Developers missed a specification (say the final "Save" button), the QAs will catch that and boastfully/vindictively point this out to the Developers like, "Mate! I can't accept this screen because it didn't meet the criteria!"


Did you notice that there is a difference between my Gherkins and the Rule-based examples. That difference exists due to the inflexibility of Gherkins, and the second reason I prefer rule-based criteria.


In Summary:

Eliciting Acceptance Criteria out of your stakeholders (Subject-Matter Experts, Tech Leads or Users) is simply asking them, "So tell me, what does success look like?"


I used the Christmas story to illustrate the extreme importance of clear communication by setting out clear constraints to the Development/Scrum team. Do not over-estimate the mindreading capabilities of your Dev team. Similarly, I would advise that you do not underestimate their creativity as well. One time in Uni, I asked for a functionality to allow users to get the attention of other users (it was a gaming app) and I got sent a Megaphone--- granted they were joking, but just be clear.


Finally, as a BA/PO, you are accountable for the failure of that software solution (not even the Product Manager, as the PM is your client, who explained their dream product to you). It is your job to ensure that the creator + tester fully understand expectations. You are only exempt from the blame if the failure of the solution has nothing to do with your communication and the Dev/Scrum Team's understanding (Yes, if the Dev/Scrum team doesn't understand, it is your fault). So, I encourage you to practice your User Story and Acceptance Criteria writing (and practice telling the Devs to repeat what you said, haha!)


Let me know which form of Acceptance Criteria you would prefer to work with. Meanwhile, the ability to determine someone's size through their voice is a form of sorcery that I would like to dabble into. So, if you know someone who is good at that, please link me up with them. As usual, share your comments, suggestions and criticism.


#businessanalysis #fairygodmother #acceptancecriteria #userstory #productmanagement #communicationskills

332 views

Recent Posts

See All