User Story Writing (INVEST)

User story là lời hứa sẽ nói chuyện, không phải bản đặc tả thu nhỏ

User story được sinh ra để thay thế tài liệu đặc tả dày cộm, không phải để nén nó lại thành một câu. Giá trị của nó nằm ở cuộc trao đổi mà nó khơi ra, không nằm ở chữ nghĩa trong thẻ.

Nếu đội bạn viết story rồi ném qua cho engineer mà không nói chuyện, bạn đang có phần tệ nhất của cả hai cách làm: vừa thiếu chi tiết của tài liệu đặc tả, vừa mất đi cuộc trao đổi mà story lẽ ra phải tạo ra.

Ba phần của một story, và phần thứ ba mới là phần có sức nặng:

Mẫu câu quen thuộc — "Là một [vai trò], tôi muốn [hành động], để [lợi ích]" — hữu ích vì nó buộc phải trả lời "để làm gì". Nhưng đừng thờ phụng nó: nếu phần "để…" nghe gượng ép hoặc lặp lại phần "tôi muốn…", story đó thường không có giá trị thật cho người dùng.

INVEST — sáu phép thử, và cái nào quan trọng nhất

Trong sáu chữ, chữ V và chữ T là hai chữ đáng giữ nhất. Một story không có giá trị rõ ràng là việc làm lãng phí dù viết đẹp tới đâu; một story không kiểm được sẽ luôn kết thúc bằng tranh cãi.

Về chữ E: khi đội không ước lượng được, phản xạ đúng không phải là ép họ cho một con số. Đó là tín hiệu cần một cuộc trao đổi nữa, hoặc cần một bản dựng thử nhỏ để hiểu thêm.

Cắt story lớn — sáu cách, kèm ví dụ

Story quá lớn là vấn đề phổ biến nhất. Dưới đây là các cách cắt, xếp từ tốt tới tạm được.

Phép thử sau khi cắt: nếu chỉ làm mảnh đầu tiên rồi dừng, có ai được lợi không? Trả lời "không" nghĩa là bạn vừa cắt theo lớp kỹ thuật dù tưởng là không.

Điều kiện xác nhận — viết thế nào cho khỏi cãi

Đây là phần quyết định story thành hay bại, và là phần hay được viết qua loa nhất.

• Viết thành ví dụ cụ thể, không viết thành nguyên tắc chung. "Hệ thống phải xử lý đơn hàng lớn" là nguyên tắc; "đơn 150 mã hàng hiển thị đầy đủ trong 3 giây" là ví dụ kiểm được.
• Dùng cấu trúc bối cảnh → hành động → kết quả. "Khi giỏ hàng có hàng hết tồn kho, và người dùng bấm thanh toán, thì hiện cảnh báo nêu rõ mã hàng nào và không cho đi tiếp."
• Luôn có ít nhất một ca ngoại lệ. Điều kiện xác nhận chỉ toàn ca thuận nghĩa là chưa nghĩ đủ.
• Nêu cả điều KHÔNG thuộc phạm vi. "Lần này chưa xử lý đơn hàng quốc tế." Câu này tiết kiệm nhiều tranh luận hơn bất kỳ câu nào khác.
• Viết cùng engineer và QA, không viết một mình. Họ sẽ nghĩ ra ca mà bạn không nghĩ tới — đó chính là giá trị của cuộc trao đổi.

Ví dụ — một story tệ được sửa thành tốt

Bản tệ: "Là một người dùng, tôi muốn có bộ lọc, để tìm dễ hơn."

Vấn đề: vai trò chung chung, không rõ lọc theo gì, không rõ lợi ích thật, không có điều kiện xác nhận, và quá lớn để ước lượng.

Bản đã sửa:

"Là nhân viên kho đang kiểm hàng tồn, tôi muốn lọc danh sách theo trạng thái sắp hết hàng, để đặt hàng bổ sung trước khi hết sạch."

Điều kiện xác nhận:

• Khi có hàng dưới mức tồn tối thiểu, và tôi chọn bộ lọc "Sắp hết", thì danh sách chỉ hiện những mã đó, sắp xếp theo mức thiếu nhiều nhất lên trước.
• Khi không có mã nào sắp hết, thì hiện thông báo "Không có mặt hàng nào sắp hết" kèm nút quay lại danh sách đầy đủ.
• Khi danh sách có trên 200 mã, thì kết quả lọc vẫn hiện trong vòng 2 giây.
• Ngoài phạm vi lần này: chưa tự động tạo đơn đặt hàng bổ sung.

Bản đã sửa ước lượng được, kiểm được, và có giá trị rõ ràng — cùng một ý tưởng, khác nhau ở chỗ đã trải qua một cuộc trao đổi.

Hiccups thường gặp và cách xử lý

Vì sao vai trò của bạn cần cái này

Definition of done

• Mỗi story đã qua một cuộc trao đổi thật, không chỉ được viết ra.
• Story đạt sáu phép thử INVEST, đặc biệt là có giá trị và kiểm được.
• Điều kiện xác nhận viết thành ví dụ cụ thể theo bối cảnh → hành động → kết quả.
• Có ít nhất một ca ngoại lệ trong điều kiện xác nhận.
• Có nêu rõ phần nào ngoài phạm vi lần này.
• Story cắt ra vẫn có giá trị tự thân — không cắt theo lớp kỹ thuật.