User Story

Mục đích của một user story là làm cái cớ để cả team ngồi nói chuyện với nhau. Ba dòng ngắn viết từ góc nhìn người dùng rồi dán lên backlog chỉ là phần nhìn thấy được. Ron Jeffries gọi đó là 3C: Card (mẩu giấy), Conversation (cuộc trao đổi), Confirmation (điều kiện xác nhận). Phần Card là phần ai cũng nhớ, còn hai phần sau mới là chỗ tạo ra giá trị.

User story mô tả một nhu cầu nhỏ từ góc nhìn người dùng, đủ để team hiểu vì sao phải làm, và cố ý viết ngắn để buộc mọi người trao đổi thay vì đọc tài liệu.

Mẫu câu và cách viết cho ra hồn

As a [vai trò], I want [muốn làm gì], so that [để đạt được gì].

Tiếng Việt: Là một [vai trò], tôi muốn [làm gì], để [đạt được gì].

Vế "so that" bị bỏ nhiều nhất và cũng đáng giá nhất. Không có nó, dev không biết cái gì quan trọng khi phải đánh đổi, và bạn không đo được story này làm xong có ích không.

• Yếu: Là người dùng, tôi muốn có nút xuất Excel. — Vai trò chung chung, không lý do.
• Được: Là kế toán công nợ, tôi muốn xuất danh sách hoá đơn quá hạn ra Excel theo từng khách hàng, để gửi kèm email nhắc nợ mà không phải gõ lại tay 40 dòng mỗi sáng thứ hai.

Story thứ hai cho biết ai, làm gì, tần suất và vì sao — từ đó acceptance criteria gần như tự viết ra.

INVEST

Bill Wake đặt ra bộ sáu tiêu chí này để kiểm tra một story có dùng được không:

Trong sáu chữ, S và T là hai chữ nên soi trước. Story không nhỏ thì mọi ước lượng đều là phỏng đoán; story không testable thì không bao giờ chốt được là đã xong.

So sánh với Use Case

Ở mấy dự án ngân hàng, cách kết hợp hay gặp là: backlog giữ user story để quản lý ưu tiên, còn những luồng phức tạp như tính lãi hay xử lý giao dịch treo thì đính kèm use case đầy đủ. Không có luật nào cấm dùng cả hai.

Story giả — task kỹ thuật đội lốt

Đây là bệnh phổ biến ở team mới chuyển sang Agile. Bạn sẽ thấy trên backlog những dòng thế này:

• Là một developer, tôi muốn refactor module thanh toán, để code sạch hơn.
• Là một hệ thống, tôi muốn có bảng `tbl_transaction_log`, để lưu lịch sử.
• Là admin, tôi muốn dựng môi trường staging, để deploy được.

Cả ba đều không phải user story. "Developer" không phải người dùng sản phẩm, "hệ thống" thì càng không. Chúng là task kỹ thuật, và task kỹ thuật hoàn toàn chính đáng — chỉ cần gọi đúng tên là technical task hoặc enabler, đưa vào Sprint Backlog bình thường, đừng bẻ cong khuôn "As a...".

Vì sao gọi tên lại quan trọng: khi mọi thứ đều mang hình dạng user story, Product Owner mất khả năng nhìn ra bao nhiêu phần trăm sức lực của Sprint đi vào giá trị cho người dùng và bao nhiêu đi vào hạ tầng. Con số đó cần được nhìn thấy, chứ không giấu dưới một câu có chữ "Là một".

Cách chữa: viết được vế "so that" mà người hưởng lợi là con người thật ngoài team thì đó là story. Không thì gọi nó là task và ghi rõ nó phục vụ story nào.

Ví dụ thực tế

Story gốc được ước lượng 21 điểm, và cả team nhìn nhau vì không ai tin nổi con số đó. Sản phẩm là phần mềm quản lý một chuỗi phòng tập, tính năng nhắc gia hạn thẻ hội viên. Chẻ ra thành ba:

1. Là hội viên sắp hết hạn thẻ, tôi muốn nhận thông báo trước 7 ngày, để không bị chặn ở cửa quay lúc đi tập. (5 điểm)
2. Là hội viên, tôi muốn thấy gói đang dùng và giá gia hạn ngay trong thông báo, để quyết định luôn. (3 điểm)
3. Là hội viên, tôi muốn gia hạn và trả tiền ngay trong app, để khỏi xếp hàng ở quầy lễ tân. (8 điểm)

Ba story, mỗi cái tự nó có giá trị, và nếu sprint hết chỗ thì bỏ cái thứ ba vẫn ra được một thứ dùng được. INVEST cố bảo bạn làm đúng chuyện đó.