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

DONE Understanding of “Definition of DONE”

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
  • Sumeet Madan
  • Dec 12th 2019

The Professional Scrum Master (PSM-I) workshop has a module that talks about DoD and Technical Debt, and I have often come across students who are confused about this concept. This article is a small attempt to have more clarity on these topics. Let's take DoD first As stated in Scrum Guide, the Definition of DONE (DoD) is – 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. In short, DoD is a shared understanding within the Scrum Team on making your Product Increment releasable.

DONE = Releasable

Everything in this universe that is meant for delivery has DoD
  • What it takes for the Rocket to launch?
  • What does the service engineer take to call the customer to deliver the vehicle?
  • What it takes for the Doctor to say, "The Surgery is a Success"?
  • What does it take for the Development Team to put the Product into Production?
and so on…. When we talk about Product Development (considering the system/software/solution), the DoD consists of 2 main components:
  • The Requirements – Build the right Product, or its functionality
    • Business or Functional requirements
    • Non-Functional Requirements
  • Quality – Build the Product right
    • Maybe the defined quality standards at an organizational level
    • Best practices

Business or Functional requirements

The business requirements assumed to carry value in the Product as functionality may be written in the form of User Stories and has the acceptance criteria.Example:

Non-Functional Requirements

These are the quality characteristics or attributes of the Product that may not add direct business value but without which your Product can't move. These quality assurance attributes of the Product can also be considered under the quality component. Example:
  • Availability
  • Maintainability
  • Performance
  • Reliability
  • Scalability
  • Security
  • Usability
  • Compliance/Regulatory
  • Legal
NFRs usually take their place in acceptance criteria or the Product Backlog as Product Backlog Item (requirement)  but are the key for Product success and hence are part of the DoD too.

Quality and/or best practices

Quality is more aligned with the coding language or RAD/technical tools to build the Product. The developer owns the quality to ensure the Product is of the maximum quality. These quality standards can be subjective and data-driven. Example:
  • Defined coding standards (like identified in tools – FxCop etc..)
  • Test Driven Development
  • Unit Test Coverage
  • Maintainability Index
  • No Defects or no known defects
  • Technical Debt
  • Design principles
and so on… The Definition of Done for an increment is usually part of the organization's standards. If it is defined at the organization level, then all Scrum Teams must follow it at a minimum, but if not, the Scrum Team must create a Definition of Done appropriate for the Product. The Product Owner can influence the Definition of DONE, but the Scrum team has the final say on this. A few examples of DoDs (New to Mature and Stringent)

FAQs on DoD – Definition of DONE

Do we need everything as part of DoD? Well, it depends on the nature of the Product's business, but the Definition of DONE concludes the Increment as potentially releasable. Therefore, whatever it takes to make an Increment releasable must be included as criteria in the DoD. Do we need to have all these parameters from the first Sprint? Well, the Product evolves as we learn more about it, its usage, and the competition. With the evolving Product, it's a mandate to ensure the quality and the user experience. It may so happen that the Scrum Team(s) starts with a LEAN DoD, and then DoD evolves as the Product evolve, and more is learnt. Do we need to have DoD at the Product Level, Sprint Level, or Story Level? Well, the moment a Product Backlog item meets the Definition of Done, an Increment is born, and it's the Product or its features that get released to the market or end users; hence, the DoD is at the increments level of the Product. But as we are working with Sprints, every Sprint must create a releasable Increment of Product, and this means the DoD needs to be met every Sprint to make the Product Increment releasable. The user stories are part of your Sprint deliverables, so to make every story releasable (functional releases) as part of the Product, that must meet the DoD of the Product. If multiple Scrum Teams are working on the same Product, then this may so happen that each Scrum team have their own DoD, but the combined or the integrated work of all the Scrum Teams must meet the DoD of the Product, which means their combined/integrated work must be releasable. How DoD raises transparency within the Scrum Team? Well, DoD is a shared understanding within the Scrum team on what DONE Increment of Product means, increasing transparency in the Scrum Team.    But, if we consider the DoD as just a checklist for the Developers to complete their work, then this may be barely a checklist document for the sake of having it, and this type of DoD hardly evolves or is refined. This results in low confidence within the Scrum team to declare a Product as DONE/RELEASABLE, and this also makes the Increment of low quality and non-releasable with a pile-up of UNDONE work. What is the impact if DoD is not defined? Well, there is no transparency on if a Product increment is releasable, there is an impact on the estimations or leads to unrealistic estimates, inaccurate forecast on Sprint work, the difficulty for the Product Owner to understand the progress on the Product, inefficient inspection and adaptation at Sprint Review and finally, the DoD can impact Product's total cost of ownership. What is UNDONE in the context of DoD? Well, UNDONE work refers to anything that is not completed, as mentioned in the DoD, to create a releasable Increment. What is the difference between a shippable and a releasable Increment of the Product? Well, shippable refers to some undone work (mostly related to approvals) stopping the Product Increment from being released to the market. So Shippable is like Almost DONE, which can be referred to as the Definition of Almost Done (DoAD). It's like we are DONE with the work, but the work is pending approval from UAT or Compliance or Legal, or some Documentation is pending. So in this scenario, your Product is not releasable, but the team refers to that as shippable. This is also popularly known as DONE (Shippable) DONE (Releasable). So I mean to refer to your work as "DONE" or "DONE DONE", where the first is referred to as Shippable and the latter as Releasable. Many definitions of "Done" focus only on development activities, where such activities hold no guarantee of high quality.

Agilemania Blog

Sumeet Madan

A Professional Scrum trainer (PST) from Scrum.org, SAFe® Program Consultant (SPC 4.5) and experienced Spotify consultant with over 14 years of rich experience in building people

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