Importance Of "done" In Scrum And Why Acceptance Criteria Is So Important

By Author: Mrugesh panchal
Total Articles: 48
Comment this article

Agile scrum supports events and ceremonies (sprint planning meetings, daily scrum meetings or the daily stand up, release planning meetings, sprint review meetings, sprint retrospective meetings, etc.) and it uses certain metrics (burn down charts) to ensure scrum methodology is implemented in an effective and productive manner at all times. However, many times, even though scrum teams adhere to the basic principles of scrum methodology, they fail to deliver the project value. Scrum projects may also fail in totality, and might be terminated to reduce the overheads and financial costs incurred in remunerating the team members. One of the primary reasons why this happens is because the team fails to deliver the productivity in a consistent manner and present “shippable” product functionality to the stakeholders who actually own the project. The tasks developed by the team may not satisfy the acceptance criteria laid down by the product owner and the stakeholders. The functionality may fail to execute properly after deployment. The reasons could be many but the bottom line is the team ...
... fails to function as a single unit while generating the product value and the stakeholders decide to call off the project.

Why is “done” so important in scrum?
If you analyze things when they wrong with scrum, in most cases the primary issue is accepting the user stories as “done”. Scrum supports the development of product through iterations known as sprints, and after each sprint finishes, a sprint review meeting is conducted in which the product owner reviews the development carried out during the daily sprints and accepts the sprint backlog items as complete and shippable if they meet the acceptance criteria defined in the product backlog items during the creation of the product backlog. The definition of “done” is very important in scrum methodology, but what is even more important is developing shippable user stories in the first place so they can be accepted or rejected.

When user stories do not satisfy the acceptance criteria, or if the backlog items are not “shippable”, they are transferred back to the product backlog from where they came from, and are required to be picked up again for further development in the next sprint. When items are not “done”, several issues start emerging, which can increase the developmental costs and increase the overheads for the stakeholders.
• The user story has to be taken up for development again and this leads to wastage of time and resources
• The team members are generally on a regular monthly pay so if the lead time increases for the project, it can lead to increased overheads for the project owners
• The product release date is delayed
• The competitors have an increased chance of launching their products in the market and grabbing your share of the market profits
• The ROI starts decreasing with each unsuccessfully completed sprint and due to the lack of shippable items delivered at the end of the sprint

What is understood by a potentially “shippable” product?
In simple terms, a potentially shippable product can be understood as a product backlog item that has been successfully developed by the development team during the sprint iterations, which is bug free, tested, documented, and implementable or ready for use by the end users. In scrum, when items are successfully developed and they meet the acceptance levels, they are referred to as “shippable”.

The concept of being shippable is originally defined in the product backlog item, or the user story, when the product owner creates the product backlog at the time of project release or inception. The product owner understands about the features and functionality to be provided in the final product which is to be launched in the market. Based upon the inputs received from the stakeholders, the product owner prepares a master list of requirements which can be combined to constitute the final product. This list is known as a product backlog, and each requirement stated or defined therein is known as a product backlog item or a user story. When the user stories are defined in the backlog, certain rules and conditions are stated for each item in the list. These rules and conditions function as a benchmark. When the team takes up the user story for development during the daily sprint, the development should be carried out in a manner such that the benchmark is satisfied and all the conditions linked with the story are met successfully. During the sprint review meeting which is held immediately after the sprint finishes, the developed user stories are analyzed by the product owner who ascertains that the team has carried out the development keeping in mind the benchmark associated with the particular user story. The benchmark is actually the “acceptance criteria”, and when the criterion is met in the story, the particular story is considered as “shippable”.