Topic: Executable Specifications

Facilitator: Warren Elliott

Discussion Notes

For the purpose of discussion, executable specifications were understood to mean automated acceptance tests.

There was general consensus that automated acceptance tests should be considered part of the definition of done.

Enablers for writing automated acceptance tests quickly:

• granular story acceptance criteria, or conditions of satisfaction (COS), should be stated unambiguously.
• for speed, granular unambiguous COS should be identified prior to when the story is in play by the development team  
• consider using rigorous rules-based language when capturing COS (i.e., the consistent use of rule words such as 'must', 'not', 'no', 'only if'). See RuleSpeak Sentence Templates (Ron Ross).
• Who is responsible for writing granular unambiguous COS? PO? Team? Collaboration?  
• It might prove extremely productive for the PO/BA to specify COS in executable form directly (in lieu of bulleted list) using Cucumber, FitNesse or other framework adopted by the team. Should we expect this from the PO/BA? Why not?

SOX compliance story

One participant reported a situation where review and approval by SOX auditors was becoming an impediment to velocity primarily because SOX auditing was out of sync with the sprint/release cadence, leading to wait times. The group thought that automated acceptance tests (i.e., executable specification) might serve as a perfect antidote to this problem. If the auditing rules could be captured with automated acceptance tests, and if the SOX officers could be satisfied that the tests satisfied the audit, then SOX compliance could be assured with every build. In other words, SOX audit-first driven development instead of SOX audit-last driven development. Radical! :-).