Having a Definition of Done (DoD) and Definition of Undone (DoUnD) is crucial in agile development because they establish clear, shared expectations about what constitutes a completed or incomplete work item.
The DoD is a comprehensive list of criteria that a team agrees upon to ensure consistency and quality. Think of it as a quality-assurance gate for every piece of work. When a work item is marked "Done," it means it has passed all the checks on this list, and the entire team is confident in its quality and readiness for potential release.
Clarity and Alignment:
Ensures everyone on the team—developers, testers, product owners—has the same understanding of what “done” means.
Quality Assurance:
Helps maintain consistent quality by including criteria like code reviews, testing, documentation, and deployment readiness.
Transparency:
Makes it easier to track progress and communicate with stakeholders about what’s truly complete.
Reduced Rework:
Prevents misunderstandings that lead to incomplete or buggy features being marked as done.
Sprint Planning Accuracy:
Helps teams better estimate effort and velocity, improving planning and forecasting.
A typical DoD checklist for a software development team might include:
Code is peer-reviewed and approved.
All unit tests are written and they pass.
All acceptance criteria are met.
The code is integrated into the main branch without errors.
Automated and manual tests are completed.
Documentation is updated (e.g., user guides, API documentation).
The new functionality is deployed to a staging environment and smoke tested.
There are no known defects related to the feature.
The DoD is not static; it evolves as a team matures and improves its practices. The more rigorous the DoD, the higher the quality of the product increment.
The term "undone work" refers to any work that remains at the end of a sprint because it did not meet the team's Definition of Done. Undone work is often a sign of an issue within the sprint, and it represents a risk and a form of waste because the work is not yet ready to deliver any value to the customer. In agile frameworks like Scrum, undone work is any part of a software increment that fails to meet the team's Definition of Done (DoD) and prevents a feature or increment from being truly releasable .
This could include:
Missing automated tests
Incomplete documentation
Unresolved bugs
Lack of integration or deployment readiness
Failing to meet performance or security standards
Common causes of undone work include:
Over-committing: The team took on more work than they could realistically complete in the sprint.
Unexpected issues: The team encountered technical challenges or unforeseen bugs.
Lack of adherence to the DoD: The team did not follow their own established quality standards, skipping critical steps like testing or code review.
Why It Matters in Production
In production environments, undone work can have serious consequences:
Delays in release cycles: Features may need to be reworked or retested.
Reduced product quality: Incomplete features can lead to bugs or poor user experience.
Technical debt accumulation: Repeatedly ignoring undone work builds up long-term maintenance costs.
Stakeholder dissatisfaction: Promised features may not function as expected.
Best Practices
Track undone work explicitly: Use backlog items or technical debt logs.
Refine the Definition of Done regularly: Ensure it evolves with product and team maturity.
Avoid presenting undone work at sprint reviews: It misleads stakeholders about progress.
Use undone work as a learning tool: Identify process gaps and improve team discipline.
When a work item is "undone" at the end of a sprint, it doesn't just disappear. It goes back into the product backlog to be re-prioritized and considered for a future sprint. This process is important for maintaining transparency and accurately measuring a team's progress
This is a predefined set of steps that a team follows to safely undo a deployment or change in a production environment if something goes wrong. It's a critical part of release management and incident response.
Trigger Criteria:
Conditions under which a rollback should be initiated (e.g., failed health checks, error spikes, user complaints).
Rollback Steps:
Revert code to the previous stable version
Restore database backups or schema
Reconfigure infrastructure or settings
Clear caches or restart services
Verification:
Steps to confirm the rollback was successful (e.g., smoke tests, monitoring dashboards).
Communication Plan:
Who to notify—stakeholders, support teams, users.
Postmortem Prep:
Logging the incident and scheduling a retrospective.