-
Module 1: Why PSM 1
-
Module 2: Scrum Guide Simplified
-
Module 3: Agile Foundation
-
Module 4: Advanced Scrum Theories
-
Evolving Agile Mastery
-
Scrum Excellence
-
Leadership (Bonus 1)
-
Metrics in Scrum (Bonus 2)
-
Video Coaching Sessions (Bonus 3)
-
Live PSM 1 Exam (Super Bonus 1)
-
Live Video Q&A (Super Bonus 2)
-
PSM 1 Sample Tests ( Super Bonus 3)
Definition of Done (DoD) and Acceptance Criteria
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 create a Definition of Done appropriately for the product.
The Developers are required to conform to the Definition of Done. If multiple Scrum Teams are working together on a product, they must mutually define and comply with the same Definition of Done.
Where do we need to have the DoD? Is it at the Product Level/Sprint Level/Story Level?
Because it is the product that gets released to the market, the DoD is always at the Product level.
Meanwhile, since we are working with Sprints, every Sprint must create a releasable Increment of Product and this means that the DoD needs to be met every Sprint to make the Product releasable. The user stories are part of your Sprint deliverables, so to make every story releasable (functional releases) as part of the Product, it must meet the DoD of the Product.If multiple Scrum teams are working on the same product, then there are chances of each Scrum team having their own DoD. However, the integrated work of all the Scrum Teams put together must meet the DoD of the Product, which means their combined/integrated work must be releasable.
Best Practice:
The Definition of Done should be written on the Team Working Agreement for transparency and clarification so everyone on the team understands its real meaning.
An example:
If a team is responsible to create an e-commerce website. Most of the user stories will go over the same path. The user story needs to go through a front-end, a back-end, some security approvals, end-to-end testing, and then documentation before it can be shippable.
The definition of done here can be as follows:
1. All acceptance criteria for the user story has met
2. Have passed through front end development
3. Have passed through back end development
4. Have passed through security approvals (no open ports, secured payments)
5. Have passed through end-to-end testing (no bugs or defects)
6. Documentation completed
Note: a Definition of Done can be clearer on a Kanban board. Where every column might be a phase of the definition of done’s requirements.
What is the impact if the Definition of Done (DoD) is not defined?
There is no transparency if a Product increment is releasable, impact on estimations or unrealistic estimates, inaccurate forecast on Sprint work, difficult for the Product Owner to understand the progress on the Product, inefficient inspection and adaptation at Sprint Review.
Rating
0
0
There are no comments for now.
Join this Course
to be the first to leave a comment.