We're Currently Updating Our Website & Adding Some Cool New Features. We'll be Back Shortly. Thank You For Your Patience. For Any Assistance Contact +91-960-640-0491  (India) Social Link

The Definition of Done: The 2023 Guide

Popular Post

TAGS

Non proident maiore second third four first six seven ten developer ret Agile Certification, Agile Training, BDD training, Scrum Certification, scrum for developer, Scrum Training, TDD training testing BDD training, BDD training in Bangalore, DevOPs training in Bangalore, Scrum, scrum for developer, Scrum for tester, scrum master, Scrum Training, Scrum Training in Bangalore, TDD training, tdd training in Bangalore Agile, Agile Training, Estimation, Scrum, scrum for developer, Scrum for tester, scrum master, Scrum Training Past Webinar Agile Product Development, Agile Scrum training, Traditional Project Management product backlog Spillover in Scrum sprint planning User story test scrum fg Agile Scrum training, Scrum Certification, scrum master, Scrum Master Training SAFe agile SAFe,Product owner LPM SAFe,PI planning agile-coaching agilemania testing,agilemaina,testing tools ,Build a customer-centric ,product using Scrum to maxi Agile Training CSD training CSM training CSP CSPO Training CST Scrum scrum for developer Scrum for tester scrum master Agile Metrics Agile Scrum training Scrum Master Role Scrum Master Interview Questions scrum master Agile Certification Professional Scrum Trainer professional scrum trainer professional scrum master scaling agile scaling agile scaling RTE SPC SPCT Empowering Teams,SAFe Stream Map Agile Retrospectives Mistakes Project Management PSM,CSM Digital Transformation Agile Testing, Agile Testing Training, ATDD,bdd, Scrum for tester, SpecFlow scrum master, scaling scrum, scaling agile scrum for developer, Large scale scrum software plan, scrum for developer, agile planning scrum for developer, scrum master, planning scrum coaching, agile assessment technical debts, Agile Metrics Agile Team ssm Scaled Agile Product Owner Scrum Training in Bangalore Product Manager Business Owner Resolving Conflict Conflict Resolution Techniques Product Backlog Refinement Sprint Retrospective Sprint Planning Scrum Master Interview Questions Scrum Interview Question Agile Interview Question agile coaching Creative Professional Agile Coaching Managers Safe Scrum Master Agile Governance Self-organizing Teams Agile Persona Mapping Scrum Certification CALMR Role Of Product Owner Agile Scrum Training APM Agile Product Product Management KPIs Business Agility SAFe 6.0 Definition of Done Digital Marketing SAFe Agilist Certification SAFe® Agile Certification Benefits of SAFe SAFe Agilist BDD training BDD training in Bangalore DevOPs training in Bangalore Scrum Training TDD training tdd training in Bangalore WSIF SEO DevOps Sprint JIRA PSM Agile Facilitation Feedback Loop Gold SPCT User Stories Acceptance Criteria TDD Agile Framework Technical Agility Velocity Agile Software Development SAFe vs Scrum SAFe Scrum Master vs just Scrum Master Scrum Vs. Kanban Agile Coach Enterprise Agile Coach Agile Testing Pair Programming Scrum Teams PI planning PERT CPM Delivery Pipeline Project Management Tools Agile Certification BDD training Scrum Certification Value Flow ICAgile Digital Transformation Large scale scrum Measuring Scrum Sucess Organizational Agility Agile Coaches Leadership Management
Agilemania Blog
  • Vishal Prasad
  • May 9th 2023

Scrum relies on transparency, inspection, and adaptation; transparency requires courage and trust. The team can only inspect work, progress, and quality when they are transparent. Without inspection, there is no adaptation.

These are the core principles of the Scrum Framework, and the Definition of Done is a commitment by the Scrum Team to make the Increment transparent.

So what is the Definition of "Done"?

It's a shared understanding of what it means for work to be complete. The Scrum Team agrees to deliver the "Done" Increment in each Sprint, and a Product Owner may choose to release it immediately.

So if transparency doesn't occur overnight, when is a definition of "Done" really "Done"? Let’s understand this further.

The answer is probably "never"

Not to worry, that's an answer to many things in Scrum, and for good reasons.

A Product Backlog, for instance, is never "Done." It's ever-evolving till the existence of a product. It changes as more information is acquired about the users and the product itself.

Impediments (in general) are never gone (Done); they keep coming and require facilitation. Inspection and adaptation are never "Done"; these are opportunities for continuous improvement at regular intervals.

Artifacts themselves may change over time even if they provide the same information, only in a better way. The Definition of "Done" is no stranger.

Ever Evolving?

Consider a situation where a development team does not have automation testing capabilities. The team will probably identify this gap during a Sprint Retrospective and plan to gain these capabilities over time to improve the Increment's quality.

Does that mean the Increments will not be "Done" in the meantime? Of course not! The first iteration of the Definition of "Done" may have a shared agreement between the Developers and the Product Owner to have rigorous exploratory testing for every integrated Sprint Backlog item to ensure acceptance.

As the capabilities are gained within the team, the Definition of "Done" can get revised during another Sprint Retrospective to have automation testing included along with a plan to recover the technical debt that might have been injected during its absence.

This makes the Definition of "Done" an evolving artifact and, as such, enables transparency over time.

Deriving a Definition of "Done"

One of the common ways of deriving a Definition of "Done" is to have an exercise during the first Sprint Planning where the Scrum Master may ask the team a simple (potential) question: As a Product Owner, we want a useful increment from this Sprint so that we can choose to release it immediately. Although this question is framed as a commonly used user story format, there is no compulsion to use it this way.

However, if you wish to use this, then a user story is obviously followed by acceptance tests (or criteria) that are derived in the presence of the whole Scrum Team and agreed upon as the basis of engineering & quality standards. I prefer to call it deriving and not creating because it's not a one-time activity. Once created, it becomes a part of the regular inspection and adaptation with inputs from the Scrum Team and is affected by external constraints.

Single Team's Definition of "Done"

Chances are bleak, but you may belong to one of those lucky Scrum Teams unaffected by any external constraints; then, you can perform this exercise yourself and define your own acceptance and quality standards.

For instance, during their first Sprint Planning meeting, a newly formed Scrum Team will have the Product Owner provide the vision of a new Product to build a state-of-the-art ETL tool. The team will go through the existing Product Backlog, derive a Sprint Goal, and select Product Backlog items that it can possibly complete in one Sprint. At this point, the Scrum Master may time-box a definition of the "Done" exercise and put forth the above-mentioned question. As the acceptance criteria, the Scrum Team may come up with the below list:

  • All code checked in
  • All unit tests passing
  • All acceptance tests passing
  • Previous increments integrated
  • Minimum test coverage 80%
  • No open defects/bugs
  • Performance tests passing
  • Release notes updated
  • Recovery plans updated, etc.

This Definition of "Done" gets fed into the remaining Sprint Planning meeting, where the Development Team decides how to build the functionality defined by the Sprint Goal into a "Done" product Increment during the Sprint.

Scaled Team's Definition of "Done"

When working with multiple Scrum Teams toward a single Product, the Definition of "Done" for each team will get influenced by the other teams. Since all the teams are working on a common product, a common set of standards will apply to all teams.

Exceptions may apply to a few teams, which are only acceptable if agreed upon by all the other Scrum Teams and the Product Owner. It's worth noting that if multiple teams kicked off their implementation simultaneously, the rule of thumb would be to have a common definition of the "Done" exercise during the first Sprint Planning.

Also, since these teams are working on the same product, their Sprint length will likely be the same. Even if it's not, these teams must find a common time (e.g., combined Sprint Retrospective) when the shared Definition of "Done" can be inspected. When new teams get added to this setup at a later point in time, a common definition of the "Done" exercise makes sense during the first Sprint Planning of the new team to share common guidelines, agree on exceptions, and derive exclusive "Done" criteria for the new team.

Organization's Definition of "Done":

The Scaled Scrum scenario may also apply to organizations where a common set of guidelines binds all products and teams of an organization. For every new product or team, it may be a mandate to have a definition of "Done" that apply these organization conventions and more if required. Although complicated, the derivation guidelines for Scaled Scrum must also apply when organizations mandate conventions & standards, which must be inspected regularly.

Absence of Definition of "Done"?

Yes, a definition of "Done" may never be "Done"; evolution is the only way to improve. If this becomes an excuse not to have a definition of "Done," then what happens? To list a few:

  • Lack of shared understanding regarding the acceptance of the Increment
  • Lack of quality standards for an Increment
  • Lack of transparency between business and technical acceptance
  • Increased risk of failure due to incomplete activities
  • Negative outlook about the product in the market
  • Loss of credibility Bankruptcy (a bleak possibility)

In short, there's no "Fun" without a definition of "Done."

Our vision is to become one of the trusted groups of passionate change agents to build ecosystems in enterprises to scale digital solutions.

Agilemania Blog

Vishal Prasad

With over 14 years of specializing as a Business Analyst, my teams have delivered digital solutions across multiple industry verticals & domains that have transformed businesses to serve their people & customers better. During this period, SLICE has been my lodestar for experimentation, allowing my teams to swiftly navigate through complex & challenging environments; a safe culture of learning to fail has allowed my teams to plan and take risks for faster value realization while achieving a shared purpose.

Sign up for Agilemania Newsletter

Stay updated with the latest Agile & Scrum trends.

Popular Post

TAGS

Non proident maiore second third four first six seven ten developer ret Agile Certification, Agile Training, BDD training, Scrum Certification, scrum for developer, Scrum Training, TDD training testing BDD training, BDD training in Bangalore, DevOPs training in Bangalore, Scrum, scrum for developer, Scrum for tester, scrum master, Scrum Training, Scrum Training in Bangalore, TDD training, tdd training in Bangalore Agile, Agile Training, Estimation, Scrum, scrum for developer, Scrum for tester, scrum master, Scrum Training Past Webinar Agile Product Development, Agile Scrum training, Traditional Project Management product backlog Spillover in Scrum sprint planning User story test scrum fg Agile Scrum training, Scrum Certification, scrum master, Scrum Master Training SAFe agile SAFe,Product owner LPM SAFe,PI planning agile-coaching agilemania testing,agilemaina,testing tools ,Build a customer-centric ,product using Scrum to maxi Agile Training CSD training CSM training CSP CSPO Training CST Scrum scrum for developer Scrum for tester scrum master Agile Metrics Agile Scrum training Scrum Master Role Scrum Master Interview Questions scrum master Agile Certification Professional Scrum Trainer professional scrum trainer professional scrum master scaling agile scaling agile scaling RTE SPC SPCT Empowering Teams,SAFe Stream Map Agile Retrospectives Mistakes Project Management PSM,CSM Digital Transformation Agile Testing, Agile Testing Training, ATDD,bdd, Scrum for tester, SpecFlow scrum master, scaling scrum, scaling agile scrum for developer, Large scale scrum software plan, scrum for developer, agile planning scrum for developer, scrum master, planning scrum coaching, agile assessment technical debts, Agile Metrics Agile Team ssm Scaled Agile Product Owner Scrum Training in Bangalore Product Manager Business Owner Resolving Conflict Conflict Resolution Techniques Product Backlog Refinement Sprint Retrospective Sprint Planning Scrum Master Interview Questions Scrum Interview Question Agile Interview Question agile coaching Creative Professional Agile Coaching Managers Safe Scrum Master Agile Governance Self-organizing Teams Agile Persona Mapping Scrum Certification CALMR Role Of Product Owner Agile Scrum Training APM Agile Product Product Management KPIs Business Agility SAFe 6.0 Definition of Done Digital Marketing SAFe Agilist Certification SAFe® Agile Certification Benefits of SAFe SAFe Agilist BDD training BDD training in Bangalore DevOPs training in Bangalore Scrum Training TDD training tdd training in Bangalore WSIF SEO DevOps Sprint JIRA PSM Agile Facilitation Feedback Loop Gold SPCT User Stories Acceptance Criteria TDD Agile Framework Technical Agility Velocity Agile Software Development SAFe vs Scrum SAFe Scrum Master vs just Scrum Master Scrum Vs. Kanban Agile Coach Enterprise Agile Coach Agile Testing Pair Programming Scrum Teams PI planning PERT CPM Delivery Pipeline Project Management Tools Agile Certification BDD training Scrum Certification Value Flow ICAgile Digital Transformation Large scale scrum Measuring Scrum Sucess Organizational Agility Agile Coaches Leadership Management
Agilemania Whatsapp