I like User Stories to have Acceptance Criteria (AC). I have many reasons for this. It just makes sense! I do not feel AC encroach on the team’s creativity to satisfy the requirements in the best way they see fit because not all teams are of a level of ability to do this. In time, and when their Agile experience is more mature then perhaps, and this is to be absolutely encouraged. Alas, in my experience, it is most often not the case, and teams need more clear guidance until their confident levels increase to the point they can make certain decisions alone.
In addition, If the PO attends Sprint Planning, as they should, negotiation of AC fro a story can take place here if the team have any issues, but at least there is a point for discussion to begin with if AC is present. It helps clear a load of stuff up and ultimately, ensure the whole team get what they need to do. Excellent. Read on for more reasons why I think AC is amazing:
- It allows black and white testing. When the story is in test, the acceptance criteria is met or not. Test can then easily raise defects on AC’s that they deem not met. they can go over to a developer and say “, Hey, I don’t think you quite met AC.2 here” and they can then
- It can help set the development team to used Test Driven Development (TDD) because test do some tests based purely on the AC. they can then populate an automated test suite for regression testing. Quality!
- In the Sprint Review (or before if they get chance), the PO can refuse to accept a user story as ‘Done’ based on a specific AC number that was not met, or can accept it based on the promise that the not met AC is addressed in a new story in another sprint (the AC not met will need to go into the backlog as a story or as part of another story)
- AC ensure the scope of a story is not expanded or ‘gold- plated’, which will consume sprint time unnecessarily (see my blog about Sprint Tetris). Developers like to gold plate things, and rightly so! It’s great they want things to be awesome! But sometimes they need a bit of help focusing the awesomeness.
- AC allow the PO to explain the requirements very clearly at sprint planning. When the whole team are on the same page, there is less likelihood that the team will produce something different to what is needed.
- When writing stories, adding AC helps the PO judge when a story is getting too big and needs splitting. As a general rule of thumb, I recommend no more than up to about 5 or 6 AC per story.
- Having AC prevents a load of other AC-type rubbish being entered into digital trackers under each story. One User Story has one set of AC. Not AC and Definition of Ready and Definition of Done and anything else someone thought of one day). By the way, the Definition of Done is a separate document that applies to all stories as a whole, not on a story by story basis).
So there you go, why I think AC is awesome. I hope you do too!