Articles

Acceptance Criteria

The second half of the User Story is the Acceptance criteria.  Defined by the Product Owner (the voice of the customer) during User Story decomposition, acceptance criteria sets the expected functionality that each intended task is to provide. It details the requirements that must be met for each story to be completed and answers the question, “How will the development team know when they are done with a story”.

Acceptance criteria may be clearly detailed or vaguely composed

· The pull down menu color in the payment screen must be PB15:1 (Windsor Blue RS)

· Meet ISO9001 – 8.5.2 Requirements for Analysis and Improvement

· Have a systematic approach to fix nonconformity and stop it from recurring, including a procedure.

Acceptance criteria can be ambiguous

· Fishing ads do not make it to the reply form or info request page

· Cart-payment page does not hang upon CC submission
Done

Tasks are part of User Stories that are either completed or not.  Completed tasks are tracked on the Sprint Burn-down Chart where the Scrum team deducts completed work from the Sprint.

Partially completed tasks do not satisfy acceptance criteria and should be moved back to the product backlog for further clarification or prioritization and taken up on the next sprint.

Expect to test

In meeting the requirements of the acceptance criteria (a result of a well-defined user story) as part of the development of a potentially ship-able product, the development team may implement tools to test different stages of product development and build a working software that creates specific observable results. This is  an effective way to continuously verify that the acceptance criteria is met.

Dos and Don’ts

· Focus on meeting each item's acceptance criteria and maintain technical excellence

· Stay focused on building the minimum code required to satisfy the acceptance criteria for the current sprint.

· Do not gold plate

· Feature creeps (resulting from a poorly understood user story) takes time away from developing expected value.

· Assisting the PO in refining the product backlog can be a effective use of time should the development team have remaining sprint time,

· Sprints should not be extended if the development team needs more time to complete a given user story

· Don’t give partial credit for items that don’t meet acceptance criteria.

Potentially Ship-able product

As stated earlier, Acceptance Criteria sets the parameters that the development team needs to meet for the sprint items (tasks) to be completed within the velocity of a sprint.  Doing so builds customer value, delivers working software more frequently and gets the team closer to building a potentially ship-able product that works as intended and meets the conditions of the Product Owner.