Scrum Methodology

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.