A critical component to any software development process is ensuring clarity around the expectations of a requested feature. As part of our on going series on How We Use Trello we will discuss how defining acceptance criteria will increase flow and reduce frustrations for all stakeholders.
The most vital part of any card is that it have well understood acceptance criteria. These criteria are defined by the product owner and are required to be satisfied in order to accept the card. This should be defined before the developer begins work and not change once the developer starts (or least be only an occasional exception to this rule rather than a frequent occurrence).
If acceptance criteria cannot be stated in clear, concise and concrete terms, then the story isn’t ready for development. Chances are great if development proceeds without this definition and shared understanding, you will end up with a lot of blockers once the product owner begins reviewing the work for acceptance. Resolving these blockers will cause cycles to be wasted and budget overruns will likely occur.
The exercise of defining acceptance criteria is also useful in scoping cards/stories properly. Too much variance and/or volume in acceptance criteria can be clear indicator that it should be broken up into multiple, smaller cards.
There are a lot of things one can do to improve the development process, but demanding and improving upon acceptance criteria definition is the single best way to make things better for all stakeholders.
Often times the acceptance criteria are implied and obvious. For example, a card with the the title Add basic admin for the project's models is pretty clear, especially in light of conversations with the product owner where it is learned that there isn't a need for any non-standard or custom work in the admin.
There is also another category of cards that are not feature stories but tasks, like Get project setup on Gondor. The acceptance criteria are obvious–is it deployed on Gondor?–and there is no need to spell it out explicitly.
Being explicit with acceptance criteria is useful for any non-trivial feature. For example, As a staff user, I need the ability to invite members to the site, appears pretty self-explanatory but we can do better by creating an Acceptance Criteria checklist on the card with the following items:
While this might border on specifying implementation details, it is really focused on what the product owner expects in terms of UX for how the feature works. Sometimes product owners will be able to work out this criteria on their own, but often it's useful for this to be a collaborative experience between the developer and the product owner.