Well it’s been a little while in between posts. I had all the best intentions of keeping this updated weekly/fortnightly, and then like all best intentions something little like life and work got in the way. Well I am now dedicated to keeping this updated.
I think for this post I’ll talk about Acceptance Criteria on story cards. This was a hot topic at the last brown bag I went to at work. When the discussions were taking place people from different teams all had different input. We tried to elicit what is good acceptance criteria, who comes up with acceptance criteria and what it is used for. Some teams said the BA writes their acceptance criteria and testing are not involved and some teams said their acceptance criteria is very details, almost like their test cases.
I have found the following works in the projects I have been on –
Who comes up with Acceptance Criteria?
You need all of the development team including SME (business representative) involved in creating the acceptance criteria. This is because you need everyone to understand what is the criteria that defines the story card is finished. So the BA, Dev (Lead), SME and Tester should all be involved in creating this (if you have a large team you could have a representative from each). That way everyone is on the same page to when the card is actually ‘Done’. This is done in story card elaboration session.
What are Acceptance Criteria used for?
Acceptance Criteria is used to derive the key actions that pass that story card enabling the sign off. It is also a good conversation enabler and focuses people to think about what the card is actually trying to achieve.
Having good acceptance criteria on the card lets the developer know what to develop and what has to be implemented to pass the card, and is also useful to create automated tests. It lets the tester know the minimum to test to pass with the tester undertaking their in-depth testing in conjunction including exploratory testing. Finally the SME has the criteria that they can pass the card on.
What is Acceptance Criteria?
I have seen structured ways to write acceptance criteria, but in my experiences something short and sharp that is understandable (in plain English) and doesn’t take long to come up with is the best i.e. ‘When Person 1 radio button is selected the address fields display’, ‘Address fields consist of 3 x text boxes at 60 characters long’.
Of course good acceptance criteria constitutes an understanding of what is ‘Done’ for the card by all the team. I would tend to not get too in-depth as this is the testing performed by the testers.
TIP 1 – If you have an absurd amount of Acceptance Criteria on your story card you may want to look at breaking the card up as it is probably too big
TIP 2 – The more mature the agile team the less detail the Acceptance Criteria has to be as conversation flows freely
TIP 3 – All people are involved so you get a technical perspective, testing perspective, end-user perspective and core functionality perspective
Well until next time….(which will be sooner)!!!
An Agile Journey 