User story là gì? Cách viết cho người mới, kèm mẫu và ví dụ
Mẫu “Là…, tôi muốn…, để…” là phần dễ. Bài này chỉ cách chọn đúng người dùng, đúng vấn đề và cắt story đủ nhỏ, kèm ví dụ trước và sau.
Viết bởi Phan Lâm Duy Khôi
Một user story tốt nói rõ một người dùng cụ thể, một vấn đề có thật của họ và một phần giá trị đủ nhỏ để team làm xong trong một sprint. Mẫu “Là [ai], tôi muốn [gì], để [vì sao]” chỉ là khung ghi lại, phần quan trọng là cuộc trao đổi và cách xác nhận đã xong.
Một user story bị trả lại
Đây là tình huống minh họa. Bạn vừa nhận vai PO cho ứng dụng của một shop cây cảnh online tên Mầm Xanh (tên hư cấu). Buổi họp lên kế hoạch sprint sắp tới, bạn viết vội một dòng vào backlog: “Là người dùng, tôi muốn quản lý đơn hàng, để tiện theo dõi.”
Trong buổi họp, một bạn dev hỏi: “Người dùng ở đây là khách hay nhân viên shop? Quản lý là xem, sửa hay hủy? Đơn cũ từ năm ngoái có cần không?” Bạn designer hỏi thêm khách xem trên điện thoại hay máy tính. Bạn QA hỏi làm sao biết là xong. Bạn trả lời được một nửa, nửa còn lại là “để mình hỏi lại”. Story bị đẩy sang sprint sau.
Câu story của bạn đúng mẫu. Nó có đủ ba phần “Là…, tôi muốn…, để…”. Vấn đề không nằm ở mẫu. Nó nằm ở chỗ câu đó chưa nói được ai thật sự cần, họ đang gặp khó ở đâu, và lần này team làm phần nào.
User story là gì, và vì sao viết đúng mẫu vẫn chưa đủ?
User story là một mô tả ngắn về điều một người dùng cần làm được và vì sao họ cần nó, viết từ góc nhìn của người dùng. Backlog là danh sách các việc team có thể làm, đã được sắp theo thứ tự ưu tiên. Sprint là một chu kỳ làm việc ngắn, cố định, mà cuối chu kỳ team phải có một phần sản phẩm dùng được.
Mẫu phổ biến nhất là: Là [ai], tôi muốn [làm được gì], để [đạt được điều gì]. Mẫu này dễ học trong năm phút. Cái khó nằm ở ba chỗ mà mẫu không tự giải quyết được.
- Người dùng thật. “Người dùng” hay “khách hàng” là một nhóm quá rộng. Khách mua lần đầu, khách mua lại và nhân viên chăm sóc khách có nhu cầu rất khác nhau.
- Vấn đề thật. Phần “để…” hay bị viết cho có, kiểu “để tiện hơn” hay “để trải nghiệm tốt hơn”. Một câu như vậy không giúp ai chọn giữa hai cách làm.
- Lát cắt đủ nhỏ. “Quản lý đơn hàng” chứa cả chục việc. Viết chung vào một story thì team không ước lượng được, cũng không làm xong trong một sprint.
Người mới thường nghĩ viết story là một việc viết lách. Thực ra phần lớn công sức nằm ở việc hiểu vấn đề trước khi viết, và ở cuộc trao đổi với team sau khi viết. Câu chữ trên thẻ chỉ là phần ghi lại.
Nếu yêu cầu bạn nhận được ban đầu là một tin nhắn kiểu “thêm giúp chị tính năng này”, hãy làm rõ nó trước khi viết bất kỳ story nào. Bài về cách xử lý feature request đi qua bước này chi tiết hơn.
Cách viết user story từng bước
Một cách làm dễ áp dụng là đi qua bốn bước theo thứ tự. Đừng mở công cụ quản lý công việc ở bước 1. Hãy viết nháp ra giấy hoặc một file riêng, đến bước 4 mới đưa vào backlog.
- Chọn người dùng: Một nhóm cụ thể, trong một tình huống cụ thể
- Nói rõ vấn đề: Họ đang xoay xở ra sao, điều gì sẽ khác
- Cắt lát nhỏ: Một phần dùng được, làm xong trong một sprint
- Thống nhất cách xác nhận: Trao đổi với team, ghi điều kiện xong
Nếu ở bước 4 team còn nhiều câu hỏi chưa ai trả lời được, quay lại bước 2.
Bước 1, chọn người dùng. Thay “người dùng” bằng một nhóm người mà bạn gọi tên được, kèm tình huống. Ví dụ: “khách đã đặt hàng và đang chờ giao”, thay vì “khách hàng”. Nếu bạn không nói được họ là ai, có thể bạn chưa nói chuyện với họ, hoặc chưa đọc dữ liệu về họ.
Bước 2, nói rõ vấn đề. Viết một câu về việc họ đang làm hôm nay và vì sao nó khó. Ví dụ: “Khách không biết đơn đang ở đâu nên nhắn fanpage hỏi, nhân viên phải mở từng đơn để trả lời.” Câu này sẽ quyết định phần “để…” của story. Nếu phần “để…” chỉ lặp lại phần “tôi muốn…” bằng từ khác, bạn vẫn chưa có vấn đề thật.
Bước 3, cắt lát nhỏ. Hỏi: phần nhỏ nhất nào mà người dùng đã thấy có ích? Một story tốt là một lát cắt dọc: nó đi qua đủ giao diện, xử lý và dữ liệu để người dùng dùng được một việc trọn vẹn, dù nhỏ. Phần tiếp theo của bài nói cách tách khi story quá lớn.
Bước 4, thống nhất cách xác nhận. Mang bản nháp đến cho dev, designer và QA. Mục đích là để họ hỏi, không phải để họ ký nhận. Sau cuộc trao đổi, ghi lại các điều kiện để biết story đã xong. Đó là acceptance criteria.
3C là gì: card, conversation, confirmation
Ron Jeffries mô tả story qua ba phần, thường gọi là 3C. Ý chính: dòng chữ trên thẻ chỉ là một phần ba của story.
- Card (thẻ): Vài dòng đủ để nhận ra story là gì. Thẻ nhắc mọi người rằng việc này cần bàn, không chứa mọi chi tiết.
- Conversation (trao đổi): PO, dev, designer và QA cùng bàn về story, chủ yếu bằng lời, có thể kèm ví dụ hay bản phác. Chi tiết thật nằm ở đây.
- Confirmation (xác nhận): Các điều kiện thống nhất trước khi làm, để cuối sprint cả team cùng kiểm tra được story đã xong hay chưa.
Với người mới, 3C giúp bỏ một áp lực: bạn không cần viết một story hoàn hảo trước buổi họp. Bạn cần một thẻ đủ rõ để bắt đầu trao đổi, và sau trao đổi phải có phần xác nhận.
Phần xác nhận đáng một bài riêng: cách viết acceptance criteria sao cho QA kiểm thử được và dev không phải đoán. Bài này chỉ chạm tới nó ở mức cần thiết.
INVEST là gì? Kiểm tra nhanh một story
INVEST là một danh sách kiểm tra chất lượng story, do Bill Wake đưa ra. Mỗi chữ cái là một tiêu chí. Bạn không cần đạt hoàn hảo cả sáu, nhưng story trượt nhiều tiêu chí thì nên viết lại hoặc tách ra.
| Tiêu chí | Câu tự hỏi | Dấu hiệu chưa đạt |
|---|---|---|
| I: Independent (độc lập) | Story này làm được mà không phải chờ story khác xong không? | “Làm sau khi xong story A, B và C” |
| N: Negotiable (thương lượng được) | Team còn được bàn cách làm không, hay mọi thứ đã chốt cứng? | Story ghi sẵn từng nút, từng màu, không chừa chỗ bàn |
| V: Valuable (có giá trị) | Người dùng hoặc doanh nghiệp được gì khi story xong? | Chỉ là một phần kỹ thuật, như “tạo bảng dữ liệu đơn hàng” |
| E: Estimable (ước lượng được) | Team có đủ thông tin để ước lượng công sức không? | Dev nói “chưa biết, phải xem đã” |
| S: Small (nhỏ) | Làm xong và kiểm tra được trong một sprint không? | Một story chiếm gần hết sprint, hoặc kéo sang sprint sau |
| T: Testable (kiểm thử được) | Có cách nào để biết chắc nó đã xong không? | Không ai nói được làm sao biết story đã xong |
Hai tiêu chí người mới dễ trượt là V và S. Story không có giá trị thường do bạn chia việc theo lớp kỹ thuật. Story quá lớn thường do bạn viết theo tên một khu vực của sản phẩm, như “quản lý đơn hàng” hay “trang cá nhân”.
Story quá lớn thì tách thế nào?
Story quá lớn thường được gọi là epic. Epic không sai, nó chỉ chưa sẵn sàng để làm. Mike Cohn gợi ý vài hướng tách story, gọi tắt là SPIDR. Dưới đây là bốn hướng dễ dùng nhất cho người mới.
- Theo đường đi: Mỗi cách người dùng đạt mục tiêu là một story. Ví dụ: xem đơn trong ứng dụng trước, nhận thông báo qua tin nhắn sau.
- Theo dữ liệu: Bắt đầu với một phần dữ liệu. Ví dụ: chỉ đơn trong ba mươi ngày gần nhất, đơn cũ hơn để story sau.
- Theo quy tắc: Tạm bỏ một quy tắc phức tạp, thêm lại ở story sau. Ví dụ: cho hủy đơn khi chưa đóng gói, chưa xử lý hoàn tiền tự động.
- Theo giao diện: Làm một giao diện đơn giản trước, giao diện đầy đủ sau. Ví dụ: danh sách chữ trước, dòng thời gian có biểu tượng sau.
Ngoài bốn hướng trên còn một cách nữa: tách phần nghiên cứu ra trước. Khi team chưa biết đơn vị vận chuyển có trả trạng thái đơn theo thời gian thực hay không, một việc tìm hiểu ngắn sẽ giúp story sau ước lượng được.
Có một cách tách nên tránh: tách theo lớp kỹ thuật, kiểu “story 1 làm cơ sở dữ liệu, story 2 làm API, story 3 làm giao diện”. Làm xong story 1 hay story 2, người dùng chưa nhận được gì. Đó là việc của team kỹ thuật, nên để họ chia thành task bên trong một story.
Ví dụ trước và sau: story “quản lý đơn hàng”
Quay lại shop Mầm Xanh trong tình huống minh họa. Sau khi hỏi bộ phận chăm sóc khách, bạn biết phần lớn tin nhắn trên fanpage là khách hỏi “đơn của em tới đâu rồi”. Nhân viên phải mở từng đơn trên hệ thống quản trị để trả lời. Đây là vấn đề thật, có người gặp và có người đang tốn công.
| Phần | Trước | Sau |
|---|---|---|
| Là ai | Người dùng | Khách đã đặt hàng và đang chờ giao |
| Muốn gì | Quản lý đơn hàng | Xem đơn gần nhất đang ở bước nào mà không cần nhắn shop |
| Để làm gì | Để tiện theo dõi | Để biết khi nào cần có người ở nhà nhận cây |
| Phạm vi lần này | Không nói | Bốn trạng thái: đã xác nhận, đang đóng gói, đang giao, đã giao |
| Chưa làm lần này | Không nói | Lịch sử đơn cũ, hủy đơn, thông báo qua tin nhắn |
| Cách xác nhận | Không có | Ghi thành acceptance criteria sau buổi trao đổi với team |
Story sau viết đầy đủ là: “Là khách đã đặt hàng và đang chờ giao, tôi muốn xem đơn gần nhất của mình đang ở bước nào mà không cần nhắn shop, để biết khi nào cần có người ở nhà nhận cây.”
Các phần bị cắt ra không mất đi. Chúng trở thành các story tiếp theo trong backlog, mỗi story có người dùng và lý do riêng:
- Là khách đang chờ giao, tôi muốn nhận tin nhắn khi đơn được giao cho đơn vị vận chuyển, để không phải mở ứng dụng kiểm tra.
- Là khách mua lại, tôi muốn xem các đơn đã mua trước đây, để đặt lại đúng loại cây đã mua.
- Là khách vừa đặt nhầm, tôi muốn hủy đơn khi shop chưa đóng gói, để không phải nhắn và chờ nhân viên xử lý.
Để ý rằng story thứ ba có thể không cần làm sớm. Nếu khách hiếm khi đặt nhầm, nó nằm cuối backlog cũng không sao. Tách story ra giúp bạn ưu tiên từng phần theo giá trị, thay vì phải nhận hoặc bỏ cả một khối lớn.
Mẫu user story để dùng ngay
Mẫu đầu là khung cho một story, gồm cả phần bối cảnh và phạm vi mà câu “Là…, tôi muốn…, để…” không chứa được. Mẫu thứ hai là danh sách kiểm tra nhanh trước khi đưa story vào sprint. Bạn copy rồi sửa theo cách team mình đang dùng.
Tên ngắn: [động từ + đối tượng, ví dụ: Xem trạng thái đơn gần nhất] Là [nhóm người dùng cụ thể, trong tình huống nào], tôi muốn [việc họ cần làm được], để [kết quả họ nhận được, hoặc điều sẽ khác đi]. Bối cảnh: [hiện họ đang xoay xở thế nào, ai đang tốn công, vì sao cần lúc này] Trong phạm vi lần này: [liệt kê ngắn] Chưa làm lần này: [liệt kê ngắn, ghi story tiếp theo nếu có] Acceptance criteria: [ghi sau buổi trao đổi với team] Câu hỏi còn mở: [ai trả lời, trước ngày nào] Đã trao đổi với: [dev, design, QA, vận hành], ngày [ngày]
[ ] Gọi tên được người dùng và tình huống, không chỉ ghi "người dùng" [ ] Phần "để..." nói được điều gì sẽ khác đi, không lặp lại phần "tôi muốn..." [ ] Làm xong story này, người dùng đã dùng được một việc trọn vẹn [ ] Không phải chờ story khác xong mới làm được [ ] Team đã ước lượng được, không còn câu "chưa biết, phải xem đã" [ ] Làm xong và kiểm tra được trong một sprint [ ] Đã ghi rõ phần chưa làm lần này [ ] Đã có acceptance criteria mà QA đọc là biết cách kiểm tra
Lỗi hay gặp khi viết user story
- Viết “Là người dùng”. Đây là lỗi rất dễ gặp. Nếu mọi story đều bắt đầu bằng “Là người dùng”, phần “Là ai” không còn giúp gì cho team.
- Viết giải pháp thay cho nhu cầu. “Tôi muốn có nút màu xanh ở góc phải” là một quyết định thiết kế. Hãy viết điều người dùng cần làm được, để designer và dev còn chỗ đề xuất cách tốt hơn.
- Phần “để…” viết cho có. “Để tiện hơn” không giúp ai quyết định. Nếu không viết được lý do cụ thể, hãy quay lại hỏi người gặp vấn đề.
- Tách theo lớp kỹ thuật. Story “làm API đơn hàng” không có giá trị riêng cho người dùng. Hãy để team kỹ thuật chia task bên trong story.
- Xem story là hợp đồng. Viết thật dài để không ai hỏi được gì là đi ngược ý của story. Chi tiết đến từ cuộc trao đổi, rồi được ghi vào phần xác nhận.
- Viết story cho mọi thứ. Sửa một lỗi chính tả hay nâng phiên bản thư viện không cần ép vào mẫu “Là…, tôi muốn…”. Ghi nó thành task bình thường là đủ.
Tóm tắt
- Mẫu “Là [ai], tôi muốn [gì], để [vì sao]” là phần dễ. Phần khó là người dùng thật, vấn đề thật và lát cắt đủ nhỏ.
- Viết theo bốn bước: chọn người dùng, nói rõ vấn đề, cắt lát nhỏ, thống nhất cách xác nhận với team.
- Một story gồm ba phần: thẻ ghi ngắn, cuộc trao đổi với team, và điều kiện xác nhận đã xong.
- Dùng INVEST để kiểm tra nhanh. Story trượt nhiều tiêu chí thì viết lại hoặc tách ra.
- Tách story theo đường đi, dữ liệu, quy tắc hoặc giao diện, không tách theo lớp kỹ thuật.
Mình đang soạn thêm các tình huống PO khác theo cùng khung này, kèm mẫu dùng ngay. Nếu bạn muốn nhận khi có bài mới, đăng ký bản tin bên dưới.
Câu hỏi thường gặp
User story là gì?
User story là một mô tả ngắn về điều một người dùng cụ thể cần làm được và vì sao họ cần nó, viết từ góc nhìn của người dùng. Nó là điểm bắt đầu cho cuộc trao đổi giữa PO và team, không phải một bản đặc tả đầy đủ.
User story khác acceptance criteria thế nào?
User story nói ai cần gì và để làm gì. Acceptance criteria là các điều kiện cụ thể, kiểm tra được, cho biết khi nào story đó được xem là xong.
Một user story nên nhỏ cỡ nào?
Đủ nhỏ để team làm xong và kiểm tra được trong một sprint, nhưng vẫn mang lại một điều có ích cho người dùng. Nếu team không ước lượng được hoặc story kéo dài qua nhiều sprint, hãy tách nó ra.
Nguồn kiểm tra
Bài liên quan
- Acceptance criteria là gì? Cách viết để QA kiểm thử được: Cách viết acceptance criteria rõ đến mức QA đọc xong là biết phải thử gì, kèm ví dụ mã giảm giá và mẫu dùng ngay.
- Ưu tiên backlog khi việc nào cũng gấp: chọn cách nào?: Cách chọn giữa value vs effort, MoSCoW và RICE, tách hạn chót thật khỏi cảm giác gấp, và gửi stakeholder một ghi chú ưu tiên một trang.
- Cách nói không với sếp và stakeholder mà không mất lòng: Ba cách nói không thay cho một chữ “không”, cách xử lý khi người yêu cầu là sếp hoặc CEO, lúc nào nên escalate, kèm hội thoại mẫu và tin nhắn theo từng cấp.
- Sprint planning là gì? PO cần chuẩn bị gì trước buổi họp: Checklist chuẩn bị 1 đến 2 ngày trước sprint planning, cách dẫn phần “làm gì” và cách viết Sprint Goal, kèm mẫu dùng ngay.