There has been a lot of talk in the agile community about acceptance criteria. How having defined acceptance criteria beforehand makes development a lot easier. And it does. I’m a big fan of acceptance criteria. But just because someone write an acceptance criteria on the back of a card, doesn’t mean that what they’ve written is the correct criteria.
That might sound like a dumb thing to say. After all, if someone writes a wrong acceptance criteria, then what can we do about it? It’s their fault, they’re just going to get the wrong software, and they have no reason to complain… Right?
The new requirement specification
Remember the old days? Customer gives you a requirement spec, you implement the spec. Customer gets the software, and then requests changes. “But, thats not in the spec” you say.
Fast forward a decade, and what do we have
|What do we build?||Look at the requirements||Look at the acceptance criteria|
|How do we test||Conformance to requirements||Conformance to acceptance criteria|
|When are we done?||Requirements met||Acceptance criteria pass|
|The hitch||Requirement were flawed||Acceptance criteria were flawed|
I love acceptance criteria
I earlier said that I love acceptance criteria, and now I’ve just gone and bashed it, comparing it with that waterfall document. Whats going on?
Well I love acceptance criteria at the story level. Over there, acceptance criteria do a wonderful job. It lets us know when a story is done and when we can move on to the next story.
The problem comes when you roll it up and use acceptance criteria to steep the ship. Just because we are meeting acceptance criteria doesn’t mean that we are building something useful. We build software, not to meet acceptance criteria, but to solve some business or customer goal. And lets face it, goals are nebulous beings, which most of the time cannot be translated into acceptance criteria. Look at these examples
- I’m building a search engine. A key goal is to deliver more relevant hits than Google. What are “relevant hits”?
- I’m making a game. A key goal is that the game should be fun. What is “fun”?
- I’m writing an iPhone app. A goal is that it should be easy to use. What exactly is “easy to use”?
None of these goals can be translated into acceptance criteria. The only way to get there is to do something, make changes, and repeat.
Build with acceptance criteria, steer with goals
Now, you might think this is obvious. After all, being agile is all about responding to feedback. So it is rather surprising that many agile teams have their sprints and acceptance criteria and definition of done, but have no techniques to validate the application against goals and change direction. In essence, they are playing the “requirements specification is God” game all over again.
If you are a product owner, then your job is NOT to simply to accept or reject stories, but to keep validating the product being built against goals and steer the ship.
No related posts.