{"id":184,"date":"2026-03-10T18:07:15","date_gmt":"2026-03-10T18:07:15","guid":{"rendered":"https:\/\/nextagile.ai\/blogs\/?p=184"},"modified":"2026-04-04T05:04:06","modified_gmt":"2026-04-04T05:04:06","slug":"what-is-dod-and-dor","status":"publish","type":"post","link":"https:\/\/nextagile.ai\/blogs\/agile\/what-is-dod-and-dor\/","title":{"rendered":"DOR and DOD in Agile: The Complete Guide to Ready and Done"},"content":{"rendered":"\r\n\r\n\r\n

Key Highlights DOD And DOR<\/strong><\/p>\r\n

    \r\n
  1. DOR (Definition of Ready) is a shared checklist ensuring user stories are fully prepared before development begins, covering acceptance criteria, dependencies, design assets, estimation, and grooming.<\/li>\r\n
  2. DOD (Definition of Done) is a shared checklist that defines when a story can be marked complete, covering testing, code merge, PO approval, test automation, and quality thresholds.<\/li>\r\n
  3. Both are co-created before the project kicks off, with input from the entire team including the PO, SM, developers, and QA, and are continuously refined through sprint retrospectives.<\/li>\r\n
  4. DOR eliminates common sprint failures caused by vague requirements, unresolved dependencies, and stories that were never properly groomed or estimated.<\/li>\r\n
  5. DOD drives consistent quality and shared accountability by setting a clear, non-negotiable bar for what it means to ship a working increment.<\/li>\r\n
  6. Key factors shaping both definitions include the nature of the project, team skill sets, compliance and security requirements, and organizational coding and quality standards.<\/li>\r\n
  7. While Agile is not a gated process, co-creating working agreements like DOR and DOD is essential for building team trust, maintaining delivery consistency, and shipping with confidence.<\/li>\r\n<\/ol>\r\n

    Introduction<\/h2>\r\n\r\n\r\n\r\n

    Agile recommends\u00a0teams to be cross functional<\/a>\u00a0and that implies teams to be composed of people with different skill sets who can convert a requirement into a working software. Let\u2019s take an example of a requirement \/ user story which has come up for a team which involves Design, Backend , Frontend and QA folks. There are two questions which arise in all the team members. \u201cWhen can the story be picked up to start work?\u201d And \u201cWhen can a story be marked Done?\u201d.<\/p>\r\n\r\n\r\n\r\n

    Story naturally progresses through different states of the workflow. For Instance, when the design part is done, the development team picks it up, and when the development is done the QA folks pick it up to validate. In the above flow, for development team members, their work is completed as soon as the QA teams pick it up and design team members conclude their work when the story is picked up for development. With this, there is no common understanding of deciding when a story is completed or ready to be shipped. Also, while we understand the flow Design > Dev > QA, there is a common understanding of when a story is ready to be picked up.<\/p>\r\n\r\n\r\n\r\n

    This Blog aims at explaining the following points<\/p>\r\n\r\n\r\n\r\n

      \r\n
    1. What is DOR and DOD?<\/li>\r\n\r\n\r\n\r\n
    2. Why do we need DOR and DOD?<\/li>\r\n\r\n\r\n\r\n
    3. When do we derive it?<\/li>\r\n\r\n\r\n\r\n
    4. Some factors we need to consider while deriving them.<\/li>\r\n\r\n\r\n\r\n
    5. Some Sample DOR and DOD points<\/li>\r\n<\/ol>\r\n\r\n\r\n\r\n

      Definition Of Ready ( DOR )<\/h2>\r\n\r\n\r\n\r\n

      What is DOR?<\/h3>\r\n\r\n\r\n\r\n

      DOR is a document which usually is in the form of checklists that contains all the work the PO and SM should take care of a requirement or user story, before the team can start working on it.
      DOR is a guideline which educates everyone in the team and brings everyone on the same page on what needs to be taken care of before the story is picked up by the dev teams.
      DOR ensures that the work prioritized for the next sprint is ready to be picked up and gives confidence to the dev teams to commit for the delivery.<\/p>\r\n\r\n\r\n\r\n

      Why do we need DOR?<\/h3>\r\n

      \"Why<\/p>\r\n\r\n\r\n\r\n\r\n\r\n

        \r\n
      1. Work Items without enough information might cause a lot of confusion for the dev team members and might not give the right direction<\/li>\r\n\r\n\r\n\r\n
      2. Dependencies if not resolved, will not let teams commit to deliver a work item<\/li>\r\n\r\n\r\n\r\n
      3. A story which is not groomed \/ or not understood by the team can cause re work<\/li>\r\n<\/ol>\r\n\r\n\r\n\r\n

        When do we derive DOR?<\/h3>\r\n\r\n\r\n\r\n

        DOR is derived before the start of the project by taking consensus from all the dev team members, PO, SM and other stakeholders. But DOR may be modified or improved during the course of sprints taking input in the retrospection.<\/p>\r\n\r\n\r\n\r\n

        Some factors we need to consider before deriving DOR?<\/h3>\r\n\r\n\r\n\r\n
          \r\n
        1. Nature of your project ( Backend Heavy \/ Frontend \/ Mobile Applications etc )<\/li>\r\n\r\n\r\n\r\n
        2. Skills involved in delivering your project<\/li>\r\n\r\n\r\n\r\n
        3. Requirements and its structure ( NFR , Compliance , Security etc )<\/li>\r\n\r\n\r\n\r\n
        4. Dependent teams<\/li>\r\n<\/ol>\r\n\r\n\r\n\r\n

          Sample DOR:<\/h3>\r\n\r\n\r\n\r\n
            \r\n
          1. Business value is clearly defined in the story<\/li>\r\n\r\n\r\n\r\n
          2. Story fulfills INVEST ( Story can be completed in one sprint )<\/li>\r\n\r\n\r\n\r\n
          3. Acceptance Criteria is well defined<\/li>\r\n\r\n\r\n\r\n
          4. NFR is clearly mentioned<\/li>\r\n\r\n\r\n\r\n
          5. Dependencies are identified and resolved<\/li>\r\n\r\n\r\n\r\n
          6. Design Assets are attached in the story<\/li>\r\n\r\n\r\n\r\n
          7. Story is estimated<\/li>\r\n\r\n\r\n\r\n
          8. Story is groomed at least once<\/li>\r\n<\/ol>\r\n\r\n\r\n\r\n

            \u201cDefinition Of Done ( DOD )\u201d<\/h2>\r\n\r\n\r\n\r\n

            What is DOD?<\/h3>\r\n\r\n\r\n\r\n

            DOD is a document which is usually in the form of checklists that contains all the work the Dev team should take care for a requirement or user story before marking it to Done state.
            DOD is a guideline which educates everyone in the team and brings everyone on the same page on what needs to be taken care before the story is marked to Done
            DOD ensures transparency by providing a common shared understanding of what done means. It enables shipment of an increment.<\/p>\r\n\r\n\r\n\r\n

            Why do we need DOD?<\/h3>\r\n

            \"Why<\/p>\r\n\r\n\r\n\r\n\r\n\r\n

              \r\n
            1. To create shared understanding around multiple teams<\/li>\r\n\r\n\r\n\r\n
            2. Creates working agreements<\/li>\r\n\r\n\r\n\r\n
            3. Promotes consistency in quality and user experience<\/li>\r\n\r\n\r\n\r\n
            4. Helps in Cross-team collaboration<\/li>\r\n\r\n\r\n\r\n
            5. Ensures teams comply with organization \/ domain requirements<\/li>\r\n<\/ol>\r\n\r\n\r\n\r\n

              When do we derive DOD?<\/h3>\r\n\r\n\r\n\r\n

              DOD is derived before the start of the project by taking consensus from all the dev team members, PO, SM and other stakeholders. But DOD may be modified or improved during the course of sprints taking input in the retrospection.<\/p>\r\n\r\n\r\n\r\n

              Some factors we need to consider before deriving DOR?<\/h3>\r\n\r\n\r\n\r\n
                \r\n
              1. Nature of the project<\/li>\r\n\r\n\r\n\r\n
              2. Organization \/ domain \/ coding standards<\/li>\r\n\r\n\r\n\r\n
              3. Business and functional requirements<\/li>\r\n\r\n\r\n\r\n
              4. Quality<\/li>\r\n\r\n\r\n\r\n
              5. Non functional requirements<\/li>\r\n<\/ol>\r\n\r\n\r\n\r\n

                Sample DOD:<\/h3>\r\n\r\n\r\n\r\n
                  \r\n
                1. Acceptance Criteria is met<\/li>\r\n\r\n\r\n\r\n
                2. Story is tested<\/li>\r\n\r\n\r\n\r\n
                3. Story is demoed to the PO and approved<\/li>\r\n\r\n\r\n\r\n
                4. No open P1 , P2 Issues<\/li>\r\n\r\n\r\n\r\n
                5. Not more than 3-5 open P3 , P4 issues<\/li>\r\n\r\n\r\n\r\n
                6. Unit testing has 85% coverage<\/li>\r\n\r\n\r\n\r\n
                7. Tests are automated and passed<\/li>\r\n\r\n\r\n\r\n
                8. Code is merged in the branch<\/li>\r\n\r\n\r\n\r\n
                9. All Story related tickets are updated in the tool<\/li>\r\n<\/ol>\r\n
                  \r\n

                  Transform your organization with expert SAFe consulting services<\/a>. Achieve scalable success with tailored solutions. Contact us for a consultation!<\/em><\/p>\r\n<\/blockquote>\r\n\r\n\r\n\r\n

                  Conclusion<\/h2>\r\n\r\n\r\n\r\n

                  Though agile is not a gated approach, it is important to co-create some shared guidelines on when a piece of work can start and when a piece of work can be shipped. This helps create harmony within the team members and deliver work with consistent quality and common understanding.<\/p>\r\n\r\n\r\n\r\n

                  With this, our blog on \u201cMeet the DO brothers \u2013 DOR and DOD\u201d comes to an end. We hope this blog has helped you understand the concepts , why do we need them and how it helps the teams. Please reach out to \u201cconsult@nextagile.ai\u201d for any suggestions or feedback.<\/p>\r\n\r\n\r\n","protected":false},"excerpt":{"rendered":"

                  Key Highlights DOD And DOR DOR (Definition of Ready) is a shared checklist ensuring user stories are fully prepared before development begins, covering acceptance criteria, dependencies, design assets, estimation, and grooming. DOD (Definition of Done) is a shared checklist that defines when a story can be marked complete, covering testing, code merge, PO approval, test…<\/p>\n","protected":false},"author":6,"featured_media":4046,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"content-type":"","footnotes":""},"categories":[2],"tags":[5,7,6],"class_list":["post-184","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-agile","tag-agile","tag-project-management","tag-scrum"],"_links":{"self":[{"href":"https:\/\/nextagile.ai\/blogs\/wp-json\/wp\/v2\/posts\/184","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/nextagile.ai\/blogs\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/nextagile.ai\/blogs\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/nextagile.ai\/blogs\/wp-json\/wp\/v2\/users\/6"}],"replies":[{"embeddable":true,"href":"https:\/\/nextagile.ai\/blogs\/wp-json\/wp\/v2\/comments?post=184"}],"version-history":[{"count":12,"href":"https:\/\/nextagile.ai\/blogs\/wp-json\/wp\/v2\/posts\/184\/revisions"}],"predecessor-version":[{"id":6527,"href":"https:\/\/nextagile.ai\/blogs\/wp-json\/wp\/v2\/posts\/184\/revisions\/6527"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/nextagile.ai\/blogs\/wp-json\/wp\/v2\/media\/4046"}],"wp:attachment":[{"href":"https:\/\/nextagile.ai\/blogs\/wp-json\/wp\/v2\/media?parent=184"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/nextagile.ai\/blogs\/wp-json\/wp\/v2\/categories?post=184"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/nextagile.ai\/blogs\/wp-json\/wp\/v2\/tags?post=184"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}