Definition of Done: Quality Gate

Level: Advanced Module: Scrum Artifacts and Commitments 3 min read Lesson 31 of 52

Overview

  • What you’ll learn: What the Definition of Done (DoD) is, why it is the commitment for the Increment, how to create one, examples of DoD items, and common pitfalls.
  • Prerequisites: Lesson 30 — The Increment.
  • Estimated reading time: 13 minutes

Introduction

The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product. When a PBI meets the DoD, it becomes part of the Increment. When it does not meet the DoD, it cannot be released or presented at the Sprint Review.

DoD as Commitment

The DoD is the commitment for the Increment, just as the Product Goal is the commitment for the Product Backlog and the Sprint Goal is the commitment for the Sprint Backlog. It creates transparency by providing a shared understanding of what “done” means.

Example Definition of Done

  • Code is written and follows coding standards.
  • Code is peer-reviewed (or pair-programmed).
  • All unit tests pass.
  • Integration tests pass.
  • No known critical or major bugs.
  • Documentation is updated.
  • Feature is deployed to staging environment.
  • Acceptance criteria are verified by a Developer (not the author).
  • Performance meets baseline thresholds.
  • Security scan shows no new vulnerabilities.

Who Creates the DoD?

If the organization has an organizational DoD, all Scrum Teams must follow it as a minimum. Individual teams can have a stricter DoD but never a weaker one. If no organizational DoD exists, the Scrum Team creates one appropriate for the product.

Common Pitfalls

  • “Code is written” as DoD: This is not done. Code that is written but untested, unreviewed, and undeployed is just a liability.
  • Different DoDs per team on the same product: Integration quality becomes unpredictable.
  • DoD that nobody follows: If the DoD is aspirational rather than actual, it provides false transparency.
  • DoD never updated: As the team matures, the DoD should become stricter, not remain at the starting level.

Key Takeaways

  • The DoD defines what “done” means — it is the commitment for the Increment.
  • Work that does not meet the DoD is not an Increment and cannot be released.
  • The DoD should be specific, enforceable, and actually followed.
  • Teams can have a stricter DoD than the organization, never weaker.
  • The DoD should evolve — as the team matures, quality standards should increase.

What’s Next

In Lesson 32, you will explore estimation techniques — Story Points, T-Shirt sizing, #NoEstimates, and why estimation is a conversation, not a commitment.

繁體中文

概述

  • 學習目標：完成定義（DoD）是什麼、為什麼是增量的承諾、如何建立、範例，以及常見陷阱。
  • 先決條件：第 30 課。
  • 預計閱讀時間：13 分鐘

簡介

完成定義是增量滿足產品所需品質標準時的正式描述。不符合 DoD 的 PBI 不能成為增量的一部分，不能發布或在 Sprint Review 中展示。

完成定義範例

  • 程式碼已撰寫並遵循編碼標準。
  • 程式碼已經同儕審查。
  • 所有單元測試通過。
  • 整合測試通過。
  • 無已知嚴重或重大錯誤。
  • 文件已更新。
  • 功能已部署到預備環境。
  • 驗收標準已由另一位開發者驗證。

常見陷阱

  • 「程式碼寫完」作為 DoD——未測試、未審查的程式碼只是負擔。
  • 同一產品的團隊有不同 DoD——整合品質不可預測。
  • DoD 從不更新——團隊成熟時，DoD 應該更嚴格。

重點摘要

  • DoD 定義「完成」的含義——是增量的承諾。
  • 不符合 DoD 的工作不是增量。
  • 團隊可以有比組織更嚴格的 DoD，絕不能更寬鬆。
  • DoD 應隨團隊成熟而演進。

下一步

在第 32 課中，您將探索估算技巧。

日本語

概要

  • 学習内容：完成の定義（DoD）とは何か、インクリメントのコミットメントである理由、作成方法、例、よくある落とし穴。
  • 前提条件：レッスン30。
  • 推定読了時間：13分

はじめに

完成の定義は、インクリメントがプロダクトに求められる品質基準を満たしている状態の正式な記述。DoDを満たさないPBIはインクリメントの一部にならず、リリースもスプリントレビューでの提示もできない。

完成の定義の例

  • コードが書かれ、コーディング標準に従っている。
  • ピアレビュー済み。
  • 全ユニットテスト合格。
  • 統合テスト合格。
  • 既知の重大・主要バグなし。
  • ドキュメント更新済み。
  • ステージング環境にデプロイ済み。
  • 受け入れ基準が別の開発者により検証済み。

よくある落とし穴

  • 「コードを書いた」がDoD——テストもレビューもされていないコードは負債。
  • 同一プロダクトでチームごとに異なるDoD——統合品質が予測不能に。
  • DoDが更新されない——チームの成熟に伴いDoDはより厳格になるべき。

重要ポイント

  • DoDは「完成」の意味を定義——インクリメントのコミットメント。
  • DoDを満たさない作業はインクリメントではない。
  • チームは組織より厳格なDoDを持てるが、緩くはできない。
  • DoDはチームの成熟とともに進化すべき。

次のステップ

レッスン32では、見積もり技法を探ります。

You Missed