Definition Of Done - DoD

An Increment is Born

Wajid Hussain
Definition Of Done
• It is a formal description of the state of the Increment when it meets the quality measures required for the product. The
moment a Product Backlog item meets the Definition of Done, an Increment is born. The Definition of Done creates
transparency by providing everyone with a shared understanding of what work was completed as part of the Increment.
If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint
Review.

• The Definition of Done becomes the main factor that separates a User Story from being "In-progress" to "Done"

Wajid Hussain
Definition Of Done
Work cannot be considered part of an Increment unless it meets the Definition of Done.

• The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the
product.

• The moment a Product Backlog item meets the Definition of Done, an Increment is born.

• The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the
Increment. If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint
Review. Instead, it returns to the Product Backlog for future consideration.

• If the Definition of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum. If
it is not an organizational standard, the Scrum Team must appropriately create a Definition of Done for the product.

• The Developers are required to conform to the Definition of Done. If there are multiple Scrum Teams working together on a product,
they must mutually define and comply with the same Definition of Done.

Wajid Hussain
Definition Of Done
DPL Definition of Done

What Scrum Guide has to say about DoD:

 The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for
the product.
 If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint
Review.
 If the Definition of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a
minimum.

Wajid Hussain
Definition Of Done
DPL Definition of Done

Standard DoD for DPL:

1. Acceptance criteria met
2. Unit tests passed
3. Regression tests passed
4. Functional tests passed
5. Non-functional tests passed
6. No showstopper bugs
7. Code reviewed and checked-in
8. Accepted by PO
PO & SM - Please review this DoD with your team and get it incorporated in your projects within this week (e.g. each story
must only be marked done if all these items are checked). If a project requires more stringent rules, then please go ahead, and
add those requirements to the list. You must not, however, remove any item from the standard DoD.

Wajid Hussain
I have added few in the above list - Wajid
1. Acceptance criteria met
2. Unit test cases defined/attached
3. Unit test cases passed
4. Separate code branch has been created for a code change
5. Code reviewed as per the code guideline document
6. Regression tests passed
7. Functional tests passed
8. Non-functional tests passed
9. UI/UX reviewed by design team as per the design guideline document
10. No critical bugs
11. Required artifacts has been attached (Feature documentation, sprint/release note etc.)
12. Product Owner accepted the increment (User story, Feature etc.)
13. Increment has deployed on UAT
14. UAT signed off
15. Increment has deployed on Production
16. Code has merged into the production branch
I have added few in the above list - Wajid
We as a scrum team need to ensure to comply the following definition of done
(DoD) for each PBI

[ DEV ] Acceptance criteria met

[ DEV ] Unit tests passed (Pre-Req: Unit test created)
[ DEV ] Code reviewed and checked-in (Pre-Req: Code branch created, PR
generated)y

[ QA ] Acceptance criteria met

[ QA ] Regression tests passed (Pre-Req: Test cases created)
[ QA ] Functional tests passed (Pre-Req: Test cases created)
[ QA ] Non-functional tests passed (Pre-Req: Test cases created)
[ QA ] No showstopper bugs

[ PO ] Acceptance criteria met

[ PO ] No showstopper bugs
[ PO ] Accepted by PO (when PO doesn't mark it Done himself or herself)
Definition Of Done
Goal:
•Builds a common understanding within the Team about Quality and Completeness.
•Use as a checklist that User Stories (or PBIs) are checked against.
•Ensure the increment shipped at the end of the Sprint has high quality and that the quality is well
understood by all involved.
Dependencies:
•The nature of the product being developed.
•The technologies being used to develop it.
•The organization that is building the product.
•The present obstacles that impact the possibility.

Wajid Hussain
Definition Of Done
Things that commonly addressed in the Definition of Done are:
•Operating environments and at what level of integration are user stories expected to work?
•What level of documentation is required?
•What are the quality expectations?
•What are the security expectations?
•Scalability expectations?

Wajid Hussain
Definition Of Done
Things to consider:
•Review Acceptance Criteria
• Gather the Acceptance Criteria for work completed so far.
• Look for common criteria that can be abstracted out and applied across work in general.
• Use these common criteria as the basis for a Definition of Done.
•Assess Technical Debt
• Identify any rework that needs to be done.
• Identify the reasons why it wasn’t done properly the first time.
• Identify what measures can be put in place to stop similar rework from occurring.
• Add these measures to the Definition of Done (DoD).
•Continually update the DoD
• In each Sprint Review, identify which (if any) work was rejected or which caused rework to be done,
then
• In each Sprint Retrospective, challenge the DoD for relevance and completeness

Wajid Hussain
Definition Of Done
Advantages:
•Having a clear Definition of Done helps Scrum Teams work together more collaboratively, increases transparency, and
ultimately results in the development of consistently higher quality software.
•During the Sprint Planning meeting, the Scrum Team develops or reconfirms its DoD, which enables the Development
Team to know how much work to select for a given Sprint. Further, a common DoD helps to:
• Baseline progress on work items
• Enable transparency within the Scrum Team
• Expose work items that need attention
• Determine when an Increment is ready for release
•The Definition of Done is not changed during a Sprint, but should change periodically between Sprints to reflect
improvements the Development Team has made in its processes and capabilities to deliver software.
•The adoption of DoD happens during Sprint Retrospective
•When multiple Scrum Teams are working on a single project, it might not be possible to use the same definition of
“Done” for all teams, because they might be working on items of different natures.
•In such a case, each Scrum Team will define its own definition of “Done” and delivers its items based on that definition.
•However, the integration of those definitions of “Done” should be capable of creating a potentially releasable
Increment in the project level.

Wajid Hussain
Definition Of Done
Levels:

•The Definition of Done can vary based on various companies and their processes. However, the initial
definition of Done should be made very clear before starting the Sprint. This definition should be agreed
upon by all the team members, and the communication should be made very clear. Some teams prefer to
use three levels or types of Definition of Done. They are:

•Definition of Done for a feature (User Story or product backlog item): It refers to the criteria that have to
be fulfilled for the User Story to be declared.
•Definition of Done for a Sprint: This refers to the set of conditions and list of items that have to be
checked to display a Sprint as done or completed.
•Definition of Done for a release: This is the set of checklist items that have to be crossed to release the
update to the product.
•Usually, the Definition of Done includes designing, coding, integrating, testing, and documenting, which
has to be fulfilled to produce a complete set of functionalities. After the items in the definition are
completed, the product should deliver a validated value to the customer. The purpose of doing can be
more specific or general based on the tasks that have to be completed.
Wajid Hussain
Definition Of Done

Wajid Hussain
Definition Of Done
Story Definition of Done:
•All story should have automated acceptance test.
•The story should have working code supported by unit test that provide around
60 – 70 percent coverage.
•The story should have well defined acceptance criteria.
•The code must have been written as a pair or should be code reviewed.
•Code must be completely checked in to the source control system and the build
should pass with all the automated tests running.
•The product owner must accept the story.

Wajid Hussain
Definition Of Done
Sprint Definition of Done:
•Product owner should have defined a sprint goal.
•All stories completed for the spring must be accepted by the product owner.
•All the automated acceptance tests should be running for the stories in the
sprint.
•All code should have been pair programmed or must have gone through a code
review process.
•If there is a database involved, the database scripts must have been automated
and tested.

Wajid Hussain
Definition Of Done
Release Definition of Done:
•Product is deployed to the test box and makes it to staging.
•There are deployment documents for the release.
•Training manuals are available for users.
•All stories for the release are completed and accepted.
•The release does not have any level one bugs.

Wajid Hussain
Definition Of Done
Sample DoD Checklist
•All code has been written and all to-do items are complete.
•All code has been tested and passes quality standards.
•All code has been checked in and run against the current version in source control.
•All code is free of errors and functions in every operating system or browser.
•All code has gone through an architecture review.
•All code has gone through user testing and/or a usability assessment.
•The feature developed satisfies the requirements documented in the user story.
•The product owner has accepted the feature.
•The feature has been documented in any end-user documentation.
•The feature has been documented in any internal documentation.

Wajid Hussain
Definition Of Done
Sample DoD Checklist
•The code should be peer-reviewed
•Code is Checked-In
•Code is deployed to the test environment
•Regression testing should be passed by feature/code
•The code should give smoke testing
•Documentation of code
•Help documentation is updated
•The Stakeholders approve the feature.

Wajid Hussain
Definition Of Done
Sample Definition of Done
•Code produced (all ‘to do’ items in code completed)
•Code commented, checked in and run against current version in source control
•Peer reviewed (or produced with pair programming) and meeting development standards
•Builds without errors
•Unit tests written and passing
•Deployed to system test environment and passed system tests
•Passed UAT (User Acceptance Testing) and signed off as meeting requirements
•Any build / deployment / configuration changes are implemented / documented / communicated
•Relevant documentation / diagrams produced and / or updated
•Remaining hours for task set to zero and task closed

Wajid Hussain
Ready vs Done

Wajid Hussain
Definition Of Ready
What is the definition of ready?

The definition of ready spells out the criteria your user stories must meet before development can start, to ensure they
deliver value quickly.

In Agile, you refine user stories as they rise up your list of prioritized work ahead, adding more detail and building a
better understanding across the team.

Wajid Hussain
Definition Of Ready

Wajid Hussain
Definition Of Ready
Definition of Ready for a user story:
•Well-defined User story
•User story acceptance criteria defined
•User story sized by the delivery team
•Scrum team accepts user experience artifacts
•Performance criteria identified
•The Person who will accept the user story is identified
•A Team is able to ‘demo’ the user story.

What is definition of ready (DoR)?

A definition of ready (DoR) is used to determine whether work on a task is ready to be started. Before teams assign a
task or user story in a sprint, it must be sufficiently well described and understood by team members.
The development team should grasp enough of a proposed scope to plan it into a sprint, estimate completion time,
and allocate adequate resources to meet its goal.
A definition of ready serves as a checklist of criteria to help facilitate a team's decision to begin working on a new
task. Note that a definition of ready is different from a definition of done (DoD).

Wajid Hussain
Definition Of Ready
Example – Definition of Ready for a Sprint
Different teams will have different Dentition of Ready, and some require less. i.e., some teams just
describe the value to the user, prioritize, and write how to demo. Other estimates and
communication are in the sprint planning meeting and etc. Here is the sample items to be
considered for developing DORs for your team:
•The Sprint Backlog is prioritized
•The Spring Backlog contains all defects, User Stories and other work that the team is committing to
•No hidden work
•All team members have calculated their capacity for the Sprint
•Fulltime on project = X hours per day
•All User Stories meet Definition of Ready

Wajid Hussain
Definition Of Ready
Example – Definition of Ready for a User Story
This section shows a sample Definition of Ready for a user story, and a sample Definition of Ready for
a Sprint. You can adopt some of these as baselines or starting points:
•The value of Story to the user is clearly indicated.
•The acceptance criteria for Story have been clearly described.
•User Story dependencies identified
•User Story sized by Delivery Team
•Scrum Team accepts User Experience artifacts
•Performance criteria identified, where appropriate
•Person who will accept the User Story is identified
•The team knows how to demo the story.

Wajid Hussain
Definition Of Ready
Here’s a sample definition of ready:
•The business value is clearly communicated
•The team can demo the feature
•The story has a short summary
•The story can fit into one sprint
•There are no external dependencies

Wajid Hussain
Definition Of Ready
Sample Definition of Ready (DoR)
•User Story is clear
•User Story is testable
•User Story is feasible
•User Story defined
•User Story Acceptance Criteria defined
•User Story dependencies identified
•User Story sized by Development Team
•Scrum Team accepts User Experience artefacts
•Performance criteria identified, where appropriate
•Scalability criteria identified, where appropriate
•Security criteria identified, where appropriate
•Person who will accept the User Story is identified
•Team has a good idea what it will mean to Demo the User Story

Wajid Hussain
DEFINITION OF READY TEMPLATE
User Story Clarity: Yes/No
Is the user story clear, concise, and unambiguous?
Does it include a clear description of the desired functionality or outcome?
Does it follow the Who, What, Why format?
Acceptance Criteria:
Have the acceptance criteria been defined and documented?
Do the acceptance criteria cover all key aspects and functionalities of the user story?
Are the acceptance criteria measurable and testable?
Dependencies and Prerequisites:
Are all necessary dependencies identified and addressed?
Are any external services, APIs, or components required for development available and accessible?
Are there any specific prerequisites or conditions that must be met before work can begin?
Stakeholder Alignment:
Have the stakeholders provided input and agreed upon the user story and its requirements?
Is there a shared understanding of the expected outcome between the product owner, development team, and
stakeholders?
Design and Mockups:
Have design specifications, wireframes, or mockups been provided, if applicable?
Are the design elements aligned with the desired outcome and stakeholder expectations?
Do the design specifications address any specific UI/UX requirements?
Story Sizing and Effort Estimation:
Has the user story been appropriately sized and estimated in terms of effort?
Does the development team clearly understand the level of effort required?
DEFINITION OF READY TEMPLATE
I - INDEPENDENT Yes/No
Can it be worked on and completed without relying on other stories?
If there are dependencies, are they separated and refined?
Can the team complete this work without relying on other teams?
N - NEGOTIABLE
Was the story discussed and does the team fully understand what needs to be done?
Are the acceptance criteria defined?
Is there a high-level technical solution in place and the team can start working on the story?
V - VALUABLE
Does the user story provide value to the end-users or stakeholders?
Does it align with the project goals and objectives?
Does it follow the Who, What, Why format?
E - ESTIMATABLE
Can the development team estimate the effort and complexity of the user story?
Are the requirements and acceptance criteria clear enough to allow for accurate estimation?
S - SMALL
Is the user story small enough to be completed within a single iteration or sprint?
T - TESTABLE
Can the user story be tested to ensure that the desired outcome or functionality is achieved?
Are the acceptance criteria well-defined and specific enough to guide the testing process?
End of Session 1
25th August 2022

Wajid Hussain