User Story Mapping
Cách sắp xếp user story thành bản đồ hai chiều: ngang là trình tự người dùng làm việc, dọc là mức ưu tiên. Giúp nhìn ra khoảng trống và cắt phạm vi phát hành gọn hơn danh sách phẳng.
Định nghĩa
Product Backlog là một danh sách dọc. Nhìn vào 150 dòng xếp chồng lên nhau, bạn không thấy được người dùng thật sự đi qua những bước nào, và cũng không biết mình đang thiếu chỗ nào. Jeff Patton đưa ra cách khác: trải story ra thành bản đồ hai chiều.
Trục ngang là trình tự thời gian người dùng làm việc, đọc từ trái sang phải như một câu chuyện. Trục dọc là mức cần thiết, càng lên trên càng không thể thiếu.
Danh sách phẳng che mất bối cảnh. Bản đồ cho bạn thấy ngay chỗ nào đang trống mà chẳng cần ai chỉ.
Ba tầng của bản đồ
Tầng 1: hoạt động lớn (backbone). Những bước chính trong công việc của người dùng. Ví dụ với ứng dụng giao đồ ăn: Tìm quán, Chọn món, Đặt đơn, Theo dõi đơn, Nhận hàng, Đánh giá.
Tầng 2: bước cụ thể. Dưới mỗi hoạt động là các bước nhỏ hơn. Dưới "Tìm quán" có: xem quán gần đây, tìm theo tên món, lọc theo giá, xem quán đã lưu.
Tầng 3: story chi tiết. Dưới mỗi bước là các story thật, xếp dọc theo mức cần thiết. Dưới "lọc theo giá" có thể là: lọc theo khoảng giá cố định, tự nhập khoảng giá, nhớ bộ lọc lần trước.
Sau đó kẻ ngang vài đường để cắt lát: lát trên cùng là bản phát hành đầu tiên, lát kế tiếp là bản thứ hai. Mỗi lát phải đi hết chiều ngang, nghĩa là người dùng vẫn làm trọn được công việc, chỉ ở mức đơn giản hơn.
Dựng một bản đồ trong buổi workshop
- Mời đúng người: PO, BA, một vài dev, QC, designer, và tốt nhất là một người hiểu công việc thật ngoài hiện trường.
- Chọn một nhân vật cụ thể. Đừng làm bản đồ cho "người dùng" chung chung, làm cho "tài xế giao hàng chặng cuối, chạy 25 đơn mỗi ngày".
- Dán backbone trước, đọc lại từ trái sang phải xem có bước nào hụt không.
- Bổ sung chi tiết bên dưới, để mọi người viết tự do rồi gom nhóm.
- Cắt lát và đặt tên cho từng lát bằng mục tiêu, không phải bằng ngày tháng.
Dùng giấy dán tường nếu ngồi cùng phòng. Làm từ xa thì Miro hoặc FigJam đều ổn. Công cụ không quan trọng bằng việc có mặt đủ người biết chuyện.
Ví dụ thực tế
Một công ty giao hàng nội thành muốn làm lại app cho tài xế. Backlog ban đầu: 90 story do bên vận hành liệt kê, xếp thành một danh sách dọc dài dằng dặc.
Dựng story map với ba tài xế thật ngồi cùng. Backbone: Nhận ca, Nhận đơn, Lấy hàng tại kho, Giao hàng, Xử lý đơn hỏng, Kết ca.
Cột Xử lý đơn hỏng gần như trống. Trong 90 story ban đầu chỉ có 2 story chạm tới nó. Trong khi đó ba tài xế nói mỗi ngày họ gặp trung bình 2 đến 3 đơn có vấn đề: khách không nghe máy, sai địa chỉ, khách từ chối nhận. Mỗi ca họ mất khoảng 40 phút gọi tổng đài cho những ca này.
Lát phát hành đầu tiên được cắt lại: bỏ bớt phần thống kê thu nhập theo tuần vốn được ưu tiên cao, thêm 5 story cho luồng xử lý đơn hỏng. Cái khoảng trống đó nằm ngay trước mắt trên bản đồ, còn trong danh sách 90 dòng thì không ai nhìn ra suốt hai tháng.
So sánh với backlog thường
| Tiêu chí | Danh sách backlog | Story map |
|---|---|---|
| Cách nhìn | Một chiều, theo thứ tự ưu tiên | Hai chiều, theo trình tự và mức cần thiết |
| Phát hiện thiếu sót | Khó, phải nhớ trong đầu | Dễ, chỗ trống hiện ra ngay |
| Cắt phạm vi | Cắt từ dưới lên, dễ hụt luồng | Cắt theo lát ngang, luồng vẫn trọn |
| Dùng để | Vận hành hằng ngày | Lập kế hoạch phát hành, bàn với stakeholder |
Story map không thay thế backlog. Nó là cách nhìn khác trên cùng một tập story, dùng lúc lập kế hoạch rồi đưa kết quả về backlog để chạy sprint.
Lỗi hay gặp
- Dựng bản đồ cho hệ thống thay vì cho người dùng. Backbone thành ra "Đăng nhập, Quản lý danh mục, Báo cáo" — đó là menu, không phải công việc của ai cả.
- Làm một lần rồi bỏ. Bản đồ nên được mở lại mỗi khi chuẩn bị lát phát hành mới.
- Nhồi quá nhiều nhân vật vào một bản đồ. Mỗi vai trò khác nhau thì làm bản đồ riêng, hoặc ít nhất là hàng riêng.
- Cắt lát theo module kỹ thuật thay vì theo luồng công việc. Cắt kiểu đó thì lát đầu tiên chẳng ai dùng được.
