The Scrum methodology of agile software development marks a dramatic departure from waterfall management. In fact, Scrum and other agile processes were inspired by its shortcomings. The Scrum methodology emphasizes communication and collaboration, functioning software, and the flexibility to adapt to emerging business realities — all attributes that suffer in the rigidly ordered waterfall paradigm.


Scrum Acceptance Criteria

Posted by admin under Scrum Basics

In Scrum, a Product Owner would never deem a team’s work “done/done/done” until he or she had consulted the story’s acceptance criteria. Acceptance criteria are the requirements that have to be met for a story to be assessed as complete. Acceptance criteria are incredibly important in Scrum because they spell out what a Product Owner expects and what a team needs to accomplish. There are no hairs to split and no points to argue. If it’s in the acceptance criteria, then it needs to be in the release.

So what happens when only some—most, even—of a story’s acceptance criteria is met? Should the team be awarded a corresponding percentage of the story points? Well, no. Scrum frowns on partial credit for work that is only partially completed. All of the criteria must be fulfilled or else the work is incomplete. (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 assigned. Work is confined to the sprint, so a team must 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. It might sound like a Yogi Berra-ism, but if it’s not done, it’s not done. Third, when a Product Owner awards unearned credit, it results in velocity inflation, rendering the team’s velocity an unreliable metric for forecasting. Furthermore, when a team is awarded credit for a story that it will have to finish in the next sprint, it means the team’s workload is even greater than the sprint backlog suggests. When this happens, a team has to play catch up, which often leads to a team falling behind and accruing substantial technical debt along the way.

Clearly, it is in the interest of the team to only award credit when it is completely earned. Partial credit 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 |


    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.


  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

Leave a Reply

Scrum Training Courses