Actually it should come as no surprise that clear acceptance criteria are a quintessential prerequisite for high quality software that meets both design requirements and customer demand. All too often however, acceptance criteria for software products are either non-existent or vague and ambiguous at best.
Who hasn’t come across ‘acceptance criteria’ such as “The app should have a modern UI.” or “The application should be easy to use.“? What do bromides like that amount to? Not much, unfortunately.
Elena Kulik of RubyGarage wrote about why it’s important to define clear and explicit acceptance criteria and I couldn’t agree more.
Yes, it’s obvious but still acceptance criteria and corresponding test cases are often neglected during software development. Trading in software quality for more output per unit of time (for instance to be able to keep a deadline) can be tempting but it’s treacherous.
Sure, in the short term this might allow you to create more stuff (though I doubt even that’s true in most cases) but not only will your software quality suffer severely in the long run, more importantly you’ll lose direction: You’ll haphazardly create something but that something quite likely will be of little value (or at least a lot less than had you defined clear acceptance criteria beforehand) to your target customer.
Frequently though, it isn’t even quality being traded in for time that’s at the core of the problem. Depending on the application and its complexity defining actually useful acceptance criteria can be quite challenging. As with any skill this can only be learned by doing it frequently. By trying, iterating and getting a little better each time.
In order to ultimately get there one obviously has to get started and make understandable and useful acceptance criteria a prime objective of one’s software development process.
One comment