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

2023/04/29閱讀時間約 38 分鐘

Photo by Glenn Carstens Peters on unsplash.com

在我們實踐 Scrum 的過程中，總有許多機會能接觸到 User Story ，而在觸及 User Story 時，又經常能談論到 Acceptance Criteria（AC），AC 的常見中譯名為「驗收準則」，顧名思義為「驗收某種東西的標準原則」，然而，這項名詞卻時常讓我們感到混淆，到底驗收準則或 AC 是什麼？它與 Definition of Done（DoD）的差別在哪？而我們又該如何寫出一手好 AC？

據史料記載，User Story 概念最早出現在最一開始的 Extreme programming（XP）團隊，這樣的概念一直醞釀到西元 1995 年更佳被重視，因此在當年，創造了最原始的 Wiki 與同為 Agile Manifesto 共同創造者的 Ward Cunningham 發表了《 Epidsodes 》，並在其中提到使用者導向的需求之概念，此為 User Story 的早期想法。爾後，更多有關使用者導向的需求與 User Story 的討論更明確地出現在 Kent Beck 的《 Extreme Programming Explained: Embrace Change 》這本書中。

直到今天，當我們應用 Scrum 時，大多會配合運用 User Story，這也許意味著「使用者導向的需求」的討論方式，對於整體產品開發團隊（包含前線業務行銷單位與後端技術開發團隊）之間的溝通，產生了不可忽視的重要性。或許是這項溝通語言的簡便與易用，讓兩個原本位於不同端點、甚至可能不太容易溝通的單位，產生了能輕鬆對話的空間，而導致使用率漸增。無論真正普及的原因為何，我們都不能忽略 User Story 能帶給我們的確切效用，即「促成團隊對話」。

然而，在 User Story 的應用中，仍存在許多模糊點，尤其 Scrum Guide 中只針對 Definition of Done 作重點描述，並未提到有關 User Story 的任何事項，讓我們在實務運用時，更多了一些潛在的變數，因此，我希望能透過這篇文章，以經年的實務經驗與習得的學術理論，來談談有關 AC 的幾個面向，幫助正在運用 Scrum 的團隊瞭解更多的 AC，進而能有效地將它運用在平常的工作或生活中。

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

很可惜的，如前文所述，Scrum Guide 並未針對 AC 做任何說明。然而，我們可以從相關的文獻與 Scrum Guide 中理解兩者意涵與差異。首先來看看定義：

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 應該由誰來寫？

「做產品」這件事，以產品管理的角度而言，我認為有個簡易方程式能清楚說明：

產品管理 = 假設＋驗證

即產品管理是「先設定對某種事情的假設（Assumption）」（或指，先設定目標），接著建立驗證該假設的條件，再透過執行一連串實驗，來實現假設，或捨棄假設並轉向其他假設」的一種科學化的實驗過程。

我認為，要打造出成功的產品，則要透過科學化的實驗，反覆驗證假設，以邁向成功。

這項方程式套用到 User Story 與AC 時，也具有相似的道理。（下方以需求由 User Story 撰寫的前提來說明）

User Story 的內容概念為：為了讓整體產品開發團隊，針對一個特定的、具體的需求對象或 TA ，為了他們的某些特定價值（通常為 Business Value），而產生的對話工具。而 AC 則為被開發出來的需求，能否被判斷為「完成」的驗收條件。轉換成類似的方程式則可為：

需求 = User Story + AC （註4）

意即，要確認需求是否完成，需要透過做出需求或功能，以及配合 AC 的驗收條件來驗證它，才能明確瞭解需求是否已完成。

在國外社群或知名網站上，有許多關於「誰該負責撰寫 AC 」的爭論，有些人認為應該由 Product Owner 寫，有些人則認為應該由執行任務的 Developers 撰寫，而非由 Product Owner 負責。然而，我認為這些討論似乎缺少思考「了解使用者需求」與「團隊合作」的意涵。要記得，Scrum 的價值能否體現，在於團隊能否理解和實現「團隊合作」，並在如此的團隊合作基底下，確實的了解使用者真正的需求或痛點，並產生能真正幫助使用者的解決方案。

Mike Cohn 針對 User Story 有做出詳細的研究，他在《 User Stories Applied: For Agile Software Development 》一書中提到關於 Acceptance Criteria 的概念（他在書中使用 Acceptance Testing 表述）：「One reason for writing acceptance tests is to express many of the details that result from the conversations between customers and developers…Acceptance tests also provide basic criteria that can be used to determine if a story is fully implemented.」AC 可以透過客戶與開發人員的對話產生，並且它是用來驗證 User Story 是否被完善執行或開發的準則。

我想，這點跟 Scrum 起源因素之一「Ziv’s law」想解決的問題（即規格不會被完全理解）十分相關。為了讓產品開發相關成員能充分了解面臨的議題及要完成的解決方案等，需要透過成員之間的有效對話，來讓剛所述的這些面向等，能更清晰地被產品開發團隊理解與實現。

因此，我們可以說 AC 需要由客戶、代表客戶或最了解使用者的一方（如：Product Owner）與產品開發團隊討論而成，而非單純地交給任何單一一方撰寫。在我的實務經驗上，確實也經由許多驗證，發現經由團隊相互討論、激盪而產生的 AC，更能讓團隊產生最接近或符合需求對象（或 TA）所「想要」的產品或功能，進而使其滿足。

如何寫出好的 AC ？

還記得多年前任職的某間外資公司，曾在產品剛上線的幾天內，立即砸下 250 萬新台幣讓實際使用者幫忙抓漏（註5），雖然以當時已知的公司財力，250 萬猶如九牛一毛，但對於很在乎公司營收支出、產品品質與不願意浪費（Waste）的我，實在是非常難以忘懷的一件事。

當時的那間公司在 AC 的撰寫上，出了嚴重的問題。即，沒有撰寫 AC。即便當時有數十名 QA 測試團隊成員，但在需求的撰寫上，缺少了 AC 的準備，導致測試團隊不了解該從何測試，只能自行依照各自經驗的準備各自認為的測試項目和計畫。

在 AC 的撰寫上，雖然確實沒有標準化流程或 SOP 能參考，然而，我們能試著使用 Ellen Gottesdiener 提出的《7 Product Dimensions》中的其中三個維度的面向去發想：（以下為簡易範例）

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

若對於需求對象或 TA 感到模糊，或 Persona 的定義仍然過於廣泛不具體時，也可試著參考《7 Product Dimensions》提到的三大角色 Customer、Business Partner 與 Technology partner（註6）做為思考的參考方向。

期待上述的分享，能帶給你更多有關 AC 的想法！

備註：

結案：指關單、Close 或 Done 。
任務：指需求、User Story 或 Product Backlog Item（PBI）。
對外發佈：指上線或發佈到 production environment 。
也可為：需求 = User Story （含 AC）；此處用與產品管理相同的方程式來加強說明，因此這樣描述。
抓漏：指抓蟲子、找 bug ，找出產品缺陷。
三個角色：指「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

Sometimes, we will use User Story in Scrum practices. When talking about User Story, most of the time we will talk about Acceptance Criteria (AC) as well. However, AC is not easy to understand. We easily get confused between AC and Definition of Done (DoD)? What is AC? What is the difference between AC and DoD? And, how to write a good AC?

According to historical records, the first concept of User Story appeared in the initial Extreme programming (XP) team. The concept had been made for a while, and it got more attention later on. In 1995, Ward Cunningham, who created the initial Wiki and co-writer of Agile Manifesto, published "Epidsodes" and mentioned the concept of user-oriented requirement. That was the initial idea of User Story. Later, more detailed discussions appeared in Kent Beck's book, "Extreme Programming Explained: Embrace Change".

Until now, most of the time we use User Story in Scrum. That may indicate the concept of "user-oriented requirement" become reckoned with for the overall product development process, including the communication between front line and back line (technical development teams). Perhaps it is because the “user-oriented requirement” help smoothen the communication between the two functional units, front line and back line, which originally the two units might not easy to reach a consensus. No matter what made it prevalent, we can not ignore the exact utility, facilitating conversations, that User Story brings.

However, there are still many ambiguities when applying User Story. Especially, Scrum Guide only focuses on Definition of Done but not User Story. That makes some potential uncertainties when using it. Therefore, I hope this article, with my experiences and knowledge, can help explain more about to AC and be beneficial for more Scrum teams in daily working life.

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

Unfortunately, as above mentioned, Scrum Guide doesn't explain anything related to AC. However, we can realize the meaning and difference from some relevant documentation and Scrum Guide still. First of all, let’s take a look at the definition of them:

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.

In addition, the thinking point of them is different:

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?

In my point of view, there is a simple formula that can clearly explain “what is product management”:

Product management = Hypothesis + Validation

Product management is, "make an assumption (or a goal), then establish some conditions to validate the assumption, and then implement a series of experiments to check it until achieve the goal, or just abandon the assumption and move forward".Product management is just a scientific experimental process.

I believe, it is necessary to repeatedly implement the experiments in order to make a successful product or products.

We can see some similarities on User Story, AC and the above-mentioned simple formula. (Below take User Story for example)

The concept of User Story is, “it is a tool for facilitating communication when in the overall product development process by writing as a story and focusing on a specific TA and value (normally it is Business Value). AC is the acceptance condition of the developed outcome. If put it as a simple formula, it can be:

Requirements = User Story + AC (Note 1)

That is, AC is used to confirm whether the requirement is completed. It is necessary to validate requirement with AC. If we pass it, we can say the requirement is done.

There are many debates about "who should take the responsibility to write the AC" everywhere. Some people think it should be written by the Product Owner, but some believe Developers should take the responsibility. However, I think we should think more about "TA’s /user needs" and "teamwork". Remember, the value of Scrum is always relevant to the outcome the team produces. If we have a solid team work, we know exactly what user/TA wants, and we also provide a solution that can satisfy our user, then we can bring a higher value.

Mike Cohn explained User Story explicitly in his book, "User Stories Applied: For Agile Software Development". (However, he used “Acceptance Testing” to express AC in the book if I am not misunderstanding). He mentioned, "One reason for writing Acceptance tests are to express many of the details that result from the conversations between customers and developers…Acceptance tests also provide basic criteria that can be used to determine if a story is fully implemented.” AC can facilitate the conversations between customers and developers, and it is the criteria for validating whether the User Story is well developed.

In my point of view, it is related to the "Ziv's law", one of reasons of designing Scrum. Ziv’s law is, “specifications will never be fully understood”. In order for having the product development team fully understand the issues they are facing and the scope of the solution, it is necessary to have effective conversations among them. With those conversations, the team can know clearly why they need to do and what to do.

So, AC needs to be defined by customer, customer proxy or the person who knows the customer most (e.g. Product Owner), but not simply asking someone to finish. In my experience, it is truly helpful to have AC that is through communications between stakeholders and the team. It helps the team to provide a product that satisfies user/TA.

How to write a good AC ?

An unforgettable thing happened several years ago. One of my previous company which spent NT$2.5 million immediately after the product launch, in order to “ask” actual users to find defects. (The company did announce it on the product bullet board.) I do care about “Waste” so much that I can’t forget this thing that really shocked me.

The problem of the company was there was no Acceptance Criteria for each requirement. Even if there were several QA teams, they still can’t find a way to verify the product. They did not know how to verify and what should they do. They simply test it by personal experience. So the product was launched with lots of defects, and also the company needed to ask users to find those defects for it.

We don’t have any SOP to write AC, however, we might be able to try it with 7 Product Dimensions designed by Ellen Gottesdiener. We can think about some dimensions of it:

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.?

If you are confused with TA/user or do not know how to use Persona, you can also try the three roles, Customer, Business Partner and Technology partner (Note 2), mentioned in the "7 Product Dimensions".

Hope this article can inspire you more!

Note:

It can also be “Requirement = User Story, including Acceptance Criteria.
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.”