幫助 Scrum Team 更了解Acceptance Criteria（AC）的一篇文

AC 是什麼？它與 Definition of Done（DoD）的差別在哪？

• Acceptance Criteria（AC）：簡單來講，AC 是需求的驗收標準，也就是 User Story 或 Product Backlog Item（PBI）能否結案（註1）的條件。當任務（註2）被做出來並同時符合 AC 列出的要求時，才能算完成任務。需要考量需求對象或目標族群（Target Audience，TA）的「想要」來判斷，並且每一項需求，都會有各自的 AC。
• Definition of Done（DoD）：DoD 是每次 Sprint 產出的成果（即 Increment），於對外發佈（註3）前要滿足的品質標準。Scrum Guide 提到 DoD 是「…a formal description of the state of the Increment when it meets the quality measures required for the product…If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration.」指出 DoD 即為 Increment 能否被發佈到市場的先決條件。

• Acceptance Criteria（AC）：由於 AC 是緊附著於需求，因此考量的出發點在於「 TA 」，因此在撰寫 AC 時的出發點，要著重在 TA 的「需求/想要」。因此，由於需求的不同（須符合 INVEST 原則），因此每一項需求都產生獨一無二的 AC 條件。
• Definition of Done（DoD）：而 DoD 則與對外發佈有緊密連結，因此思考的方向，要從「組織、公司」或「產品」的角度來思考。它能是整個組織中，所有團隊共同遵守的品質原則（即共享同一份 DoD 清單），也能成為團隊針對共同處理的產品之共同的品質標準，我們可參閱 Scrum Guide 窺探更多：「…If the Definition of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum. If it is not an organizational standard, the Scrum Team must create a Definition of Done appropriate for the product. The Developers are required to conform to the Definition of Done. If there are multiple Scrum Teams working together on a product, they must mutually define and comply with the same Definition of Done.」

AC 應該由誰來寫？

如何寫出好的 AC ？

• Control 維度：使用產品或功能上，可沒有哪些規則或限制？他們對於這些規則的想法可能為何？不遵守規則時，會出現哪些風險？是否警示違規？（如：欄位的 error handling）
• Environment 維度：偏好在哪裡使用產品或功能？要怎麼安裝、使用、…等？是否要符合某些技術標準？（如：某些功能僅適合手機上使用）
• Quality Attribute 維度：操作方面是否符合可用性（availability）、易用性（usability）、互通性（interoperability）、資訊安全（security）、 安全性（safety）等等？開發方面是否有彈性（flexibility）、可修改性（modifiability）、可移植性（portability）、再利用性（reusability）等等？

1. 結案：指關單、Close 或 Done 。
2. 任務：指需求、User Story 或 Product Backlog Item（PBI）。
3. 對外發佈：指上線或發佈到 production environment 。
4. 也可為：需求 = User Story （含 AC）；此處用與產品管理相同的方程式來加強說明，因此這樣描述。
5. 抓漏：指抓蟲子、找 bug ，找出產品缺陷。
6. 三個角色：指「A customer is most likely looking to solve a particular problem or leverage an opportunity that could be provided by the product. A business partner might be more focused on the market, revenue, or competitive position. Finally, technology partners are usually invested in building around quality, performance or scalability and similar quality attributes.」

A better understanding of Acceptance Criteria/AC

What is Acceptance Criteria? What is the difference between Definition of Done (DoD) and Acceptance Criteria (AC)?

• Acceptance Criteria (AC): In short, AC is the acceptance criteria of a requirement. That is, the conditions for finishing a User Story or Product Backlog Item (PBI). When the User Story or PBI meets the AC listed with it, it can be considered as “completed”. AC should made by user needs, that is we will need to think more about “what user wants” (we can call “user” as “Target Audience or TA” in the following content), and each requirement will have its own AC.
• Definition of Done (DoD): DoD is the quality standards for the increment. It is related to the production release. Scrum Guide mentions DoD is "...a formal description of the state of the Increment when it meets the quality measures required for the product...If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration.” That points out DoD is one of the conditions to determine if each Increment can be released to public.

• Acceptance Criteria (AC): Since AC is listed in a requirement (User Story or PBI), the thinking point is "TA". We need to consider more related to the “needs or want” of the TA. Besides, each requirement is unique (and it is necessary to fit the INVEST principle before starting), and AC of it is unique too.
• Definition of Done (DoD): DoD is closely related to public release, so the thinking point should be related to the needs of "an organization/company" or "a product". It can be a quality principle shared by all teams in the entire organization (that is, they share the same DoD list), and it can also become a shared product quality standard. Refer to Scrum Guide, "...If The Definition of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum. If it is not an organizational standard, the Scrum Team must create a Definition of Done appropriate for the product. The Developers are required to conform to the Definition of Done. If there are multiple Scrum Teams working together on a product, they must mutually define and comply with the same Definition of Done.”

Who should write the Acceptance Criteria?

How to write a good AC ?

• Control dimension: Are there any rule or restriction? What will user/TA think about the rule or restriction? Is there any risk happened when we ignore them? Is there a violation alert? (eg: error handling)
• Environment dimension: Where will TA/user use the product? How to install, use, ... etc.? It there any technical standard? (For example: some functions are only available on certain mobile phones)
• Quality Attribute dimension: How is the availability, usability, interoperability, security, safety, flexibility, modifiability, portability, reusability and etc.?

1. It can also be “Requirement = User Story, including Acceptance Criteria.
2. The three roles are, “A customer is most likely looking to solve a particular problem or leverage an opportunity that could be provided by the product. A business partner might be more focused on the market, revenue, or competitive position. Finally, technology partners are usually invested in building around quality, performance or scalability and similar quality attributes.”