
Clear Acceptance Criteria and Why It’s Important - ievgen1989
https://rubygarage.org/blog/clear-acceptance-criteria-and-why-its-important
======
wisevehicle
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.

~~~
fbreduc
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.

------
woliveirajr
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.

~~~
thomk
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."

------
zachrose
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.

~~~
jdminhbg
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.

------
heisenbit
Acceptance criteria should be testable.

~~~
dghf
They should not just be testable, but should have tests. Under ATDD (which I
accept is not necessarily what she's describing here), a requirement without a
test is not a requirement.

If you've got a project with a lot of complex business rules, this makes a
massive difference to whether they're correctly interpreted and implemented.
You can argue with an English sentence, but it's a lot harder to argue with a
worked example (or a bunch of them).

