User Stories: Are Acceptance Criteria Factorable?

Tighter acceptance criteria == lower cost, faster delivery, and higher quality. Do you agree?  Here is one way to think about this as a practice.This post comes out of some work I have been doing on a generalized rules framework.

Before someone asks why anyone would ever build a generalized rules framework rather than simply implementing a COTS rules engine – let me just say that we might end up doing that, but we are trying to define what our product needs.  We are still exploring the generalized metaphors of rules and how they relate to less generalized business objects in our problem space.  Building software to explore the relationships between metaphors is a good way to tell whether a significantly complex commercial or open source software framework will actually help solve real problems or whether it is just another hammer looking for a nail that you can’t use effectively.

But this post is about user story practice.  User story practice can be divided into three main categories.

1. Dividing and Sequencing.  Do I know how to break the work into small enough pieces that can be sequenced for incremental delivery?
2. Semantic Disambiguation.  Do I have consistent words (especially nouns and verbs, and actors) across my stories so that I can model software and assess impact?
3. Elaborating the Definition of Done. Do I have an agreed upon definition of done that is aligned with the nouns and verbs that the team can assess to determine whether they know how to deliver?

This post is about my attempt to simplify the definition of done.

What I realized this week is that acceptance criteria are essentially factorable.  There is a minimum set.  I was writing about rules.  Rules are Boolean expressions.  They are math.  Rules are factorable.  That is, there is a least complex way of expressing logic, and there are many, many more complex ways to express the same logic. Moreover, the less complexity, the less chances for conflict or error, or inconsistency.  By factoring our rules down to the simplest set, we are ensuring that they are the most consistent, and the easiest to test and correct.

Interestingly enough acceptance criteria, especially those that are written using the “GIVEN, WHEN, THEN” framework are also Boolean expressions. What this essentially told me is that I don’t necessarily need to write out all of the edge and corner cases as individual acceptance criteria, or have all of my negative test cases written as acceptance criteria.

Maybe this came naturally to everyone else.  Maybe I am really late to the game. But it is cool that I can factor my acceptance criteria down to the minimum set that is sufficient to express the intent of the story.  Think about it.

So why, oh why would I want to “waste time” factoring my acceptance criteria down to the smallest sufficient set?  Here are my three reasons:

1. Developers write tests on the basis of acceptance criteria.  The fewer criteria, the fewer tests they have to write.
2. Testers form test scripts on the basis of acceptance criteria.  The fewer criteria, the shorter scripts they have to write.
3. The smallest set has the least possible chance of inconsistency.  Inconsistency means defects.  Defects mean conversations and rework.

So by spending a little time up front, tightening up my acceptance criteria, I can save work downstream for my delivery team.  And I can increase the quality of the software product by having fewer defects in the story.

Tighter acceptance criteria == lower cost, faster delivery, and higher quality.  Factoring is a way of thinking that will get you there.