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 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 grooming 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 set conditions of the Product Owner. ipadian crack
————————————————————————————————————————
About Frank:
A credentialed IT Security Professional, Frank is a Project Manager consultant in New York City with extensive experience with Agile and Waterfall projects. He has organized and managed various global projects for the Financial Services, Pharmaceutical and Multi-Media industries providing him with valuable insight that is shared with colleagues and students alike. With over 20 years of industry experience, he has led a number of cross-functional and Agile project teams allowing him opportunities for partnering, team building and facilitating leadership that creates long-lasting relationships and enhances project success.
