In our last blog post on Arbor, we talked about the details and guidelines of writing useful, effective user stories – but writing the actual story is only half of the process. In addition to effectively writing the actual user story, it’s also critical to define the acceptance criteria for that story. Without this step, there’s no clear finish line for the story and no way to turn it into an actionable, reliable organization tool for the project. For an in-depth look at this, check out our video on the subject – but this article will give you a solid primer on the what and why behind acceptance criteria.
Defining the Acceptance Criteria
Acceptance criteria detail when a user story is considered “done.” They state, in clear, unambiguous terms, when you can consider the story finished, check it off your development to-do list, and move on to the next story. Acceptance criteria will vary in stringency and complexity from story to story, and many stories will have multiple criterions to meet before the story is considered “done.” For example, if a story says that a user should be able to log in through Facebook or through a LinkedIn account, that story will have two acceptance criterions: “I can log in through Facebook” and “I can log in through LinkedIn.”
In Arbor, adding acceptance criteria to your story is simple. If you click on any individual user story, you’ll see a text box below the story with the heading “Acceptance Criteria.” To add a criterion to the story, just type in the criterion and hit enter. You’ll now see it listed below the story. But as with all elements of user stories, the key isn’t just writing it – it’s writing it so that it’s an effective and useful guideline.
Writing Effective Acceptance Criteria
What you want from your acceptance criteria will change with each project, but we’d recommend three key principles as you write them:
- User-Centric: Acceptance criteria should always be written from the perspective of the user. This means that the criteria should be based on when the user or customer would consider the story complete: it states what exactly needs to happen for the user to derive a benefit from the function, not what you or your team think would complete the story. It’s not about whether the button exists in the software, it’s about whether pressing the button actually accomplishes what the user wants to accomplish.
- Comprehensive: Each user story can and probably should have multiple acceptance criteria, and some of those criteria may be about qualitative assessments instead of simple functional capabilities. If your user wants to call a car to their location, one acceptance criterion is that the care gets there. But in addition, you’ll probably want to include criteria stating the car arrives within a reasonable period of time, that it’s clean and sanitary, and that the user is greeted cordially by the driver.
- What, Not How: Similar to the stories themselves, acceptance criteria should always describe what the user gets and not how they get it. To that end, your acceptance criteria shouldn’t say that a modular window pops up with a graphical list of items in the user’s cart, they should say that the user can view all the items in their cart before checkout.
Start Writing Stories With Arbor
Hopefully these guidelines give you some help in using Arbor effectively, and if you haven’t tried it out yet, we’d highly recommend signing up for our Beta program. Keep a look out for more updates on Arbor, as we’re constantly improving it and adding features, and also keep your eyes open for the full launch of the product. Until then, get some practice on writing acceptance criteria!