INVEST
Sáu tiêu chí kiểm tra chất lượng một user story: Independent, Negotiable, Valuable, Estimable, Small, Testable. Dùng như bộ soi nhanh trước khi đưa story vào sprint.
Định nghĩa
Bill Wake đặt ra bộ này năm 2003 như một cách nhớ nhanh sáu đặc điểm của một user story dùng được. Không phải chuẩn của tổ chức nào, cũng không nằm trong Scrum Guide, nhưng cực kỳ tiện khi bạn cầm một story trong buổi refinement và cần quyết định có nên đưa nó vào sprint hay không.
Story trượt hai tiêu chí trở lên thì đừng đưa vào sprint. Trượt riêng chữ S thì chẻ nhỏ, thường là đủ để chữa luôn mấy chữ còn lại.
Sáu tiêu chí
| Chữ | Nghĩa | Cách kiểm nhanh |
|---|---|---|
| Independent | Độc lập | Làm story này trước hay sau story kia đều được không |
| Negotiable | Còn thương lượng được | Story mô tả nhu cầu hay đã chốt cứng giải pháp kỹ thuật |
| Valuable | Có giá trị | Ai được lợi và lợi ở chỗ nào, nói ra được không |
| Estimable | Ước lượng được | Team có đủ hiểu biết để cho một con số không |
| Small | Đủ nhỏ | Vừa một sprint, tốt nhất là vài ngày |
| Testable | Kiểm thử được | Viết được acceptance criteria có kết quả đạt hoặc trượt không |
Ba chữ đầu nói về cách viết story, ba chữ sau nói về mức độ sẵn sàng thực thi. Chữ hay bị trượt nhất trong thực tế là I và T.
Đi qua từng chữ bằng ví dụ
Lấy một story tệ có thật, kiểu hay thấy trong dự án ngân hàng:
"Là quản trị viên, tôi muốn hệ thống có phân quyền để bảo mật tốt hơn."
- Independent: không rõ. Nó đụng vào mọi màn hình, làm rời ra khỏi các story khác gần như không được.
- Negotiable: tạm ổn, chưa chốt cứng kỹ thuật.
- Valuable: mơ hồ. "Bảo mật tốt hơn" không nói được ai bớt khổ chỗ nào.
- Estimable: không. Phân quyền cho bao nhiêu vai trò, bao nhiêu chức năng, có phân quyền theo chi nhánh không.
- Small: không, đây là cả một epic.
- Testable: không. Kiểm cái gì để gọi là đạt.
Viết lại thành một story trong số nhiều story:
"Là trưởng phòng giao dịch, tôi muốn giao dịch viên tại chi nhánh mình chỉ xem được hồ sơ khách hàng thuộc chi nhánh đó, để tránh việc tra cứu thông tin ngoài phạm vi công việc."
Acceptance criteria: giao dịch viên chi nhánh A tìm khách hàng của chi nhánh B thì không ra kết quả; trưởng phòng vẫn xem được toàn bộ chi nhánh mình; mọi lượt tra cứu đều ghi log kèm mã nhân viên và thời điểm.
Bây giờ story đó ước lượng được, kiểm thử được, và giá trị nói ra được thành lời.
Chỗ INVEST không áp dụng được
Đừng ép mọi item trong backlog phải đạt INVEST.
- Spike là việc đi tìm hiểu, bản chất là chưa ước lượng được kết quả. Nó chỉ cần timebox.
- Việc kỹ thuật thuần như nâng phiên bản framework, tách service, dựng pipeline CI. Ép viết thành "Là người dùng, tôi muốn nâng phiên bản..." là trò hình thức nhìn rất buồn cười. Cứ ghi thẳng đó là việc kỹ thuật, nêu lý do và tác động.
- Bug. Ghi mô tả lỗi, bước tái hiện, mức độ. Không cần khoác lên nó cái áo user story.
Chuyện chữ Independent trong thực tế
Đây là tiêu chí lý tưởng hoá nhất. Trong dự án tích hợp nhiều hệ thống, phụ thuộc là chuyện không tránh được: story hiển thị lịch sử giao dịch buộc phải chờ story đồng bộ dữ liệu từ hệ thống cũ.
Cách xử lý thực dụng: chấp nhận phụ thuộc, nhưng phải nhìn thấy nó. Ghi rõ trong story, xếp thứ tự backlog theo đúng chuỗi phụ thuộc, và tránh đưa hai story phụ thuộc chặt vào cùng một sprint nếu chúng do hai người khác nhau làm.
Mẹo khi đi làm
Dán sáu chữ này lên đầu buổi refinement, đi qua nhanh từng story trong 30 giây. Đừng biến nó thành biểu mẫu chấm điểm sáu ô. Giá trị của INVEST nằm ở chỗ nó gợi ra câu hỏi đúng vào lúc còn kịp sửa, chứ không phải ở việc điền cho đủ.
