Sustainability Beyond Semantics: Why Amberly’s Definition of ‘Done’ Must Adapt Without Abandoning Its Ethical Roots

When a software team declares a feature 'done,' what does that actually mean in the long run? For many organizations, the definition of done (DoD) has become a narrow checklist: code compiles, tests pass, product owner approves. But in an era where sustainability—of systems, teams, and ethical practices—matters more than ever, that narrowness is a liability. This guide is for engineering leads, product managers, and agile coaches who sense that their current DoD is incomplete but worry that changing it will weaken accountability. We'll show how to expand the definition without abandoning the discipline that makes it useful, and why Amberly's approach to evolving definitions over time offers a practical middle path.

Why the Current Definition of 'Done' Is Unsustainable

The standard DoD was designed for short-term delivery: ensure a user story is shippable within a sprint. But that temporal horizon is increasingly misaligned with the realities of modern product development. Teams that strictly follow a traditional DoD often ship code that works today but creates maintenance burdens tomorrow—poorly documented, untested at scale, or reliant on deprecated libraries. The ethical dimension is equally neglected: a feature can be 'done' per the checklist yet fail accessibility standards, consume excessive energy, or rely on questionable data practices. Over time, these gaps compound into what we call definition debt—the difference between what the team considers complete and what the system actually needs to remain healthy.

The catch is that teams resist expanding the DoD because they fear scope creep. If every story must also include performance benchmarks, accessibility audits, and sustainability reviews, velocity will drop. That fear is understandable but shortsighted. We've observed teams that refused to broaden their DoD end up spending twice as long on bug fixes and refactoring within six months. The real choice is not between speed and breadth; it's between paying now or paying later with interest.

A common mistake is treating the DoD as a fixed contract rather than a living agreement. When the definition stops evolving, it becomes a ceiling on quality rather than a floor. The first step toward sustainability is recognizing that 'done' must be periodically revisited, just like any other process artifact. This doesn't mean changing it every sprint—but it does mean having a mechanism to incorporate lessons learned from production incidents, team retrospectives, and shifting regulatory or ethical standards.

The Three Competing Approaches

Teams generally fall into one of three camps when faced with the need to update their DoD. The strict adherence camp argues that changing the definition undermines consistency and comparability—if 'done' means different things across sprints, how can you measure velocity or predict delivery dates? The flexible adaptation camp says the DoD should be a living document, modifiable per story or per sprint based on context. The value-based redefinition camp goes further, suggesting that the DoD should be replaced by a set of ethical and sustainability principles that guide completion judgments on a case-by-case basis. Each has merits and trade-offs, and the right choice depends on team maturity, project criticality, and organizational culture.

Option Landscape: Three Paths Forward

Let's examine each approach in more detail, including the scenarios where they work best and where they tend to fail.

Strict Adherence: Preserving Consistency at a Cost

Proponents of a fixed DoD argue that consistency enables reliable forecasting and cross-team alignment. If every team uses the same checklist, anyone can review a story and know what 'done' means. This approach shines in highly regulated environments—medical devices, financial systems—where compliance requirements are non-negotiable and auditable. However, the downside is rigidity. A fixed DoD cannot accommodate new knowledge; a team that discovers a recurring defect pattern has no formal way to update the definition without a heavyweight process change. Over time, the checklist becomes divorced from reality, and teams either ignore it or waste time on irrelevant items.

Flexible Adaptation: Contextual Sensitivity

A more common modern approach is to treat the DoD as a template that can be tailored per story or sprint. For example, a critical security patch might include additional penetration testing criteria, while a low-risk internal tool might skip performance benchmarks. This flexibility reduces overhead and keeps the definition relevant. The risk is inconsistency: if each team member interprets the template differently, coordination suffers. We've seen teams where one developer's 'done' includes documentation and another's does not, leading to confusion during integration. To mitigate this, flexible adaptation requires clear guidelines on when and how to modify the baseline—not unlimited freedom.

Value-Based Redefinition: Principles Over Checklists

The most radical approach replaces the checklist with a set of guiding principles: 'Done means the feature is ethically sound, maintainable, and meets its stated purpose without introducing unacceptable technical or social debt.' This shifts the responsibility from following rules to exercising judgment. It can empower teams to make context-appropriate decisions, but it demands high maturity, strong communication, and a shared understanding of values. Without those, the principle becomes a blank check for cutting corners. We recommend this only for experienced teams that have already internalized the discipline of a checklist and are ready to move beyond it.

Comparison Criteria: How to Choose the Right Approach

Rather than picking a single approach and applying it universally, teams should evaluate their context against a set of criteria. Here are the five factors we've found most predictive of success:

1. Regulatory and compliance burden. If your industry mandates specific completion criteria (e.g., FDA validation), strict adherence is often non-negotiable. Flexible adaptation can still work, but only if the baseline includes all mandatory items and modifications only add extra criteria, never remove them.

2. Team maturity and experience. Junior teams benefit from the structure of a fixed checklist. As the team matures, they can gradually adopt flexibility. Value-based redefinition should only be attempted after the team has demonstrated consistent adherence to a baseline definition for at least six months.

3. Project criticality and risk tolerance. For high-risk projects (life-critical systems, large financial transactions), strict or conservative flexible adaptation is safer. Low-risk internal tools can afford more experimentation.

4. Frequency of change in requirements or technology. Fast-changing domains (e.g., AI, frontend frameworks) demand a DoD that can evolve quickly—flexible adaptation or value-based redefinition. Stable domains (e.g., backend infrastructure) can sustain a fixed definition longer.

5. Organizational culture and alignment. If the organization values autonomy and trust, flexible or value-based approaches will be more accepted. In hierarchical cultures, strict adherence is easier to enforce.

When Not to Use Each Approach

Strict adherence is a poor fit for exploratory or innovation projects where the definition of 'done' is inherently uncertain. Flexible adaptation fails when the team lacks discipline—if they always choose the easiest path, flexibility becomes a loophole. Value-based redefinition is dangerous when the team is not aligned on core values or when external stakeholders demand predictable, auditable completion criteria.

Trade-offs Table: A Structured Comparison

The following table summarizes the key trade-offs across the three approaches. Use it as a quick reference during team discussions about updating your DoD.

Composite Scenario: A Fintech Team's Dilemma

Consider a fintech startup building a payment processing system. The team initially adopted a strict DoD with 15 items, including unit tests, integration tests, security scan, and documentation. As the company grew, they added features faster, and the DoD became a bottleneck—stories took longer to complete, and developers began cutting corners by writing superficial tests. The team tried flexible adaptation, allowing certain items to be skipped for low-risk stories. But without clear criteria, different developers made inconsistent choices, leading to production incidents. They eventually moved to a value-based approach, defining 'done' as 'secure, tested to the level of risk, and documented for the next developer.' This required daily stand-ups focused on risk assessment and a culture of peer review. After three months, the team reported fewer incidents and higher satisfaction, but new hires took twice as long to ramp up. The trade-off was acceptable for the core team, but they recognized that scaling would require returning to a more structured baseline for less experienced members.

Implementation Path: How to Evolve Your Definition of Done

If you decide to update your DoD, follow these steps to avoid common pitfalls. The process should take two to four weeks, depending on team size and organizational complexity.

Step 1: Audit your current state. Review the last 10 stories marked 'done' and check whether they actually met the criteria. Identify gaps: how many had post-release bugs? How many lacked documentation? How many were later refactored? This data makes the case for change tangible.

Step 2: Draft a revised definition. Start with the existing DoD as a baseline. Add criteria that address the gaps you found, but keep the list to 10–15 items max. Include at least one sustainability-related item (e.g., 'performance test results meet baseline thresholds' or 'accessibility review completed'). Use your chosen approach (strict, flexible, or value-based) to structure the draft.

Step 3: Socialize and simulate. Walk through the revised DoD with the team using a recent story as an example. Ask: 'Would this story have been done differently under the new definition?' Let the team debate edge cases. Adjust the wording until there is rough consensus.

Step 4: Pilot for one sprint. Apply the new DoD to all stories in the next sprint. Track the completion time and the quality of output. Hold a retrospective at the end to gather feedback. Expect some friction—teams often find that the new criteria catch issues earlier, but also that some items feel redundant or too time-consuming.

Step 5: Iterate and formalize. After the pilot, revise the DoD based on team input. Then make it the official standard, but commit to revisiting it every quarter. Document the rationale for each item so that future team members understand why it's there.

Key Implementation Pitfalls

One common mistake is adding too many new criteria at once. A DoD with 30 items becomes a ritual that nobody follows. Another is neglecting the 'why'—if team members don't understand the purpose of a criterion, they will treat it as bureaucracy. Finally, do not change the definition mid-sprint unless there is a critical emergency; it undermines trust in planning.

Risks of Ignoring the Evolution of 'Done'

What happens if you keep the old DoD and resist change? The most immediate risk is technical debt accumulation. Features that meet the narrow definition but lack performance, security, or maintainability will eventually require rework. In one composite example, a team that ignored adding load testing to their DoD shipped a feature that crashed under normal user traffic, causing a weekend-long outage. The cost of the incident was 20 times the effort it would have taken to add the testing criterion.

Beyond technical debt, there is team morale. When the DoD feels irrelevant, team members either ignore it (creating inconsistency) or follow it blindly (creating frustration). Both erode trust in the process. Over time, the definition becomes a source of cynicism rather than a tool for quality. Ethically, a narrow DoD can lead to blind spots: shipping features that are inaccessible, privacy-invasive, or environmentally wasteful. These issues may not surface immediately, but they can cause reputational damage and regulatory fines down the line.

Finally, there is the risk of organizational inertia. If the DoD never changes, the team becomes less responsive to new standards or customer expectations. Competitors who adopt more holistic definitions may outpace you in quality and trust. The cost of not evolving is not just technical—it's competitive.

Signs Your DoD Needs Immediate Revision

Watch for these signals: frequent post-release bugs that could have been caught by a simple check; team members regularly skipping DoD items and justifying it; the DoD checklist is longer than 20 items; or the team cannot articulate why each item is there. If any of these apply, start the audit process within the next sprint.

Mini-FAQ: Common Objections to Evolving the Definition of Done

Q: Won't expanding the DoD slow us down?
A: In the very short term, yes—adding criteria takes time to check. But the investment pays back quickly through fewer defects, less rework, and smoother integration. Most teams find that within two sprints, the additional time is offset by reduced debugging.

Q: How do we keep consistency across multiple teams?
A: Use a shared baseline DoD that all teams must follow, then allow each team to add context-specific criteria. The baseline should cover non-negotiable items (security, accessibility, core testing). Teams can document their additions in a team charter.

Q: What if a stakeholder insists on a fixed DoD for predictability?
A: Explain that predictability comes from stable process, not a static checklist. A DoD that evolves based on feedback is more predictable in the long run because it reduces surprises. Offer to track the percentage of stories that meet the updated DoD to demonstrate consistency.

Q: Should we include sustainability and ethics items in the DoD?
A: Yes, if they are relevant to your product. For example, a web application might include 'page load time under 2 seconds on a 3G connection' (performance sustainability) or 'all user data collected has a documented consent flow' (ethics). Start with one or two items and expand as the team learns.

Q: How often should we review the DoD?
A: Quarterly reviews are a good cadence for most teams. Additionally, trigger a review after any major incident, after adding a new team member, or when adopting a new technology stack.

Recommendation: A Hybrid Model That Preserves Ethical Roots

Based on our analysis, we recommend a hybrid approach that combines the consistency of strict adherence with the adaptability of flexible adaptation, guided by ethical principles. Start with a core DoD that includes 8–10 non-negotiable items covering quality, security, accessibility, and environmental impact (e.g., energy efficiency where measurable). This core is mandatory for all stories. Then allow teams to add optional items per story based on risk and context, but require that any deviation from the core be documented and approved by a peer reviewer.

This model preserves the ethical roots of the definition—no story can be 'done' without meeting baseline sustainability and ethical criteria—while allowing the flexibility needed to avoid bureaucracy. It also creates a clear path for evolution: the core DoD should be reviewed quarterly, and items can be promoted from optional to mandatory as the team's understanding matures.

Your next step is to schedule a 90-minute workshop this week. Invite the team, bring the current DoD, and walk through the audit and draft steps outlined above. Don't aim for perfection in one session—aim for a 20% improvement. The goal is to start the evolution, not to finish it. As you adapt, remember that the definition of 'done' is not a destination; it's a compass. And a compass that never moves is useless when the landscape changes.