Part 010 — DoD for Features, Bugs, Migrations, APIs, Events, and Infrastructure

Positioning

Definition of Done adalah commitment terhadap Increment.

Ia menciptakan shared understanding mengenai kualitas minimum yang harus dipenuhi agar work dianggap selesai.

Tanpa DoD yang nyata, team dapat menggunakan kata “Done” untuk kondisi berbeda:

• coding complete;
• review complete;
• test complete;
• integrated;
• deployable;
• released;
• atau operationally accepted.

Core thesis: Done bukan status administratif. Done adalah evidence bahwa perubahan telah terintegrasi dan memenuhi standar kualitas yang dibutuhkan agar Increment dapat digunakan secara aman.

1. Definition of Done in Scrum

Definition of Done memberikan transparency terhadap kondisi Increment.

Ketika sebuah Product Backlog Item memenuhi DoD:

• ia menjadi bagian dari Increment;
• kualitas minimum dipenuhi;
• dan kondisi item dapat dipahami bersama.

Item yang belum memenuhi DoD tidak boleh dianggap Done.

2. Done versus Coding Complete

Coding complete

Implementation utama ditulis.

Done

Perubahan telah memenuhi seluruh standar yang relevan, seperti:

• review;
• test;
• integration;
• security;
• documentation;
• observability;
• and release safety.

Coding complete adalah intermediate state.

3. Done versus Deployed versus Released

Done

Meets the Definition of Done.

Deployed

Artifact exists in an environment.

Released

Capability is exposed to intended users.

A team may produce a Done Increment before release.

Internal release policy must be verified.

4. Done versus Operationally Accepted

Operational acceptance may include:

• monitoring;
• runbook;
• support handoff;
• alert ownership;
• and recovery validation.

For production-critical work, these should often be part of Done, not a later afterthought.

5. Why a Shared DoD Matters

A shared DoD reduces:

• hidden work;
• quality negotiation per story;
• downstream handoff;
• false completion;
• and release surprises.

It also supports:

• forecasting;
• trust;
• and consistent review.

6. DoD as a Quality Floor

DoD is a minimum standard.

It is not:

• the maximum quality possible;
• a guarantee of zero defects;
• or a substitute for risk-based acceptance.

High-risk work may need additional criteria.

7. Organizational versus Team DoD

If organization has standards, teams must follow at least those standards.

The team may add stricter criteria.

Avoid conflicting definitions across teams working on one product.

8. DoD Dimensions

A practical DoD may cover:

1. Functional correctness.
2. Code quality.
3. Review.
4. Automated tests.
5. Integration.
6. Security.
7. Performance where relevant.
8. Compatibility.
9. Data and migration.
10. Documentation.
11. Observability.
12. Deployment.
13. Recovery.
14. Support readiness.
15. Product acceptance evidence.

9. Functional Correctness

Evidence may include:

• acceptance examples;
• automated tests;
• exploratory test;
• and domain-invariant checks.

“Works on my machine” is insufficient.

10. Code Quality

Possible standards:

• follows team conventions;
• no unresolved critical static-analysis issue;
• understandable naming;
• appropriate complexity;
• and no hidden debug artifacts.

Avoid using DoD for subjective stylistic preference.

11. Peer Review

Review should verify:

• behavior;
• risk;
• maintainability;
• security;
• and system impact.

A checkbox approval without meaningful inspection weakens DoD.

12. Automated Tests

DoD may require:

• unit;
• contract;
• integration;
• and end-to-end tests

depending on risk.

Do not require every test layer for every change.

13. Test Evidence

State what is proven.

Weak:

Tests pass.

Stronger:

Contract tests confirm old and new consumer payload compatibility; retry test confirms one downstream side effect per idempotency key.

14. Integration

A change is not Done if it remains isolated from the real boundary it must support.

Integration may include:

• database;
• service;
• event;
• environment;
• or user interface.

Mocks alone may not prove production interaction.

15. Continuous Integration

DoD often assumes:

• code merged;
• main branch green;
• and build artifact produced.

Long-lived unintegrated branches create false completion.

16. Security

Contextual security evidence may include:

• authorization;
• tenant isolation;
• input validation;
• secret handling;
• dependency scan;
• and threat review.

Security is not a final external gate only.

17. Data Integrity

For stateful work, verify:

• invariants;
• transaction behavior;
• concurrency;
• and correction path.

A code change may be correct while existing data remains wrong.

18. Compatibility

Compatibility may include:

• API;
• event;
• schema;
• configuration;
• and behavior.

Syntactic compatibility does not guarantee semantic compatibility.

19. Performance

Performance checks should be risk-based.

Possible evidence:

• baseline;
• representative workload;
• target percentile;
• and saturation behavior.

Avoid universal performance testing without a decision need.

20. Documentation

Documentation may include:

• public contract;
• user guide;
• operator guide;
• architecture decision;
• release note;
• and code rationale.

DoD should specify relevant documentation, not “all docs updated” vaguely.

21. Observability

For material production behavior, include:

• logs;
• metrics;
• traces;
• correlation;
• and alertability.

Observability is not merely adding more logs.

22. Operability

Ask:

• Can support identify failure?
• Can operations validate health?
• Is owner known?
• Is recovery possible?
• Is manual action safe?

23. Deployment Readiness

Possible criteria:

• artifact immutable;
• configuration known;
• deployment automated;
• health checks available;
• environment variables documented;
• and rollout owner identified.

24. Rollback and Roll-Forward

High-risk work should define:

• rollback;
• roll-forward;
• containment;
• or compensation.

Rollback may not be possible for destructive data change.

25. Support Readiness

Support may need:

• known behavior;
• diagnostic fields;
• workaround;
• escalation path;
• and customer communication.

26. Release Note Readiness

Release notes should communicate:

• user-visible change;
• compatibility;
• migration;
• configuration;
• and known limitation.

Not every internal refactor needs customer-facing release notes.

27. Feature DoD

A feature DoD may include:

• acceptance behavior;
• automated tests;
• integration;
• review;
• observability;
• documentation;
• rollout;
• and stakeholder evidence.

28. Bug Fix DoD

A bug fix should prove:

• original failure reproduced;
• fix prevents recurrence;
• regression coverage exists;
• affected scope understood;
• and production/data validation is planned.

29. Hotfix DoD

Hotfix has compressed lead time, not absent controls.

Minimum may include:

• focused review;
• reproduction test;
• regression check;
• rollback;
• production validation;
• and follow-up work.

30. Migration DoD

Migration DoD may require:

• source and target validated;
• dry run;
• mismatch report;
• pilot;
• reconciliation;
• rollback or containment;
• and decommission criteria.

Running the migration script is not the end.

31. API Change DoD

Possible criteria:

• contract updated;
• compatibility checked;
• authentication/authorization verified;
• examples;
• error semantics;
• generated clients where applicable;
• contract tests;
• and deprecation notes.

32. Event Change DoD

Possible criteria:

• schema/version;
• consumer inventory;
• compatibility;
• duplicate/order behavior;
• replay;
• rollout;
• and monitoring.

33. Infrastructure Change DoD

Possible criteria:

• infrastructure code reviewed;
• plan inspected;
• policy checks pass;
• security implications reviewed;
• rollback or replacement path;
• monitoring;
• and ownership.

34. Configuration Change DoD

Configuration can be production code in effect.

Verify:

• environment scope;
• defaults;
• validation;
• secret safety;
• rollback;
• and audit trail.

35. Platform Capability DoD

A platform capability is not complete only because infrastructure exists.

Include:

• internal consumer;
• documentation;
• self-service path;
• support model;
• and adoption evidence.

36. Technical Debt DoD

Debt-remediation evidence may include:

• duplicated path removed;
• tests preserve behavior;
• old interface decommissioned;
• and recurring cost reduced.

Refactoring without removing the old path may not complete the outcome.

37. Spike Done Criteria

A spike produces:

• evidence;
• decision;
• recommendation;
• and remaining uncertainty.

Production code may be disposable.

38. Documentation Work DoD

Documentation work should include:

• target audience;
• verified steps;
• owner;
• and discoverable location.

A document no one can find is not operationally useful.

39. Release Readiness

Release readiness asks whether a Done Increment can be exposed safely.

It may include:

• target scope;
• rollout;
• customer readiness;
• support;
• monitoring;
• and business approval.

40. Done but Not Released

Reasons may include:

• release window;
• feature flag;
• customer timing;
• or bundled commercial launch.

This is acceptable if:

• Increment is truly Done;
• and unreleased work remains controlled.

41. Release Gate

A release gate should protect a material risk.

Possible gates:

• security;
• migration approval;
• customer acceptance;
• or operational readiness.

Avoid gates that exist only because “we always do it”.

42. Release Readiness Checklist

## Scope

- [ ] Exact release contents known.
- [ ] Feature flags and tenant exposure defined.

## Evidence

- [ ] DoD met.
- [ ] Production-like validation complete.
- [ ] Known risks documented.

## Operations

- [ ] Monitoring and alerts ready.
- [ ] Support and runbook ready.
- [ ] Rollback/containment prepared.

## Communication

- [ ] Release notes prepared.
- [ ] Customer/internal communication owner known.

## Decision

- [ ] Go/no-go authority clear.

43. Operational Readiness

Operational readiness asks whether the organization can:

• observe;
• support;
• recover;
• and sustain the change.

44. Operational Readiness Review

A review may cover:

• service ownership;
• SLI/SLO impact;
• alerts;
• capacity;
• runbook;
• on-call;
• security;
• and dependency behavior.

Use proportional depth.

45. Production Readiness Checklist Risk

A giant universal checklist creates:

• low-quality checkbox behavior;
• and ignored fields.

Use:

• baseline standards;
• plus contextual risk sections.

46. Evidence over Checkbox

Weak:

• Monitoring complete.

Strong:

• Dashboard shows success/error rate by tenant; synthetic check triggers alert; on-call runbook links to correlation query.

47. Definition of Done Ownership

Developers are accountable for creating a usable Increment.

DoD should be:

• shared;
• visible;
• and consistently applied.

It should not be owned solely by QA.

48. Product Owner and DoD

Product Owner cannot unilaterally waive DoD to mark work complete.

Scope can change.

Quality floor should remain transparent.

49. Scrum Master and DoD

Scrum Master can help:

• make DoD transparent;
• inspect process;
• and address organizational impediments.

They do not act as quality approver.

50. QA and DoD

QA expertise can shape:

• test strategy;
• evidence;
• and risk.

Quality remains cross-functional.

51. Operations and Support Contribution

Operations and support help define:

• observability;
• recovery;
• and support readiness.

Involving them only before release creates late surprises.

52. Security Contribution

Security should provide:

• guardrails;
• tooling;
• and specialist review for material risk.

Avoid making all work wait for manual approval.

53. DoD Evolution

DoD should improve as team learns.

Inputs:

• incidents;
• escaped defects;
• support pain;
• and new platform capability.

Do not change DoD casually every Sprint.

54. Raising the DoD

A safe progression:

1. identify recurring gap;
2. gather evidence;
3. define standard;
4. enable team;
5. automate;
6. adopt;
7. review effectiveness.

55. DoD and Technical Debt

If current codebase cannot meet a desired standard immediately:

• define current DoD honestly;
• create remediation plan;
• and avoid pretending the new standard is already met.

56. DoD Exception

An exception should be rare and explicit.

Record:

• unmet criterion;
• reason;
• risk;
• mitigation;
• owner;
• and deadline.

The item may not be technically Done under the normal DoD.

Do not relabel incompleteness silently.

57. Emergency Exception

During an incident, a temporary exception may be necessary.

Follow-up should restore:

• tests;
• documentation;
• and permanent controls.

58. Quality Debt Register

Track deferred quality work:

Avoid indefinite “later”.

59. DoD and Sprint Planning

Planning should account for all work needed to meet DoD.

Do not estimate implementation only.

60. DoD and Daily Scrum

Inspect whether items are approaching Done, not only coding completion.

Questions:

• What remains for integration?
• What validation is waiting?
• What operational evidence is missing?

61. DoD and Sprint Review

Only work meeting DoD belongs in the Increment.

Partial work can be discussed honestly, but should not be presented as complete value.

62. DoD and Retrospective

Retrospective may inspect:

• which criteria are repeatedly delayed;
• which are unclear;
• and what can be automated.

63. Done Status Model

Possible workflow:

In Development
-> In Review
-> Integrated
-> Validating
-> Releasable
-> Done

Avoid excessive states if they do not support decisions.

64. Status versus Truth

Board status must match actual evidence.

Moving an item to Done for reporting does not create a Done Increment.

65. Partial Completion

Partial work may include:

• design;
• code;
• tests;
• or disabled implementation.

Keep it transparent.

Do not count it as Done if the DoD is unmet.

66. Carry-Over

Carry-over may expose:

• late validation;
• hidden DoD work;
• dependency;
• and oversized items.

Do not split incomplete work solely to protect completion metrics.

67. Release versus Sprint Boundary

A Sprint should produce a usable Increment.

Release cadence may differ.

Do not allow release governance to justify permanently unintegrated Sprint output.

68. Multi-Team DoD

When multiple teams contribute to one product:

• shared integration standards;
• compatibility;
• and overall Increment quality

must be clear.

Local Done that creates system-level incomplete work is insufficient.

69. Component Done versus Product Done

A component can be complete locally but not integrated into product outcome.

Use explicit terminology.

70. DoD Metrics

Possible signals:

• time from code complete to Done;
• incomplete-work age;
• escaped defects;
• hotfix frequency;
• and exception count.

Do not turn DoD into individual performance metrics.

71. Time to Done

A long gap from “development complete” to Done may reveal:

• review queue;
• test environment;
• release dependency;
• or phase handoff.

72. DoD Exception Trend

Frequent exceptions indicate:

• unrealistic standard;
• insufficient capability;
• or pressure overriding quality.

Inspect the system.

73. Escaped Defects and DoD

Escaped defects do not always mean DoD is weak.

Possible causes:

• missing scenario;
• incorrect evidence;
• environment gap;
• or unavoidable uncertainty.

Use incident learning to adapt intelligently.

74. Definition of Done Anti-Patterns

DoD as QA checklist

Quality externalized.

DoD hidden in wiki

Not used.

DoD changed per deadline

No real standard.

Coding complete equals Done

Hidden work.

Integration later

No usable Increment.

Release equals Done

Can delay feedback unnecessarily.

Checklist without evidence

Theater.

Universal oversized DoD

Low adoption.

75. Release Anti-Patterns

Big-bang release

Large batch and risk.

Unknown release contents

Weak traceability.

No rollback

Unsafe.

Monitoring after release

Detection gap.

Support surprised

Operational handoff failure.

Feature flags never removed

Permanent complexity.

76. Operational Readiness Anti-Patterns

Logs only

No actionable signal.

Runbook written but untested

False confidence.

On-call owner unknown

Slow response.

Customer discovers first

Detection weakness.

Manual recovery undocumented

Hero dependency.

77. Senior Engineer Operating Model

Define standards collaboratively

• use incidents and recurring pain as evidence.

Apply risk-based depth

• do not overprocess trivial changes.

Include delivery and operations

• code is only one part of Done.

Automate

• remove repetitive human checks.

Resist silent exceptions

• make risk visible.

Teach the rationale

• avoid personal quality gate.

Distribute ownership

• enable others to validate Done.

78. Worked Example: One-Level Approval Feature

DoD evidence

• approval rule examples pass;
• state transitions tested;
• authorization verified;
• event contract compatible;
• audit visible;
• test tenant validated;
• dashboard shows approval failures;
• rollout flag configured;
• support note updated.

79. Worked Example: Duplicate Order Bug

Bug DoD

• original timeout/retry reproduced;
• idempotency fix tested;
• downstream duplicate prevented;
• affected records reconciled;
• alert available;
• production validation defined;
• post-incident follow-up tracked.

80. Worked Example: Approval Metadata Migration

Migration DoD

• dry run complete;
• mismatch rate zero or accepted;
• pilot cohort migrated;
• reconciliation report verified;
• rollback/containment tested;
• old field decommission plan exists.

81. Worked Example: Event Change

Event DoD

• schema additive;
• legacy consumers replay-tested;
• producer flag off by default;
• trace includes version;
• rollout sequence defined;
• deprecation documented.

82. Worked Example: Infrastructure Change

Change

New namespace and deployment template.

DoD

• infrastructure plan reviewed;
• policy checks pass;
• sample service deployed;
• health check works;
• rollback/recreate tested;
• internal consumer documentation available.

83. Definition of Done Template

## Functional

- [ ] Acceptance behavior validated.
- [ ] Material negative scenarios validated.

## Engineering

- [ ] Review complete.
- [ ] Automated tests pass.
- [ ] Change integrated.

## Risk

- [ ] Security/data/compatibility requirements met.
- [ ] Migration evidence complete where relevant.

## Operations

- [ ] Observability available.
- [ ] Rollback, recovery, or containment defined.
- [ ] Support/runbook updated where relevant.

## Release

- [ ] Configuration and rollout known.
- [ ] Documentation and release notes updated where relevant.

84. DoD Tailoring Table

85. Release Readiness Template

## Release Scope

## Customer/Tenant Exposure

## DoD Evidence

## Known Risks

## Feature Flags

## Deployment Order

## Monitoring

## Rollback / Roll-Forward / Containment

## Support and Communication

## Go/No-Go Owner

86. Operational Readiness Template

## Service Ownership

## Critical User Journey

## SLI / Health Signal

## Alerts

## Diagnostic Path

## Runbook

## Capacity and Limits

## Dependency Failure

## Recovery

## Escalation

87. DoD Review Checklist

• Is every criterion understandable?
• Is it applied consistently?
• Is it evidence-based?
• Is it automated where possible?
• Does it include integration?
• Does it include operations where relevant?
• Are exceptions visible?
• Is it reviewed after incidents?

88. Process Smells

• items move to Done before merge;
• validation occurs next Sprint;
• many release exceptions;
• runbooks appear after incidents;
• API changes lack consumer evidence;
• migrations lack reconciliation;
• and support learns from customers.

89. Internal Verification Checklist

Definition of Done

• Is there a formal DoD?
• Is it team or organizational?
• Where is it visible?
• Who can change it?
• Which criteria are frequently missed?

Quality gates

• What PR and CI checks are mandatory?
• Is QA a gate or collaborator?
• What security checks exist?
• What requires specialist approval?

Release

• Is Done distinct from deployed and released?
• Who owns go/no-go?
• Are feature flags standard?
• What rollback evidence is required?
• How are release notes handled?

Operations

• What observability is mandatory?
• Are runbooks required?
• Who owns on-call?
• How are support handoffs performed?
• What data-recovery process exists?

Work types

• Are there different standards for bug, migration, API, event, and infrastructure?
• How are spikes closed?
• How are DoD exceptions tracked?
• Are old flags and compatibility paths removed?

90. Practical Exercises

Exercise 1 — Status audit

Classify current work as coding complete, integrated, releasable, released, or Done.

Exercise 2 — DoD rewrite

Turn a vague team checklist into evidence-based criteria.

Exercise 3 — Work-type tailoring

Create DoD additions for bug, API, event, migration, and infrastructure.

Exercise 4 — Release readiness

Build a go/no-go checklist for a pilot rollout.

Exercise 5 — Exception analysis

Review one quality exception and design prevention or enablement.

Exercise 6 — Operational readiness

Create an SLI, alert, runbook, and recovery path for one critical workflow.

91. Part Completion Checklist

You are done if you can:

• explain Definition of Done as a Scrum commitment;
• distinguish coding complete, Done, deployed, and released;
• create evidence-based standards;
• tailor evidence by work type;
• include integration and operations;
• manage exceptions transparently;
• assess release readiness;
• and evolve DoD without creating bureaucracy.

92. Key Takeaways

1. Definition of Done creates transparency.
2. Coding complete is not Done.
3. Done and released may differ.
4. Integration is part of real completion.
5. Operational evidence belongs in quality.
6. Work types need contextual evidence.
7. Hotfixes still require controls.
8. Exceptions must remain visible.
9. Automation scales quality standards.
10. Internal DoD and release policies must be verified.

93. References

Conceptual baseline:

• The Scrum Guide for Definition of Done and Increment.
• General continuous integration, release readiness, operational readiness, security, migration, and production-quality practices.

These concepts do not describe internal CSG processes.