Over a million developers have joined DZone.

All About Acceptance Criteria

DZone's Guide to

All About Acceptance Criteria

Code can tend to ramble when it should be succinct. When code is focused on passing some acceptance criteria, it's more straightforward and to-the-point.

· Agile Zone ·
Free Resource

Whatever new awaits you, begin it here. In an entirely reimagined Jira. 

Acceptance criteria are simple tests to tell us when we're finished implementing a feature.

Knowing when we're done building a feature is extremely important to developers because we're not always sure how robust a feature should be.

We don't like it when our code breaks in the field, so we want our code to be robust — which often leads us to overbuild in one area, taking the time we need to give other areas the attention they deserve. Knowing when we're done with one feature helps us move on to the next with confidence.

Acceptance criteria should be seen from the perspective of how the user evaluates a feature. It can be jotted down as a conditional statement on the back of a story card, or it can be automated with an acceptance testing tool like FIT, FitNess, SpecFlow, Cucumber, etc. These tools help us create acceptance tests in a form that the computer can execute while still being easy for a non-developer to read.

But there's another major benefit to coding to acceptance criteria. It keeps code focused on providing something useful to our users and puts acceptance tests at the right level of abstraction.

Creating the right tests for code is paramount. If tests are too fine-grain, then we're likely writing implementation-dependent tests. If they're too broad, then we're likely to miss edge cases and other exceptional conditions.

Good code depends on building it at the right level of abstraction, and the right level of abstraction is often defined in the acceptance criteria itself. When we write our acceptance test around the acceptance criteria of a story and our acceptance test passes, we know our story is finished.

Just like literature, code can tend to ramble when it should be succinct. When code is focused on passing some acceptance criteria, then it's more straightforward and to-the-point. We spend far less effort building cruft and put far more effort into code that provides value to our users. We also end up with a more assertive system that's more straightforward to test and extend.

Another important aspect of coding to acceptance criteria is that it helps us write code that produces an observable result, which means it's generally more testable and modular. Acceptance criteria speak to the very core of what makes a feature valuable to the user. Keeping acceptance criteria in mind as we're building a feature helps keep us focused on producing code that provides value.

"How will we know we're finished?" is the question we should always ask before we begin building a feature. It's starting with the end in sight. Defining this up front ensures that everyone starts on the same page with what's being built, and stays there until it is built.

New roadmaps, more flexible boards, and dozens of new integrations. And that's just the beginning.  

agile ,design patterns ,acceptance criteria

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}