Not only important, but when having a contract with a client, it's fundamental.
It's what defines that you have done your work and should be paid. It's what defines that your team, inside some organization, is freed from some project and might move to the next.
It's what defines what you'll work on: your goal is to get the project/product accepted. You won't expend resources and efforts in other things, and you know that missing one of those items will leave your checklist incomplete and will cause you more work/pain.
This. I have spent the last 10 years preaching this to clients and other developers alike and I spend a good amount of my time writing documentation that define software projects; and customers pay me to do so. I love doing it actually and the way I sell it to customers is this: "Changing the document is much cheaper than changing the software."
I think that there is a great deal of trust implied by the actionably ambiguous statements she uses for AC. In an environment where trust between 'client' and development team is not ideal, I find that empowering the business owner to be more prescriptive with AC to be helpful.
In those situations I encourage AC of the form:
The payment form must contain fields for email address and name.
The payment form just match the visual mockup.
When I post a request with data X the response must be returned as JSON
It helps the engineers know what they business owner will test to validate completion.
I completely agree and came to make a similar comment, if intentions were left that ambiguous for us we'd get eaten alive by contractors... I don't mean to but I laugh and think, wow this person has very limited scope of experience.
Indeed. I could help but think, "If the customer wants that button labeled 'Check out now' then the AC had better have that in it and not just 'a button'."
Possibly off-topic, but I couldn't help noticing that this post is from the blog of a Ruby consultancy. Has anyone else noticed a correlation between the Ruby users and this kind of emphasis on acceptance criteria and acceptance tests?
I learned how to think of development from this perspective and write Cucumber tests (in Ruby) from the same friend that got me into Ruby in the first place.
My experience concurs. I've worked in Ruby shops and many other types. I always assumed it was Rail's emphasis on testing and the popularity of Cucumber.
It's not an accident at all. DHH's strong emphasis on testing and baking it into Rails from the beginning was a serious departure from the rest of the non-enterprise web dev world at the time, and a major part of Rails evangelism.
10 comments
[ 2.8 ms ] story [ 35.0 ms ] threadIt's what defines that you have done your work and should be paid. It's what defines that your team, inside some organization, is freed from some project and might move to the next.
It's what defines what you'll work on: your goal is to get the project/product accepted. You won't expend resources and efforts in other things, and you know that missing one of those items will leave your checklist incomplete and will cause you more work/pain.
In those situations I encourage AC of the form:
The payment form must contain fields for email address and name.
The payment form just match the visual mockup.
When I post a request with data X the response must be returned as JSON
It helps the engineers know what they business owner will test to validate completion.
I learned how to think of development from this perspective and write Cucumber tests (in Ruby) from the same friend that got me into Ruby in the first place.
¯\_(ツ)_/¯