Entry criteria là gì

Tiếp theo series #ThuatnguBA, tuần này “Chuyện của BA” xin chia sẻ về “Acceptance Criteria [AC]” – một phần rất rất quan trọng của User Story [Xem bài giải thích về User Story tại đây].

Acceptance Criteria là gì?

Là danh sách các điều kiện phần mềm cần đáp ứng, chứng minh tính năng sản phẩm hoàn thiện theo đúng mong muốn của User trong User Story.

Ai tạo ra Acceptance Criteria?

Nếu Product Owner hiểu về Software Development và cách viết acceptance criteria: Product Owner sẽ là người viết chính.

Nếu khách hàng không quen viết, họ sẽ giao lại cho một người có khả năng biết như Requirement Analyst, Business Analyst, người đóng vài trò proxy PO hay một Scrum member thích hợp.

Sau đó Developer + QA review để xem đủ tài liệu chưa, có điểm nào về mặt kỹ thuật không thể đáp ứng hay thấy mơ hồ không, và cùng chỉnh sửa bổ sung. Nhìn chung, cả Scrum Team sẽ tham gia hoàn thiện US và AC.

Lợi ích của Acceptance Criteria?

1. Giới hạn tính năng sẽ được phát triển
2. Giúp Dev chia đầu việc & tính độ khó
3. Giúp QA/QC lên test case
4. Biên bản thoả thuận giữa Product Owner & Scrum Team về tính năng mới cho sản phẩm vào cuối sprint

Khi nào Acceptance Criteria cần sẵn sàng?

✅ Khi Client / PO và team đã thống nhất sẽ làm gì trong US
✅ Trước khi sprint bắt đầu
💣⚠️🧨 Trước khi Dev bắt đầu code!!!  [Không có là ăn chửi ráng chịu nha]

Cách viết User Story – Cách viết Acceptance Criteria đơn giản nhất

• Nên viết theo kiểu “ai đọc cũng hiểu”[plain Vietnamese or plain English]
• Không đặc tả kỹ thuật trong AC
• Tách biệt AC với Test Scenarios / Technical Spec
• Kèm mockup, biểu đồ, bảng minh hoạ [nếu có]

Khi bạn nghiên cứu, bạn sẽ thấy có hai cách viết AC là “rule-based acceptance criteria” và “scenario-based [Given, then, when] acceptance criteria” và có thể không biết nên dùng cái nào khi nào, trong bài viết này, tụi mình chia sẻ cách viết AC / US rất đơn giản, kết hợp hai phương thức trên

Cấu trúc User Story hoàn thiện

1. Title [Tiêu đề ngắn]
2. Description [Mô tả As a …, I want …, So that …]
3. Acceptance Criteria
4. Test Scenarios [Given, Then, When]
5. Attached Media [File đính kèm]

Ví dụ mẫu: Thanh toán bằng Airpay cho đơn đặt hàng Now.vn

1. Title: Thanh toán bằng Airpay
2. Description: Là người dùng Now, tôi muốn thanh toán bằng Airpay để thanh toán nhanh chóng mà không cần dùng tiền mặt.
3. Acceptance Criteria:
   • Khi xác nhận đặt món, tôi có thể chọn thanh toán bằng Airpay
   • Tôi có thể thanh toán bằng Airpay nếu tôi nhập đúng passcode và tài khoản Airpay liên kết của tôi có đủ tiền
   • Nếu có vấn đề về thanh toán, tôi cần biết lý do và cách giải quyết
   • Tôi có thể huỷ thanh toán bằng Airpay
4. Test Scenarios:
   1. 1. Scenario 1: Tài khoản liên kết Airpay có đủ tiền
         • Given tài khoản airpay = 150.000
         • And tài khoản airpay đã liên kết với tài khoản Now
         • And đơn hàng trị giá 150.000
         • When chủ tài khoản quyết định “Thanh toán bằng Airpay”
         • Then hệ thống yêu cầu nhập Airpay passcode
         • And hệ thống thông báo cho người dùng số dư không đủ thanh toán
         • And hệ thống hiển thị trạng thái “chờ thanh toán lại”
         • And hệ thống cho phép người dùng
           1. Huỷ đơn hàng
           2. Chọn phương thức thanh toán lại bằng airpay
           3. Đổi phương thức thanh toán …
5. File đính kèm
   • • UI mockup, design
     • Email, comment trao đổi giữa các bên về yêu cầu
     • Nội dung các thông báo sẽ hiển thị lên màn hình

Mình cũng khuyến khích bạn mới, chưa quen viết AC nên theo cấu trúc trên vì

✅ AC sẽ rất đơn giản, theo dạng checklist, PO/ end user muốn cái gì viết vào cái đó.
✅ AC cần được viết theo ngôn ngữ người dùng, vì nó là phần thoả thuận yêu cầu giữa Client / PO và Scrum team.

Thường PO hay stakeholder không phải là dân kỹ thuật và họ cũng không muốn phải đọc một cái sớ đặc tả màn hình hay hành vi của hệ thống.

👉 Vì vậy, các trường hợp cần kiểm thử cụ thể phần đặc tả hệ thống nên được để tách biệt so với AC của người dùng.
👉 Cấu trúc trên phù hợp cho cả team product và team outsourcing.

Thế thôi nhỉ 😉 Nếu bạn thấy hữu ích, hãy lưu lại hoặc chia sẻ cho bạn bè đồng nghiệp của mình nhé.

Các bạn hãy theo dõi các kênh chia sẻ về nghề BA, PO của Khang & Mia

Cám ơn các bạn!

– Mia