DoD is a term used to represent and reinforce transparency, assure Built-In quality, and set the right expectations for the work items to be planned, developed, and completed during the Agile product development.
The definition of done (DoD) is when all conditions in a software product must be satisfied to be ready to be accepted by a user, customer, team, or consuming system. We should meet the definition of done to ensure quality. Keep in mind that the main goal is to prevent or minimize the rework by preventing user stories that don’t meet the definition from being promoted to higher-level environments. It will prevent features that don’t meet the definition from being delivered to the customer or user.
This is not carved in stone, working as a software engineer you can deal with the stakeholders to accept the MVP to be delivered. We mean that you can balance your delivery being accepted not as done but accepted to be tested and validated.
To make the delivery viable we will provide 2 types of DoD.
- 🚨 The first is a DoD to meet a story that needs urgent (High priority and needs at least an MVP.
- 🚦 The second DoD is to meet a complete User Story that will follow the complete criteria.
- The solution is implementing
- Follow the code style guide
- The commit follows git-flow
- The feature, bug etc., is published in a Merge Request (using an issue template)
- Code is peer-reviewed and approved at least by one developer
- Code builds without error
- Feature should be tested for PM/PO/QA in stating environment
- The unit tests were written
- The solution is implemented
- Make sure that the code is following the code style guide
- The commit follows git-flow
- The feature, bug etc., is published in a Merge Request (using an issue template)
- Code is peer-reviewed and approved at least by one developer
- Some refactoring is necessary after code review
- E2E testing is complete
- Browser or device test is complete after the merged
- Documentation is complete
- Code builds without error
- The feature should be tested for Product manager or Product Owner or QA in staging environment
- The code is deployed in production within a new release
Pull together all the teams and teammates responsible for the launch.
Feel free to link to other Notion pages about your product.
↓ Click through the different database tabs to create and see other views.
Use this section to align on all the elements of a successful launch. Be sure to use the @ key to tag teammates and select dynamic dates and times.
@-name
- [ ]
- [ ]
- [ ]
Here’s where to conduct a post mortem to analyze the success of the launch.
Pre-launch checklist