Một trong những thách thức kinh điển mà các Product Owner thường đối mặt là những user story được định nghĩa một cách mơ hồ, đặc biệt là khi thiếu đi các acceptance criteria (tiêu chí chấp nhận) rõ ràng. Sự mơ hồ này dẫn đến những hiểu lầm giữa đội ngũ phát triển, các bên liên quan (stakeholder), và chính Product Owner, gây ra lãng phí công sức, phải làm lại sản phẩm, và cuối cùng là một sản phẩm có thể không đáp ứng được nhu cầu thực sự của người dùng.
Hãy coi acceptance criteria như một bản hợp đồng giữa tầm nhìn của Product Owner và quá trình thực thi của đội ngũ phát triển. Khi không có một bản hợp đồng rõ ràng, mỗi bên sẽ tự diễn giải theo cách của mình, dẫn đến xung đột tiềm tàng và những kỳ vọng không tương xứng.
Gốc rễ của vấn đề thường nằm ở việc thiếu một cách tiếp cận có cấu trúc để định nghĩa xem “hoàn thành” thực sự có ý nghĩa là gì đối với một user story.
Để giải quyết vấn đề này, có nhiều giải pháp được đưa ra: tổ chức các buổi workshop để cùng nhau định nghĩa tiêu chí, sử dụng các mẫu có sẵn với các loại tiêu chí được xác định trước (ví dụ: chức năng, hiệu năng, bảo mật), hay áp dụng một khuôn khổ như định dạng Given-When-Then của Behavior-Driven Development. Tuy nhiên, việc áp dụng các kỹ thuật này một cách máy móc có thể không đủ nếu thiếu một nguyên tắc dẫn đường.
Và đây là lúc INVEST bước vào. Dù theo truyền thống được gắn liền với việc đánh giá bản thân các user story, INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable – Độc lập, Thương lượng được, Có giá trị, Ước tính được, Nhỏ, Kiểm thử được) cũng cung cấp một lăng kính tuyệt vời để đánh giá chính các acceptance criteria. Hãy tập trung vào khía cạnh ‘Testable’ (Kiểm thử được). Để các acceptance criteria trở nên hiệu quả, chúng bắt buộc phải có thể kiểm thử. Một tiêu chí có thể kiểm thử sẽ không để lại chỗ cho sự diễn giải chủ quan. Nếu bạn không thể kiểm thử nó, bạn không thể khách quan nói rằng nó đã hoàn thành.
Để áp dụng khía cạnh ‘Testable’ của INVEST cho các acceptance criteria, hãy đảm bảo mỗi tiêu chí bao gồm: một hành động hoặc điều kiện rõ ràng, một kết quả có thể đo lường được, và một phương pháp xác minh đã được định nghĩa. Hãy tránh các thuật ngữ mơ hồ như “thân thiện với người dùng” hay “hiệu quả”. Thay vào đó, hãy sử dụng các chỉ số cụ thể, có thể định lượng.
Ví dụ, thay vì nói “Trang nên tải nhanh”, hãy viết “Trang phải tải xong trong dưới 3 giây trên kết nối 4G tiêu chuẩn, được xác minh bằng công cụ WebPageTest.”
Hãy hình dung một đội ngũ phát triển phần mềm đang xây dựng một nền tảng thương mại điện tử mới để thấy rõ hơn. Một user story được đưa ra: “Là một khách hàng, tôi muốn có thể thêm các sản phẩm vào giỏ hàng của mình để tôi có thể mua nhiều sản phẩm cùng một lúc.” Ban đầu, các acceptance criteria rất đơn giản: “Các sản phẩm có thể được thêm vào giỏ hàng” và “Giỏ hàng hiển thị các sản phẩm đã được thêm.”
Đội ngũ phát triển đã xây dựng tính năng giỏ hàng, nhưng trong quá trình kiểm thử, nhiều vấn đề đã nảy sinh. Một số người kiểm thử phát hiện ra rằng việc thêm hơn 100 sản phẩm khiến giỏ hàng chạy chậm đi đáng kể. Những người khác lại khám phá ra rằng việc thêm các sản phẩm có các biến thể khác nhau (ví dụ: kích cỡ, màu sắc) đôi khi dẫn đến việc hiển thị sai sản phẩm. Product Owner đã mặc định rằng những kịch bản này sẽ được xử lý một cách ngầm hiểu, nhưng chúng không hề được nêu rõ ràng.
Điều này đã dẫn đến việc phải làm lại và gây ra sự chậm trễ. Để khắc phục, Product Owner, cùng với sự hợp tác của cả nhóm, đã định nghĩa lại các acceptance criteria bằng cách sử dụng khuôn khổ INVEST…
…đặc biệt tập trung vào việc làm cho chúng trở nên ‘Testable’.
Sau khi áp dụng phương pháp tinh chỉnh này cho các acceptance criteria, chúng ta sẽ đo lường thành công bằng cách theo dõi các chỉ số như tỷ lệ lỗi liên quan đến các yêu cầu bị hiểu sai, số lượng yêu cầu cần làm rõ từ đội ngũ phát triển, và sự hài lòng của stakeholder đối với các tính năng được bàn giao.
Việc cải tiến liên tục là rất quan trọng. Chúng ta nên thường xuyên xem xét lại quy trình định nghĩa acceptance criteria của mình, thu thập phản hồi từ đội ngũ phát triển và các stakeholder. Qua đó, chúng ta có thể phát hiện ra rằng một số loại tiêu chí nhất định luôn gây ra vấn đề, đòi hỏi phải tinh chỉnh thêm các mẫu hoặc cần thêm đào tạo. Chúng ta cũng có thể xác định các mẫu hình trong sự hiểu lầm, từ đó chỉ ra các vấn đề giao tiếp tiềm ẩn trong nội bộ đội nhóm.
