User Story
User Story là gì?
(1) Who - What - Why
Format
As a [persona], <= WHO
I want to [do something], <= WHAT
so that I can [derive a benefit] <= WHY
Như mọi người thấy, user story viết theo dạng Who-What-Why, và không có How, không biết trình tự các bước trong chức năng người dùng phải thực hiện thế nào. Và thực tế tất cả các chi tiết, logics, kịch bản mà không mô tả trong user story thì hay được đưa vào acceptance criteria.
Ví dụ:
US01: As a customer, I want to be able to cancel my reservation at any time, So that I do not lose all the money if an incident occurs.
Acceptance Criteria
Acceptance Criteria
AC1: Verify that a premium member can cancel the same day without a fee.
AC2: Verify that a non-premium member is charged 10% for a same-day cancellation.
AC3: Verify that an email confirmation is sent.
AC4: Verify that the hotel is notified of any cancellation.
(Chú thích: cách viết AC thế này là kiểu checklist, còn một kiểu nữa theo dạng scenario cho bạn nào muốn áp dụng BDD - behaviour-driven development)
(2) Why - Who - What
Thực tế nhiều người làm user story để cho nhanh, cho kịp với tiến độ dự án, họ thường bỏ phần WHY đi. Và đấy cũng chính là thiếu sót lớn nhất của người làm user story. Nên về sau xuất hiện thêm trường phái viết WHY (purpose) lên trước, và thay “So than I can…” thành “In order to…” cho hợp ngữ cảnh.
click to edit
In order to [achieve some business value] <= WHY
As a [persona], <= WHO
I want to [do something], <= WHAT
click to edit
Thêm nữa, khi nói đến “user story”, thường hàm ý 2 nghĩa để mọi người lưu ý:
1- cấu trúc story (như trên), và
2- một requirement item. Để thấy rằng, một epic hay feature cũng có thể tuân thủ cấu trúc story, nhưng quy mô & phạm vi epic cao hơn feature, và feature cao hơn user story.
Tại sao cần phân tách User Story?
Khi xây dựng backlog cho dự án, chúng ta hay phân tích, phát triển và liệt kê các epic, (feature), và user story. Tại thời điểm ban đầu, không phải lúc nào chúng ta cũng xác định rõ ngay được một user story đã đủ nhỏ hay chưa (“nhỏ” hiểu là phát triển được trong phạm vi một sprint).
Và nếu chúng ta không thể xác định được thế nào là “nhỏ”, các bạn thử hình dung thế này:
Giả sử bạn viết một user story US01 và phân tích được 5 Acceptance Criteria, từ AC01 đến AC05. Và theo cách thông thường, bạn giải thích cho team và đưa US01 vào sprint sắp phát triển (Sprint 2), tất nhiên cũng có vài user story khác nữa cho sprint 2.
Trước khi sprint 2 khởi động, mọi người làm estimate và planning. Mọi thứ vẫn trong tầm kiểm soát. Hết tuần thứ nhất của sprint 2, việc hoàn thành các AC bắt đầu gặp khó khăn. Sang tuần thứ 2 mọi người vẫn hy vọng làm hết 5 AC.
Đến cuối sprint 2, chuẩn bị demo / sprint review, xuất hiện tình trạng 2 AC chưa hoàn thành, hoặc code xong và còn nhiều bugs. Cho nên chỉ kịp demo US01 với 3 AC. Trong buổi planning cho Sprint 3, cả team thống nhất chuyển 2 AC kia sang. Tức là tách US01 thành 2 phần: US01.1 với 3 AC xong cho Sprint 2, và US01.2 gồm 2 AC chưa xong cho Sprint 3.
Dần dà các sprint trong Scrum cứ chạy theo "practice" đó, làm cho product backlog của chúng ta ngày càng dài ra và nhiều lên.
Và như vậy cũng chỉ ra rằng chúng ta đang xử lý scope và thực thi các story chưa thực sự ngon. Cụ thể về quản lý scope cũng như duy trì backlog thế nào cho tốt, mình xin dành một phần khác. Trong bài này chúng ta quay lại chủ đề về user story, và xem làm thế nào để chia tách story tốt hơn, hiệu quả hơn.
Phân tách User story như thế nào?
Dưới đây minh họa 6 cách chia tách một user story. Khi phân tích các story và đưa vào sprint, chúng ta cần tách thành các story nhỏ hơn, hoặc chia AC thành các AC nhỏ hơn. “Nhỏ” tới mức nào không thể nhỏ hơn nữa là được (nhưng cũng tránh vụn quá!!). Dùng một hai cách chưa đủ nhỏ thì dùng tiếp cách khác. Lưu ý là một story không nên có quá nhiều AC (vd < 10), cũng như một epic không nên quá nhiều story (vd 10-15).
click to edit
Cách 1 - Workflow
Một workflow có nhiều bước, thay vì gộp là một story, thì chúng ta tách ra mỗi bước một user story.
Thay vì viết:
As a grocery store cashier, I want to check out a customer, so that I can complete the sales transaction.
Nên là:
As a grocery store cashier, I want to…
... calculate the total amount that will be charged to the customer
... specify the method of payment preferred by the customer
... enter the credit card details
... print a receipt for the customer
click to edit
Cách 2 - Data Details
Trên một màn hình có nhiều trường dữ liệu user phải nhập vào, có thể tách thành từng nhóm dữ liệu liên quan, mỗi nhóm một user story.
Thay vì viết:
As a student, I want to view my grades for this semester’s courses, so that I can see how I’m performing.
Nên viết:
As a student, I want to view…
... my numeric grade for this semester’s courses, so that I can quantify my performance.
... my letter grade for this semester’s courses, so that I can calculate my GPA easily
... the class average for this semester’s courses, so that I understand my relative performance.
click to edit
Cách 3 - Happy Path/Unhappy Paths
Một user story nhiều khi chỉ tập trung vào mục đích chính của người dùng (happy path, happy case, main flow), người phân tích quên mất còn nhiều luồng khác.
Các luồng phụ (corner cases) cũng có thể trong các story khác nhau.
Thay vì viết:
As a Uber-taxi customer, I want to view information about my booked taxi, so that I can track its movement.
Nên viết:
As a Uber-taxi customer, I want to view information about…
… an on-time taxi, so that I can track its movement
… a delayed taxi, so that I can track its movement
… a cancelled taxi, so that I can re-book another one..
click to edit
Cách 4 - Core & Enhance). Ttheo phần Cơ bản và phần Nâng cấp
Tập trung phần chính & đủ đơn giản trước, vd một chức năng Search với các tham số ngầm định, táchcác phần nâng cấp thành các user story, vd chức năng Search với các bộ lọc khác nhau.
Thay vì viết:
As a Salesforce user, I want to create revenue, profit, and growth reports, so that I can perform monthly forecasting.
Nên viết:
As a Salesforce user, I want...
... to create a revenue report for a month, so that I can view the revenue generated in that month
... to create revenue, profit, and growth reports for all months, so that I can perform forecasting for the next month.
click to edit
Cách 5 (Business Rules / Policies). Theo Quy tắc nghiệp vụ / Chính sách sản phẩm
Chia theo mỗi quy tắc nghiệp vụ / quy định / chính sách sản phẩm là một story. Quy tắc nào quan trọng về nghiệp vụ và có ảnh hưởng lớn thì đưa lên trước, ưu tiên cao hơn.
Thay vì viết:
As a customer, I want to purchase the goods in my shopping basket so that I can receive my products at home.
As a shop owner, I want to track & control the orders submitted from the customer in my store, so that I'm aware of what the status of the order is.
Nên viết:
As a shop owner, I want to…
… decline orders below 10 dollars, because I don't make any profit on them;
… decline customers from outside the US, because the shipping expenses make these orders unprofitable;
… reserve ordered products from stock for 48 hours, so other customers see a realistic stock;
… automatically cancel orders for which I have not received payment within 48 hours, so I can sell them again to other customers;
click to edit
Cách 6 (Operations). Chia theo các chức năng quản lý / bảo trì / vận hành
Mỗi hoạt động trong quản lý / bảo trì / vận hành là một user story.
Thay vì viết:
As shop owner I want to manage products in my online shop, so I can update price and product information if it is changed.
Nên viết:
As a shop owner, I want to…
… add new products, so customers can purchase them;
… update existing products, so I can adjust for changes in pricing or product information;
…delete products, so I can remove products that I no longer stock
…hide products, so they cannot be sold for the time being;