The Scrum approach to agile software development marks a dramatic departure from waterfall management. Scrum and other agile methods were inspired by its shortcomings. Scrum emphasizes collaboration, functioning software, team self management, and the flexibility to adapt to emerging business realities.

10th
NOV

Scrum Acceptance Criteria

Posted by admin under Scrum Basics

In Scrum, some Product Owners would never deem a team’s work truly done without consulting the story’s acceptance criteria. Acceptance criteria are the requirements that have to be met for a story to be assessed as complete.

So what happens when only some—most, even—of a story’s acceptance criteria is met? Should the item be declared partially complete? No, what’s not done is not done. (Many ScrumMasters won’t allow teams to present work that hasn’t been completed.)

Why does Scrum only accept work that is 100 percent complete? First of all, an implicit acceptance criterion of any story is that it must be completed during the sprint it was negotiated. Work is confined to the sprint, so a team tries to complete the work in that sprint as well. Second, it’s common for teams to discover the final one percent of work to be more challenging than they expected. Third, when a Product Owner declares something done that isn’t, it results in velocity inflation, rendering the team’s velocity an unreliable metric for forecasting. Furthermore, when something is declared done without great rigor, a team has to play catch up, which often leads to a team falling behind and accruing substantial technical debt along the way.

A weak definition of done only serves to undermine a Product Owner’s ability to forecast accurately and risks building technical debt.

Be Sociable, Share!
Comments Feed

Reader's Comments

  1. Gregory Magazu |

    Can you make a recommendation for a great book on Acceptance Criteria and how to write good acceptance criteria.

  2. Scrum Acceptance Criteria: How to Demo - Chris Steele on Agile |

    […] 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 […]

  3. Acceptance testing at synyx – Part 5 | synyx - Blog |

    […] is completed. A good approach to define when you are really done with a story is to define some acceptance criteria for it. Then you check if the application meets these criteria to determine if the story you are […]

  4. Sergey |

    Could you put here were exactly in the process / in which moment the A/C should be adding into the story and by whom?

  5. MJ |

    Sergey,

    The Product Owner and Team should agree on the acceptance criteria during Backlog Refinement and Sprint Planning. The Product Owner should also be available during the Sprint to provide clarification, but shouldn’t move the agreed finish line.

    –mj

  6. Peter |

    On our project we drove out high level user stories (became Epics) with the business, in particular we ensured that even at that level we have acceptance criteria.
    Many of these Ac then devolved into new, smaller user stories with refined AC
    From the development team point of view, the AC were the business requirements which they had to deliver. In the Waterfall world, the BA would have preced each of these with a ‘The System Shall….’). Note that some AC are in fact Business Rules.
    So our traceability is User Story => AC => Requirements => Design etc