A Small-Team Definition of Done That Prevents “Almost Finished” Work

A small team can move fast, but it can also ship “almost finished” work. That is the ticket that looked done in the sprint, but becomes a mess in the release: missing tests, unclear behavior, no way to roll back, or a support team that cannot answer basic questions.

A good Definition of Done (DoD) is a shared agreement about what “done” means for your team, in your environment, with your constraints. It is not bureaucracy. It is a way to protect focus by preventing last-minute surprises.

This post gives you a practical, lightweight DoD you can adopt quickly, plus add-ons for different types of work. You will also see a concrete example, common mistakes, and a short section on when not to do this.

Why a Definition of Done matters

Without a DoD, the definition of “done” silently changes depending on who is asked. A developer may think “done” means merged. A product owner may think it means released. A customer thinks it means solved forever.

A DoD makes delivery predictable by turning hidden expectations into explicit checks. It helps in three practical ways:

• Reduces rework: you catch missing pieces while context is fresh.
• Improves planning: tickets include the real cost of shipping, not just coding.
• Builds trust: stakeholders learn that “done” means usable and supportable.

Think of DoD as your team’s minimum quality bar. You can exceed it when needed, but you should rarely go below it. When you do, it should be an explicit decision with a clear follow-up.

A copyable small-team Definition of Done checklist

This checklist is designed for teams that ship software regularly and want a default that is strict enough to prevent pain, but small enough to finish within a sprint. Adjust wording to match your stack and release process.

Baseline DoD (applies to most tickets)

1. Scope is clear: acceptance criteria are written in plain language and reviewed by someone besides the implementer.
2. Code is reviewed: at least one reviewer confirms behavior, readability, and risk areas (not just style).
3. Tests cover the change: automated tests exist where they add signal, and they fail for the pre-change behavior.
4. Edge cases considered: errors, empty states, and permissions are handled deliberately (even if the answer is “not supported”).
5. Observability added: key events are logged or tracked so failures can be diagnosed without guesswork.
6. Docs or notes updated: the next person can understand how it works and how to support it.
7. Risk is managed: rollout plan is defined (feature flag, phased release, or a clear rollback path).
8. Done is verified: someone confirms the feature works in a production-like environment (staging, preview, or a controlled release).

Add-ons for specific work types

Not every ticket needs the same extras. Instead of inflating your baseline, add small “done add-ons” by category:

• UI changes: basic accessibility checks (keyboard navigation, focus states, readable labels) and screenshots or notes for reviewers.
• Data or migrations: backfill plan, verification query, and a rollback or forward-only decision documented.
• APIs: contract documented, error responses defined, and at least one integration-level check.
• Security-sensitive work: threat review lite (what could go wrong, how it is mitigated) and secrets handling confirmed.

If you want a simple way to operationalize this, store the DoD next to your team workflow and treat it like versioned policy. Keep it readable and short. For example:

definitionOfDone:
  baseline:
    - reviewed
    - testsUpdated
    - logsOrMetricsAdded
    - docsOrSupportNotesUpdated
    - rollbackOrFlagPlan
    - verifiedInStaging
  addOns:
    ui: [a11ySmokeCheck]
    api: [errorContractDefined]
    data: [backfillAndVerificationPlan]

Real-world example: a small feature shipped end to end

Imagine a two-person product team building a SaaS app. A customer request comes in: “I need a password reset email that expires after 30 minutes.” It sounds simple, but these are the kinds of features that can create support debt if shipped halfway.

Here is how the DoD shapes the ticket:

• Scope is clear: acceptance criteria specify expiration time, what happens when a token is reused, and the error message shown.
• Edge cases considered: requests for unknown emails, rate of requests, and what happens if the user changes their email.
• Tests cover the change: unit tests for token generation and expiry; a higher-level test that simulates the reset flow.
• Observability added: a log event for “password_reset_requested” and “password_reset_completed” with basic metadata (not the token).
• Docs or notes updated: support notes include “common reasons reset fails” and where to look in logs.
• Risk managed: release behind a feature flag for a small subset of users first, with an easy switch-off if email delivery issues appear.
• Verified: someone tests the flow in staging, including expired token behavior.

The outcome is not just “feature works on my machine.” The outcome is “feature behaves predictably, is debuggable, and can be turned off safely.” That is the difference between speed and sustainable speed.

Common mistakes (and how to fix them)

Most teams fail with DoD for avoidable reasons. Here are the patterns that show up repeatedly:

• Making DoD a wish list: If it includes items you cannot realistically do most of the time, it becomes performative. Fix: shrink the baseline until it is consistently achievable.
• Confusing “done” with “deployed”: Deployment is a step, not a guarantee of quality. Fix: include verification and rollback planning as explicit checks.
• Letting quality be implicit: “Write tests” is vague. Fix: specify what kind of test provides value for your system (unit, integration, smoke), and when a manual check is acceptable.
• Ignoring supportability: If support needs to ask engineers for every incident, you have shipped hidden work. Fix: require support notes or runbook updates for user-impacting changes.
• Using DoD as punishment: If DoD is used to blame people, they will hide problems. Fix: treat DoD misses as process signals, not personal failure.

A useful rule: if a DoD item is skipped, the team should be able to answer “what risk did we accept?” in one sentence. If you cannot, the DoD is not being used as a decision tool.

When not to use a single Definition of Done

A single DoD is a good default, but there are cases where it can slow you down or create false certainty.

• Exploration work: spikes, research, and prototyping are about learning, not shipping. Use a different DoD like “document findings, include recommendation, and capture unknowns.”
• Emergency mitigation: in an incident, speed can matter more than perfect hygiene. Still, do not abandon DoD entirely. Instead, use a “hotfix DoD” that includes a post-incident follow-up ticket for tests and documentation.
• High-assurance domains: if your product requires strict compliance, you likely need a stronger, audited process. A lightweight DoD is not enough by itself.

The principle is simple: match the DoD to the goal of the work. Shipping requires a high bar. Learning requires fast capture of truth. Emergencies require safety and follow-up.

How to roll it out and keep it alive

Rolling out a DoD is change management, not a document update. The goal is consistent behavior under time pressure. Here is a small-team approach that works without heavy ceremony:

1. Start with the pain: list the top three “almost finished” failures your team sees (bugs after release, missing context, hard rollbacks). Make sure each DoD item maps to one of these pains.
2. Adopt a two-level model: a baseline plus add-ons. This prevents debates on every ticket while keeping the baseline small.
3. Make it visible in the workflow: include DoD checks in your ticket template or PR template. The DoD should appear where work happens, not only in a wiki.
4. Define an explicit “exception” path: allow skipping an item only if (a) the risk is stated, and (b) a follow-up ticket is created. This keeps speed possible without lying about completeness.
5. Review it monthly for 10 minutes: ask two questions: “Which item saved us recently?” and “Which item is too vague or too heavy?” Update the text and keep it short.

Conclusion

A small team’s advantage is speed, but speed without a shared finish line creates churn. A practical Definition of Done gives you that finish line. It helps you ship work that is usable, supportable, and safe to release.

Start with the baseline checklist above, add only what your team truly needs, and revisit it regularly. The best DoD is not the strictest one. It is the one you actually follow.

FAQ

How strict should our Definition of Done be?

Strict enough to prevent your most common rework, and small enough that you can meet it on most tickets. If the team routinely cannot meet the DoD, reduce the baseline and move items into add-ons.

Is Definition of Done the same as acceptance criteria?

No. Acceptance criteria describe what the user gets from a specific ticket. DoD describes the quality and completeness checks that must be true for any ticket to be considered finished.

Who owns the Definition of Done?

The whole team. In practice, a tech lead or scrum master can steward updates, but developers, product, and anyone supporting releases should be able to propose changes based on real outcomes.

What if we cannot do tests for a particular change?

Make it an explicit exception: write down the risk, add alternative verification (manual smoke test steps, staging verification), and create a follow-up ticket to add automated coverage when feasible.

How do we avoid DoD turning into a long checklist?

Use a two-level model: a short baseline plus add-ons. Also, remove items that are redundant or that do not map to actual pain your team experiences.