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. 

The primary method of communication used by Product Owners to convey requirements to the scrum team are User Stories, which in my opinion, are the single most important component in SCRUM.  They express desired end-user functionality, clarify and facilitate the execution of necessary steps to accomplish early and continuous delivery of value and attain customer satisfaction.  User stories are how the Product Owner (voice of the customer)  expresses himself to the SCRUM team during the kick-off meeting adding them to the Product Backlog. The Product Owner is responsible for the creation and management of the user stories.

User stories when originally defined are goal, value or user oriented and simply stated can encompass large generalities, these ‘epics’ (which can be part of larger ‘themes’) are then decomposed into smaller stories and finally ‘Tasks’ that are completed throughout the life of the project.  I will spend more time on the decomposition of user stories along with the estimation and completion of tasks in future blogs. 

There is some variety in the formats used to define user stories but they all follow the general template that answers: Who, What and Why as  shown in the following template:   As a _____ I want ____ so that ____,   i.e. As a Mortgage Broker, I want to be able to reach decision makers on a mobile device, so that I can provide them with the most updated information.

Keep in mind that as requirements change (due to economic conditions, competitive conditions, etc) and new User Stories can be added to the Product Backlog by the Product Owner.

In a co-located center, User stories are generally written out by hand and posted on wall-boards for everyone on the team to see, make decisions on -and while off-the-shelf software products allow similar functionality, in my opinion, the communal room approach is the best method for team communication during Daily Stand-Up, Sprint/Scrum or Backlog refinement sessions.

If the user story is prioritized, decomposed and time estimated, only those tasks meeting the team ‘velocity value’ are moved into the ‘work-in-progress’ column of the Product Backlog and into the Sprint Backlog for discussion at the next Sprint Planning Meeting.