• If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • Stop wasting time looking for files and revisions. Connect your Gmail, DriveDropbox, and Slack accounts and in less than 2 minutes, Dokkio will automatically organize all your file attachments. Learn more and claim your free account.


Executable Specifications

Page history last edited by Generic Account 11 years, 8 months ago

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! :-).


Comments (0)

You don't have permission to comment on this page.