In the Scrum Guide a very straightforward definition of a Sprint can be found:
The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created.
It is quite obvious what “useable” and “potentially releasable” means. But what exactly means “Done” increment. If we ask 10 people when a website (simple example) is done, we probably will have 10 different answers. But scrum relies on transparency and to avoid the ambiguity the Definition of Done has been introduced.
In a simple words, the Definition of Done, commonly known as DoD, is a check list which is used to verify if the increment or any other Product Backlog Item meets all requirements (functional and non-functional).
In my opinion, there can be more the one Definition of Done. Of course there must be a Definition of Done for the increment. However the different types of the Product Backlog Items could also have another Definition of Done. For example the Scrum Team can introduce a separate DoD for a User Story and separate DoD for a Bug. There can even be a separate DoD for a User Story related to restricted parts of the system (accessible for registered user only) and to open one (functionality which does not require authorization). But all additionally created DoDs must be complied with DoD for increment.
Here are some examples of what can be found in a Definition of Done:
- All Acceptance Criteria have been fulfilled.
Each Product Backlog Item has (or at least should have) defined Acceptance Criteria. Product Owner or appointed person (e.g.: QA Engineer) should verify if work done meets those criteria. This verification should be done as soon as the Development Team finishes work on that item – there is no need to wait untill the end of the Sprint. - Pull Request is accepted by at least one developer.
It is a good practice to review a code before it will be merged back into main branch. It allows to detect some errors in a very early stage. This is much more successful if it is done by person not involved in the original development. Code review is also a good tool to share some ideas within a team – one line of code, even not completed tells more than hundred words. - 70% of code is covered by Unit Test.
The discussion if the created Unit Tests are required and sufficient or not should be done in Code Review (or even better it should be discussed during Sprint Planning session). However Code Coverage is an easy to measure metric allowing to check if the goal set by the Scrum Team has been accomplished. - Selected test cases covered by automated test.
If the Scrum Team is doing automated tests one of the DoD requirements may say that all (very unlikely) or selected test cases (e.g. happy path) should be automated. - Website is working properly in defined browser stack.
In a perfect world, all website should be available in all browsers. Unfortunately, the number of available operating systems and number of different browsers makes it impossible to check them all. But when we consider only the most popular configuration used by the users then the verification become feasible.
Note: For clarification, I’m not in a favor of requirements which says “Website should look exactly the same in each browser“. Why? For me it’s sufficient if a user is able to perform the task for which the website has been created and it looks similar in each browser (and similar to the design). But that’s only my opinion and a few other people. - Website generate response in less than 2s.
Today’s end-users are demanding and lot of them are not willing to use an application which is too slow. According to Google “Nearly half of all visitors will leave a mobile site if the pages don’t load within 3 seconds.”. Based on that information in my opinion 2s is a good start.
It is very important to know Definition of Done as some requirements may have direct impact on how much time is needed to complete a task.
The Definition of Done is created by the whole Scrum Team and all team members should be aware of it. The Development Team needs to know what are the expectation of the Product Owner and what they need to do to meet his/her expectation. On the other hand, the Product Owner needs to know what to expect from the Development Team. He/she needs to know and be able to inform stakeholders. In my opinion Definition of Done is a contact (Yes, I know “customer collaboration over contract negotiation”) between Development Team and Product Owner (and business he/she represents).
Each Scrum Team, as a self-organized team, should create its own Definition of Done which they will follow and with which they feel comfortable. Nobody should interfere with agreed Definition of Done. There some exceptions of this rule:
- Restriction required by the organization
If the Scrum Team is a part of bigger organization (let’s say a software house) or is doing a work for some organization it may be enforce to use some predefined Definition of Done. It may be due to some internal rules of given organization or to contractual limitations. Usually in such case the Scrum Team is able to extend or modify the provided Definition of Done but it needs to keep the required base. For example: organization require 70% of code coverage but the Scrum Team might decides it’s to low and change it into 90%. - More than one Scrum Team are working on a same product
If the Scrum Team is working with some other Scrum Teams on the same product the Definition of Done should be shared between those teams.
Conditional DoD
Should the Scrum Team, or what is more important, the Product Owner accept functionality (the final increment ) which does not meet the Definition of Done? In some cases it is best for the product to do less then to do too much. Let’s imagine following situation:
Our Scrum Team is working on a website. With Product Owner we have agreed that one of the DoD requirement is “Website generate response in less than 2s“. In the Product Backlog we have following item: “As an Admin I’m able to generate a report presenting number of images created in selected date range”. We know that this report will be used only by the Admin and it will be used rarely. In contrast to others functionality in the system this one is not critical from the business perspective. In addition we have estimated a cost (time needed to do this functionality) for 7 days if the report will be generated in less than 2s, and 1 day if it will be generated in less then 1min.
In such case a conditional DoD (item on DoD list) is very useful. We can define that in some cases requirement must be meet and in some it can be ignored. For instance: “Website must be generate response in less than 2s for each action performed by the end user”. We can also add more variations of this DoD item:
- Website must be generate response in less than 2s for each action performed by the end user.
- Website must be generate response in less than 10s for each action performed by the system administrator.
- Website should be generate response in about 1 min for each report requested by the system administrator.
In my opinion, we can go even further and we can assign a MoSCoW priorities into each items of DoD. In fact there is one plugin for DoD in JIRA allowing to do that.
The final decision how to approach and how to define the Definition of Done depends on the project, the Scrum Team and the organizations which are involved in the project.