Software teams that rework endlessly almost always share one root cause: they never agreed on what "done" means. A clear Definition of Done, well-written acceptance criteria, and a Definition of Ready checklist are the three structural agreements that stop rework before it starts.
Teams with a documented Definition of Done ship fewer defects than those without one, and catching defects during development costs significantly less than fixing them in production. This article explains exactly how to build all three, with practical examples and checklists you can apply to your team today.
TL;DR
Software teams spend a significant portion of total engineering effort on rework. Documented quality agreements are the primary prevention.
The Definition of Done sets universal quality standards for every increment. Acceptance criteria define specific conditions for individual stories.
The Definition of Ready is a pre-sprint gate to ensure stories are fully understood before development starts.
Regulated development processes benefit from formal acceptance criteria and security testing criteria to support quality and compliance standards.
These are not bureaucratic overhead. They are the engineering habits that distinguish teams with high throughput from those stuck in correction cycles.
About the Author: 724SOFTWARE is a Vietnam-based technology partner with 200+ engineers, 58% of whom are senior-level, delivering software across Fintech, Healthcare, and Enterprise ERP for clients in Singapore, Australia, the US, and the UK. The practices in this article are applied across client engagements spanning 10+ countries.
Why Does Rework Destroy Engineering Velocity?
Rework is not a minor tax on productivity. When "done" is undefined, teams spend substantial engineering effort rewriting work that was already considered complete, compounding delivery costs and delaying value.
The mechanism is straightforward: without a shared definition of "done," every team member-developer, QA engineer, product owner-carries a different mental model of completeness. A developer considers a feature done when it runs locally. A QA engineer considers it done after regression passes. A product owner considers it done when it matches the original intent. Without a shared agreement, work bounces between these definitions indefinitely.
What Is the Definition of Done, and What Should It Include?
The Definition of Done (DoD) is a formal description of the quality standards every increment must meet before it is considered shippable. The Scrum Guide defines it as the quality threshold for the Increment as a whole. SAFe treats it as a universal quality standard applying to all work items across teams.
A Definition of Done operates at the team level, not the story level. It applies consistently to every piece of work, making quality expectations transparent and non-negotiable.
Definition of done examples for a software engineering team:
Layer | Example Criteria
|
|---|---|
Code quality | Code reviewed by at least one senior engineer; no critical SonarQube violations |
Testing | Unit test coverage above threshold; integration tests passing in CI |
Security | No high-severity findings from automated SAST scan |
Documentation | API changes reflected in docs; changelog updated |
Deployment | Feature deployed to staging; smoke test passing |
Compliance | Acceptance criteria signed off by product owner |
A definition of done template should cover: code review, automated testing, manual QA sign-off, documentation, deployment verification, and compliance checks. Teams operating under quality management standards should ensure their DoD supports documented acceptance criteria in design and development outputs, as well as formal security acceptance criteria throughout the development lifecycle.
What Are Acceptance Criteria, and How Do You Write Them Effectively?
Stepping back from the team-level DoD, a separate but equally important question is: how do you specify what a specific feature must actually do?
Acceptance criteria are the conditions an individual user story or feature must meet to be accepted by the product owner. Where the DoD applies universally, acceptance criteria are story-specific. They answer the question: "What does this particular piece of functionality need to do to be correct?"
The most common format is Gherkin (Given/When/Then), which forces writers to specify a starting condition, a user action, and an expected outcome.
Acceptance criteria examples in agile format:
Given a registered user on the login page When they enter valid credentials Then they are redirected to the dashboard within two seconds.
Given a user with an expired session When they attempt to access a protected resource Then they are redirected to the login page with an explanatory message.
Poor user story acceptance criteria are vague ("the page should load fast") or untestable ("the UI should feel intuitive"). Strong criteria are binary: you can definitively pass or fail them
Checklist for acceptance criteria quality:
- [ ] Written before development starts (not after)
- [ ] Testable with a pass/fail outcome
- [ ] Specific about inputs, states, and expected outputs
- [ ] Agreed upon by the developer, QA engineer, and product owner before the sprint begins
- [ ] Linked to the user story they govern
What Is the Definition of Ready, and Why Does It Matter Before Sprint Planning?
Building on the acceptance criteria above, the harder question is: how do you prevent poorly defined stories from entering the sprint in the first place?
The Definition of Ready (DoR) is a pre-sprint quality gate. While the Scrum Guide does not formally mandate it, the definition of ready agile practice is widely adopted as the checklist a backlog item must satisfy before it can be accepted into a sprint. Its purpose is to confirm that a story is understood, estimated, and feasible before a developer picks it up.
Definition of ready checklist:
[ ] User story is written in a standard format (As a / I want / So that)
[ ] Acceptance criteria are documented and agreed upon
[ ] Story is estimated (story points or time)
[ ] Dependencies are identified and resolved
[ ] UI designs or wireframes are attached (if applicable)
[ ] No open questions remain from the previous refinement session
[ ] Security and compliance requirements are flagged if relevant
A story that fails this checklist should be returned to the backlog for refinement. Pulling unready stories into sprints is one of the most direct causes of mid-sprint blockers and the rework cycles that follow.
How Do These Three Agreements Work Together in Practice?
The three frameworks operate at different points in the delivery cycle and should not be confused with each other.
Agreement | Timing | Scope | Owner
|
|---|---|---|---|
Definition of Ready | Before sprint | Individual story | Product owner + team |
Acceptance Criteria | Before development | Individual story | Product owner |
Definition of Done | After development | Every increment | Whole team |
A practical example: a Fintech team building a payment reconciliation feature applies the DoR checklist during backlog refinement to confirm all edge cases are documented. During development, the developer tests against the acceptance criteria (specific reconciliation rules, error states, audit log format). On completion, the DoD checklist confirms code review, security scan, staging deployment, and documentation are all complete before the story is marked done.
Frequently Asked Questions
What is the difference between acceptance criteria and definition of done?
The Definition of Done applies to every work item as a universal quality standard. Acceptance criteria are specific to one story or feature and describe its functional requirements.
Can acceptance criteria replace the Definition of Done?
No. Acceptance criteria tell you whether a feature behaves correctly. The Definition of Done tells you whether the work meets the team's quality, security, and deployment standards. Both are required.
Who writes acceptance criteria?
The product owner drafts them, but they must be reviewed and agreed upon by the development team and QA before the story enters a sprint.
What is the Definition of Ready in agile?
It is a checklist confirming a backlog item is sufficiently understood, estimated, and dependency-free to be pulled into a sprint.
How detailed should a Definition of Done be?
Detailed enough to be unambiguous. If two team members can interpret a criterion differently, it needs to be rewritten.
Do ISO 9001 or ISO 27001 require a Definition of Done?
Quality management standards such as ISO 9001 and security standards such as ISO 27001 require documented acceptance criteria and formal security acceptance criteria in development processes. A well-structured DoD supports compliance with these standards.
How often should teams update their Definition of Done?
Review it at every sprint retrospective. As the team's capabilities and the product's complexity grow, the standards should reflect that growth.
About 724SOFTWARE
724SOFTWARE is a Vietnam-based technology partner providing dedicated engineering teams, custom software development, and managed IT services for startups, SaaS companies, and enterprises across Singapore, Australia, the US, and the UK. With 200+ professionals (58% senior-level), ISO 9001, ISO 27001:2022, SOC 2 Type II, and GDPR compliance, and a 95% client retention rate, the company operates as a long-term delivery partner rather than a transactional vendor. As an official partner of Claude (Anthropic) and Cursor, 724SOFTWARE integrates generative AI tools into the SDLC to accelerate delivery by approximately 30% across client engagements.
If your team is spending too many sprints fixing what was already "done," the problem is structural, not individual. Reach out to the 724SOFTWARE team at https://724software.com.vn to explore how a dedicated Vietnam software team with standardized delivery practices can reduce rework and increase your throughput from the first sprint.
