Acceptance Criteria - The True Definition of Done

Let's talk about Acceptance Criteria in User Stories and in Tasks.  Acceptance Criteria are the true Definition of Done for a work item and are the critical component when trying to estimate time.  

My experience has been that User Stories or Tasks are often poorly written which creates a misunderstanding of the scope and breadth of a work item.  Adding real Acceptance Criteria drastically changes those conversations for the better.

Video

Presentation

We capture different categories of information when we describe a unit of work. This unit of work is often encapsulated in a User Story or Task depending our working style, Kanban, Scrum, Lean, etc.  These Story components support different parts of the process.

Time Estimation

A lot of the Task Definition and specification work exist to support budgeting and time estimation.  The team uses the size estimate to figure out how much time and resources need to be applied. Management wants time estimates for budgeting purposes and as rollups to the overall project.  Note: Time estimates at the Story level are significantly more accurate than program level estimates because of the limited scope and less vague nature of the Story effort.

Related Work

Individual Tasks / Stories are limited in scope with boundaries where they push up against other stories. The team primarily cares about related work as a way of managing inter-story dependencies. Related stories or aggregators like Features and Epics exist primarily exist for coordination purposes and management functions.

Reporting functions

Binning values are things like: assigned team, subsystem, work category, or release date that exist solely for reporting functions.  A good percentage of task definition fields exist to support management reporting.  Time spent exists for expense management.  Time estimates have a dual nature. They exist for project estimation for management and team estimation as an indirect Level of Effort (LoE). 

Work Definition

Task Requirements Definitions (business requirements) and Acceptance Criteria describe the work that actually needs to be done.  Business Requirements can often be very complex.  It can be difficult to fully specify the work because some of the details won't be known until people dig into the tasks.  In theory, this shouldn't happen but building the Task Description and requirements is a complex task.

The Acceptance Criteria is the actual Definition of Done. It can include Non-Functional Requirements (NFRs) along with what needs to be demonstrated or implemented for sign off to occur. This is often a composite of business needs, technical deliverables, NFRs, and pieces from the Definition of Done (DoD). 

 

Acceptance Criteria are Necessary for Sizing Estimation.

Acceptance Criteria represent the story's definition of done.  They include Business and Non-Functional deliverables and describe what a tester or someone signing off should actually see. 

Size estimation is more accurate and less stresful when there is a full et of Acceptance Criteria available during the estimation process.  Acceptance Criteria during task sizing surfaces a lot of details that were otherwise ignored or assumed as part of the Story. 

Acceptance Criteria - Real Definition of Done

Acceptance Criteria represent everything that needs to be accomplished and delivered in order to complete this story. Creating Acceptance Criteria requires discipline. It can be frustrating in the beginning.   It forces people to a level of detail that is not always met by the normal Story definition.  .  They are not the same thing as requirements.  Acceptance Criteria are a place where you can surface pieces of the project level Definition of Done.

People seem to dislike creating Acceptance Criteria. Sometimes it is becasuse it feels like an extra field .  Other tiems theydon't like how muc

Alternative Titles for this Talk

This talk went through several alternative titles.