What constitutes Scrum Acceptance Criteria? When going through basic Scrum training, teams often learn about the Definition of Done, an overarching set of criteria that universally applies to each story in the sprint, and allows the team to know what must be done in order for the story to be complete. different teams’ Definitions of Done can vary widely, but due to their need to be applicable to a number of stories, these are rarely specific enough to give good information that helps prepare the team for the demo for the Product Owner – enter here the “How to Demo” field. The two are related, certainly, but not the same: a Definition of Done helps to ensure that the end result of a sprint is a potentially-shippable product, and is often concerned with overall quality (code coverage, regression tests, etc.), among other things – the “How to Demo” or Acceptance Criteria represents a more granular and applicable definition of the work to be completed during the sprint on that user story.
What really constitutes a set of Acceptance Criteria is, as many things in Scrum, relatively flexible. In some cases, the Product Owner might have a fully-developed workflow in his/her mind, and that could be captured as “How to Demo.” Other times it might simply be represented by a high-level bullet-point script, or for extremely-difficult-to-demo stories, a review of unit tests or back-end reports (NOTE: as always, ensure that each story results in a full, thin, vertical slice of functionality, and not only UI or back-end work). Acceptance Criteria or “How to Demo” information is, while perhaps not part of the standard, becoming more popular, as several TFS templates and other Scrum management software have “How to Demo” information of some kind or another.
You may have noticed I used the term Acceptance Criteria as interchangeable with “How to Demo” – fans of XP will note that while the official Scrum guide makes no direct reference to demo abilities, XP requires Acceptance Criteria and Acceptance Testing. This is one of many ways that a great agile team can make use of elements of both Scrum and XP to improve their quality and efficiency. Just like a team wouldn’t demo a story that isn’t finished, or which doesn’t meet a definition of done, the team won’t demo one that doesn’t meet its Acceptance Criteria. Demo criteria can be especially important on stories that are particularly difficult to demo due to long workflows or which have a lot of interesting “back-end” processing.
Why else should teams use “How to Demo?” Primarily, it aligns the team to the Product Owner and helps to set good expectations. The Product Owner can know before he/she comes to the demo exactly what will be shown, and the team knows what is important to the Product Owner. It also allows for the team to have a better discussion about the work involved for a given story during the planning meeting, especially regarding the maturity of certain features or technical components (Can a database be pre-populated? Can a response server be mocked? Is a login page required, or can we assume a user?) Having this information ultimately helps the team understand the tasks that they need to complete in order to satisfy the customer and complete the story.
Give it a try in your team. It may well help to remove the frustration of an unsuccessful demo of “done” stories, or a Product Owner who isn’t satisfied. The additional transparency it introduces will allow for the team to better estimate the amount of work they can complete in a sprint, and to direct their testing efforts to the right things as well. Have other ideas on how to accomplish this, or have a story about the use of “How to Demo” in your teams? Leave a note in the comments below.