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
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.
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.
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.
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.
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 “email@example.com” for any suggestions or feedback.
Agile Coach – Benzne