Introduction
Agile recommends teams to be cross functional and that implies teams to be composed of people with different skill sets who can convert a requirement into a working software. Let’s 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. “When can the story be picked up to start work?” And “When can a story be marked Done?”.
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.
This Blog aims at explaining the following points
- What is DOR and DOD?
- Why do we need DOR and DOD?
- When do we derive it?
- Some factors we need to consider while deriving them.
- Some Sample DOR and DOD points
Definition Of Ready ( DOR )
What is DOR?
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.
Why do we need DOR?
- Work Items without enough information might cause a lot of confusion for the dev team members and might not give the right direction
- Dependencies if not resolved, will not let teams commit to deliver a work item
- A story which is not groomed / or not understood by the team can cause re work
When do we derive DOR?
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.
Some factors we need to consider before deriving DOR?
- Nature of your project ( Backend Heavy / Frontend / Mobile Applications etc )
- Skills involved in delivering your project
- Requirements and its structure ( NFR , Compliance , Security etc )
- Dependent teams
Sample DOR:
- Business value is clearly defined in the story
- Story fulfills INVEST ( Story can be completed in one sprint )
- Acceptance Criteria is well defined
- NFR is clearly mentioned
- Dependencies are identified and resolved
- Design Assets are attached in the story
- Story is estimated
- Story is groomed at least once
“Definition Of Done ( DOD )”
What is DOD?
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.
Why do we need DOD?
- To create shared understanding around multiple teams
- Creates working agreements
- Promotes consistency in quality and user experience
- Helps in Cross-team collaboration
- Ensures teams comply with organization / domain requirements
When do we derive DOD?
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.
Some factors we need to consider before deriving DOR?
- Nature of the project
- Organization / domain / coding standards
- Business and functional requirements
- Quality
- Non functional requirements
Sample DOD:
- Acceptance Criteria is met
- Story is tested
- Story is demoed to the PO and approved
- No open P1 , P2 Issues
- Not more than 3-5 open P3 , P4 issues
- Unit testing has 85% coverage
- Tests are automated and passed
- Code is merged in the branch
- All Story related tickets are updated in the tool
Conclusion
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.
With this, our blog on “Meet the DO brothers – DOR and DOD” 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 “consult@benzne.com” for any suggestions or feedback.
Sujith G
Agile Coach – Benzne
