Episode two: Acceptance Criteria and You

Episode Two: Acceptance Criteria and You

So, my note for this episode has the phrase ‘The best thing ever’, which says a lot about me, I guess?

So, lets get to it, the humble Acceptance Criteria.
As I mentioned in the last episode, I write (or help to write) Acceptance Criteria as part of the sprint planning process. If you need to remind yourself you can pause here and go revise, I can wait.

When creating Stories for work, first a user story is defined. User stories, or business cases are what the product owner wants from a piece of functionality and why.

So, for context, requirements capture happens at the start of the project, there are broken down and defined in user stories, which are further defined in acceptance criteria.

Acceptance criteria define the boundaries of the user story, and take into account how the functionality affects

You see how the story is broken down exactly, into a checklist of sorts for exactly what happens, when, and for whom.

The lead dev (in our case) then breaks those down into Acceptance Criteria. Acceptance Criteria provide boundaries and specifics for each User Story, so everyone knows exactly what this User Story encompasses and what the work entails.

Then, the lead dev and QA have to agree on these Acceptance Criteria. This means QA can flex their natural awkwardness to make sure all angles have been considered.

When both the lead dev and QA agree, the Acceptance Criteria goes to the client for approval. This means most of the awkward questions about how and why and ‘what about x?’ happen here, before any work happens. It means we can make better suggestions as we have a clear idea on what the client wants, when its much easier to fix.

After this approval process has been completed, work starts. Changes made after this point have to go through the approval process again.

This procedure means QA have a test case made against which work will be tested. If work meets the Acceptance Criteria, in theory, it’s ready to go (obviously judgement it used here). The tests can also be used for automatic regression testing.

It also provides a much higher quality of work. Devs have more insight and can offer suggestions to how to meet the client’s needs before work starts.

It encourages better buy-in from the client. They have to engage more in order to get the work going, which means they have to think about their needs as well. I have clients that write their own AC now, it’s great.

Incidentally this also makes onboarding new staff easier – all the stories are already defined pretty narrowly, the process is defined so explaining it is relatively simple.

This method may seem cumbersome, but it doesn’t take up as much time as you’d think, and in the end, you get a collaborative project (both dev team and client), with every team member engaging to provide the best work possible.

It’s hard work, but its worth it.

Follow the show on Twitter, or follow me on Twitter.

Drop the show an email.

Check out the Soundcloud page, or subscribe to the show on iTunes or whichever podcast programme you use. If there’s a podcast programme that doesn’t have the show available, please drop me a line and I’ll get on submitting it there!

Please rate and review the show on iTunes if you enjoyed it!

Gem