User story mapping là gì? Từ epic đến story cho bản đầu tiên

Cách dựng một story map từ hoạt động của người dùng, tách epic thành story và cắt ra lát nhỏ nhất dùng được cho bản phát hành đầu tiên.

Viết bởi Phan Lâm Duy Khôi

User story mapping là cách xếp user story thành một bản đồ hai chiều: hàng ngang là các hoạt động của người dùng theo thứ tự, cột dọc là các story xếp từ cần nhất xuống ít cần hơn. Cắt ngang bản đồ, bạn có lát nhỏ nhất giúp người dùng đi trọn hành trình, dùng làm bản phát hành đầu tiên.

User story mapping là gì, và khi nào bạn cần nó?

User story mapping là cách xếp user story thành một bản đồ hai chiều: hàng ngang là các hoạt động của người dùng theo thứ tự họ làm, cột dọc là các story xếp từ cần nhất xuống ít cần hơn. Cắt ngang bản đồ đó, bạn có lát nhỏ nhất giúp người dùng đi trọn hành trình, và lát này trở thành bản phát hành đầu tiên.

Jeff Patton mô tả cách làm này trong bài “The New User Story Backlog is a Map”. Ý chính của ông: một backlog phẳng, xếp từ trên xuống dưới, làm mất bức tranh tổng thể. Bản đồ giúp team kể lại sản phẩm theo đúng thứ tự người dùng trải qua, nhờ đó thấy chỗ còn thiếu và lên kế hoạch phát hành dễ hơn.

Tình huống minh họa: bạn vừa nhận vai PO cho một ứng dụng đặt lịch của chuỗi tiệm tóc nhỏ, gọi là Hẹn Tóc. Chủ chuỗi giao một epic duy nhất: “Cho khách đặt lịch online”. Sau hai buổi gặp, backlog đã có gần bốn mươi dòng: chọn thợ, đặt cọc, nhắc lịch, tích điểm, đánh giá, đổi giờ, báo cáo doanh thu. Developers hỏi bạn một câu rất bình thường: “Bản đầu tiên gồm những gì?” Bạn nhìn danh sách và thấy dòng nào cũng có vẻ cần.

Story mapping là công cụ dành cho đúng lúc này. Nó không thay backlog. Nó giúp bạn sắp xếp lại backlog theo hành trình của người dùng, để câu hỏi “bản đầu tiên gồm gì” có câu trả lời mà cả team cùng nhìn thấy.

Epic và user story khác nhau thế nào?

Atlassian mô tả epic là một khối việc lớn, có thể tách thành nhiều story nhỏ hơn, và thường được làm qua nhiều sprint. User story là một mẩu đủ nhỏ để team làm xong trong một sprint, nhưng vẫn mang lại điều có ích mà người dùng thấy được. Nếu bạn chưa quen cách viết story, hãy đọc trước phần mẫu và tiêu chí INVEST trong bài hướng dẫn viết user story.

Vấn đề của người mới không nằm ở định nghĩa. Vấn đề là tách epic theo hướng nào. “Cho khách đặt lịch online” có thể tách thành hàng chục story, và nếu tách theo màn hình hay theo lớp kỹ thuật, bạn sẽ có nhiều mẩu việc mà không mẩu nào tự đứng được. Story map đưa ra một hướng tách: đi theo các bước người dùng làm, rồi hỏi ở mỗi bước, phiên bản đơn giản nhất là gì.

Theo cách nhìn của bài này, một epic trên bản đồ thường tương ứng với một hoạt động lớn hoặc một bước lớn. Các story bên dưới chính là epic đã được tách ra, và thứ tự trên dưới cho biết phần nào làm trước.

Cách viết user story cho người mới

Vì sao chọn bản đầu tiên lại khó?

Khi chỉ có một danh sách dài, bạn chỉ so được từng dòng với nhau. Có vài lý do khiến việc này dễ đi sai.

Danh sách phẳng làm mất ngữ cảnh. “Đặt cọc online” và “xem giờ trống” nằm cạnh nhau như hai việc ngang hàng, dù một việc là điều kiện để khách đặt được lịch, còn việc kia có thể chờ.
Việc nào cũng có người bảo vệ. Chủ chuỗi muốn tích điểm, lễ tân muốn nhắc lịch, kế toán muốn báo cáo. Mỗi người đều có lý do thật.
Dễ nghĩ theo tính năng thay vì theo người dùng. Team nói về “module đặt lịch” và “module thanh toán”, nhưng khách chỉ quan tâm một điều: tối nay mình có ghế lúc bảy giờ không.
Dễ chia theo lớp kỹ thuật. Một kế hoạch kiểu “sprint 1 làm cơ sở dữ liệu, sprint 2 làm API, sprint 3 làm giao diện” nghe hợp lý, nhưng phải đến cuối mới có thứ để người dùng thử.

Agile Alliance nêu một lợi ích cụ thể của story mapping: tránh tình trạng bản phát hành có tính năng giá trị cao nhưng không dùng được, vì nó phụ thuộc vào một phần giá trị thấp hơn đã bị đẩy lại. Bản đồ làm lộ ra những phụ thuộc đó trước khi team bắt tay vào làm.

Cách làm user story mapping từng bước

Một story map có bốn tầng. Nắm được bốn tầng này, bạn sẽ đọc được bản đồ của người khác và tự dựng bản của mình.

Bốn tầng của một story map Đọc từ trái sang phải theo hành trình, từ trên xuống dưới theo mức cần.

Hoạt động: Việc lớn người dùng muốn hoàn thành, ví dụ “đặt một lịch cắt tóc”. Hàng trên cùng, gọi chung là backbone.
Bước: Các bước nhỏ trong mỗi hoạt động, xếp theo thứ tự người dùng làm, ví dụ “xem dịch vụ”, “chọn giờ”.
Story: Các cách làm cụ thể cho từng bước, treo bên dưới. Story càng cần thì đặt càng cao.
Lát phát hành: Đường kẻ ngang chia bản đồ thành các bản phát hành. Lát trên cùng là bản đầu tiên.

Patton ví hàng hoạt động như xương sống: đó là những phần bắt buộc phải có, nên không xếp ưu tiên giữa chúng với nhau. Thứ được xếp ưu tiên là các story bên dưới. Dưới đây là bốn bước để đi từ một epic tới một lát phát hành.

Bốn bước từ epic tới bản đầu tiên Làm cùng team. Một buổi đầu có thể chỉ cần đi hết bốn bước ở mức thô.

Chốt người dùng và mục tiêu: Bản này cho ai, giúp họ làm được gì
Dựng backbone và các bước: Hoạt động ở hàng trên, các bước bên dưới, theo thứ tự người dùng làm
Treo story bên dưới: Mỗi bước vài cách làm, cần nhất ở trên
Cắt lát đầu tiên: Lát mỏng nhất đi trọn từ trái sang phải

Sau khi cắt, kể lại hành trình chỉ bằng các story trong lát đầu. Đứt ở bước nào thì thêm story đơn giản nhất cho bước đó.

Bước 1: chốt người dùng và mục tiêu. Viết một câu: “Bản đầu tiên giúp [ai] làm được [việc gì]”. Với Hẹn Tóc: “Giúp khách mới đặt được một lịch cắt tóc mà không phải gọi điện, và giúp lễ tân thấy lịch trong ngày.” Nếu có nhiều nhóm người dùng, chọn nhóm quan trọng nhất cho bản đầu, nhóm còn lại vẽ thêm sau.

Bước 2: dựng backbone và các bước. Hỏi “người dùng làm gì trước, rồi làm gì tiếp?” và ghi mỗi ý lên một thẻ, dùng động từ: xem dịch vụ, chọn tiệm, chọn giờ, xác nhận, nhận nhắc lịch, đổi hoặc hủy, xem lịch trong ngày. Xếp các bước thành một hàng từ trái sang phải, rồi gom chúng dưới vài hoạt động lớn ở hàng trên, như “đặt lịch” hay “quản lý lịch hẹn”. Hàng hoạt động đó là backbone. Đây là lúc dễ phát hiện bước bị quên, ví dụ chưa ai nghĩ khách hủy lịch bằng cách nào.

Bước 3: treo story bên dưới. Ở mỗi bước, ghi các cách làm từ đơn giản tới đầy đủ. “Chọn giờ” có thể là: xem giờ trống trong bảy ngày tới, chọn thợ cụ thể, đặt cho cả nhóm bạn. Đặt cách đơn giản nhất nhưng vẫn dùng được lên trên cùng. Chưa cần viết acceptance criteria ở bước này, một dòng cho mỗi thẻ là đủ.

Bước 4: cắt lát đầu tiên. Kẻ một đường ngang, chỉ giữ phía trên những story cần để người dùng đi hết hành trình. Patton gọi phiên bản nhỏ nhất chạy được từ đầu đến cuối là walking skeleton, một thuật ngữ ông ghi nguồn từ Alistair Cockburn. Mỗi lát tiếp theo làm dày thêm các bước, thay vì làm xong trọn một bước rồi mới sang bước khác.

Ví dụ: story map cho ứng dụng đặt lịch tiệm tóc

Đây là bản đồ minh họa cho Hẹn Tóc, một ứng dụng giả định. Mỗi dòng là một bước của người dùng. Hai nhóm người dùng xuất hiện: khách đặt lịch và lễ tân của tiệm. Đọc cột “Bản đầu tiên” từ trên xuống, bạn sẽ thấy một hành trình trọn vẹn, dù rất đơn giản.

Story map minh họa của ứng dụng Hẹn Tóc, chia thành ba lát
Bước của người dùng	Hoạt động	Bản đầu tiên	Bản tiếp theo	Để sau
Xem dịch vụ và giá	Tìm dịch vụ (khách)	Danh sách dịch vụ kèm giá và thời lượng	Ảnh mẫu cho từng dịch vụ	Lọc dịch vụ theo khoảng giá
Chọn tiệm	Tìm dịch vụ (khách)	Chọn từ danh sách các tiệm, có địa chỉ	Gợi ý tiệm gần vị trí hiện tại	Xem tiệm trên bản đồ
Chọn giờ	Đặt lịch (khách)	Xem giờ trống trong bảy ngày tới	Chọn thợ cụ thể	Đặt lịch cho cả nhóm
Xác nhận lịch	Đặt lịch (khách)	Nhập tên, số điện thoại, nhận mã đặt lịch trên màn hình	Tài khoản lưu thông tin cho lần sau	Đặt cọc online
Đổi hoặc hủy lịch	Quản lý lịch hẹn (khách)	Màn hình xác nhận hiện số điện thoại tiệm để gọi đổi hoặc hủy	Tự hủy trong ứng dụng bằng mã đặt lịch	Tự đổi sang giờ khác
Nhận nhắc lịch	Quản lý lịch hẹn (khách)	Lễ tân tự nhắn khách dựa trên danh sách lịch trong ngày	Tin nhắn nhắc tự động trước giờ hẹn	Khách tự chọn kênh nhận nhắc
Xem lịch trong ngày	Vận hành tiệm (lễ tân)	Danh sách lịch theo giờ của từng tiệm	Lọc lịch theo thợ	Báo cáo số lịch theo tuần

Vài điều đáng chú ý trong bản đồ này. Lát đầu tiên có những phần làm thủ công: khách gọi điện để hủy, lễ tân tự nhắn nhắc lịch. Đó là lựa chọn có chủ ý. Hành trình vẫn đi trọn, trong khi team dồn sức vào phần cốt lõi là xem giờ trống và đặt lịch. Đặt cọc online nằm ở lát sau, vì thiếu nó khách vẫn đặt được lịch. Tích điểm và đánh giá không thuộc hành trình đặt lịch, nên được để ngoài bản đồ của epic này.

Hãy để ý cả bước “Xem lịch trong ngày” của lễ tân. Nếu bỏ nó, khách đặt được lịch nhưng tiệm không biết ai sẽ đến, và bản đầu tiên không dùng được. Đây đúng là loại phụ thuộc mà một danh sách phẳng dễ che mất.

Để biết lát đầu có ích không, gắn cho nó một chỉ số trước khi làm. Ví dụ, với con số giả định cho minh họa: trong bốn tuần đầu, mỗi tiệm nhận ít nhất hai mươi lịch qua ứng dụng mỗi tuần, và lễ tân không phải gọi lại khách để xác nhận giờ. Con số thật cần chốt cùng chủ chuỗi dựa trên số lịch hiện có.

Trước khi chốt lát đầu tiên, bạn có thể kiểm tra nhanh bằng bốn câu hỏi dưới đây.

Lát đầu tiên đã sẵn sàng chưa? Trả lời “có” thì đi tiếp. Trả lời “chưa” thì làm việc ghi bên cạnh rồi hỏi lại.

Lát đầu tiên vừa cắt

Người dùng đi được trọn hành trình chỉ bằng các story trong lát? Thêm story đơn giản nhất cho bước bị đứt, kể cả một cách làm thủ công.
Mỗi story trong lát mang lại điều người dùng thấy được? Gộp các mẩu kỹ thuật lại theo một hành vi của người dùng.
Lát đủ mỏng để ra mắt sớm và học được từ người dùng thật? Chuyển story chưa bắt buộc xuống lát sau, hoặc thay bằng cách làm thủ công.
Đã có một chỉ số để biết lát này có ích? Viết một câu mục tiêu và một chỉ số đo được trước khi làm.

Đưa các story của lát vào đầu product backlog để refinement

Chỉ số thành công trước khi làm tính năng

Chạy một buổi story mapping với team thế nào?

Story map có giá trị nhất khi được dựng cùng nhau. Một PO tự vẽ rồi gửi cho team sẽ có bản đồ, nhưng không có sự hiểu chung đi kèm. Dưới đây là cách tổ chức một buổi đầu tiên theo gợi ý của bài này, bạn điều chỉnh theo team mình.

Mời ít người nhưng đủ góc nhìn: PO, một hoặc hai người trong Developers, người làm thiết kế nếu có, và một người hiểu vận hành thực tế (với Hẹn Tóc là một lễ tân).
Dành khoảng sáu mươi đến chín mươi phút cho buổi đầu. Mục tiêu là đi hết bốn bước ở mức thô, không phải làm bản đồ hoàn chỉnh.
Chuẩn bị một bảng trắng có giấy ghi chú, hoặc một bảng online. Mỗi ý một thẻ, chữ đủ to để đọc từ xa.
Mở đầu bằng câu mục tiêu của bản đầu tiên, rồi để mọi người cùng kể hành trình của người dùng. PO dẫn dắt, không đọc đáp án có sẵn.
Khi cắt lát, hỏi Developers phần nào tốn công bất ngờ. Một story trông nhỏ có thể kéo theo nhiều việc, và đó là thông tin cần cho quyết định cắt.
Kết thúc bằng ba thứ: ảnh chụp bản đồ, danh sách story của lát đầu, và câu hỏi còn mở kèm người phụ trách tìm câu trả lời.

Sau buổi mapping, các story của lát đầu đi vào đầu product backlog. Từ đó chúng đi tiếp qua backlog refinement để được làm rõ, ước lượng và viết acceptance criteria. Khi có nhiều lát và nhiều yêu cầu cạnh tranh, bản đồ là nền để bàn ưu tiên, còn tài liệu yêu cầu một trang giúp ghi lại mục tiêu, phạm vi và phần chưa làm của bản đầu tiên.

Mẫu story map và checklist buổi mapping

Hai mẫu dưới đây dùng được ngay. Mẫu thứ nhất là checklist cho người tổ chức buổi mapping. Mẫu thứ hai là bộ khung chữ của một story map, bạn dán vào tài liệu của team hoặc dùng để chép kết quả sau buổi họp.

Checklist buổi story mapping

TRƯỚC BUỔI
[ ] Câu mục tiêu: Bản đầu tiên giúp [ai] làm được [việc gì]
[ ] Nhóm người dùng chính cho bản này: [nhóm]
[ ] Người tham gia: PO, [Developers], [thiết kế], [người vận hành]
[ ] Bảng và giấy ghi chú, hoặc bảng online đã tạo sẵn
[ ] Backlog hiện có, in hoặc mở sẵn để đối chiếu

TRONG BUỔI
[ ] Đọc câu mục tiêu
[ ] Kể hành trình: người dùng làm gì trước, làm gì tiếp
[ ] Ghi hoạt động và bước bằng động từ, xếp từ trái sang phải
[ ] Treo story dưới từng bước, cần nhất ở trên
[ ] Kẻ đường cắt lát đầu tiên
[ ] Kể lại hành trình chỉ bằng lát đầu, sửa chỗ bị đứt
[ ] Hỏi Developers: story nào tốn công hơn vẻ ngoài?

SAU BUỔI
[ ] Chụp ảnh bản đồ, gửi cho người tham gia
[ ] Đưa story của lát đầu vào đầu backlog
[ ] Ghi câu hỏi còn mở, người phụ trách, hạn trả lời
[ ] Hẹn ngày xem lại bản đồ: [ngày]

Khung chữ của một story map

SẢN PHẨM: [tên]
MỤC TIÊU BẢN ĐẦU TIÊN: Giúp [ai] làm được [việc gì]
CHỈ SỐ: [chỉ số] đạt [mức] sau [thời gian]

HOẠT ĐỘNG 1: [động từ + đối tượng]
  Bước 1.1: [bước]
    Bản đầu tiên: [story đơn giản nhất dùng được]
    Bản tiếp theo: [story]
    Để sau: [story]
  Bước 1.2: [bước]
    Bản đầu tiên: [story]
    Bản tiếp theo: [story]
    Để sau: [story]

HOẠT ĐỘNG 2: [động từ + đối tượng]
  Bước 2.1: [bước]
    Bản đầu tiên: [story]
    Bản tiếp theo: [story]
    Để sau: [story]

PHẦN LÀM THỦ CÔNG TRONG BẢN ĐẦU TIÊN:
- [việc] do [ai] làm, đến khi [điều kiện]

CÂU HỎI CÒN MỞ:
- [câu hỏi], [người phụ trách], [hạn]

Phần “làm thủ công trong bản đầu tiên” đáng giữ lại. Nó nhắc team rằng bản đầu đang dựa vào sức người ở đâu, và khi nào cần tự động hóa phần đó.

Lỗi hay gặp khi làm user story mapping

Vẽ tính năng thay vì hoạt động của người dùng. Hàng trên cùng ghi “Module đặt lịch, Module thanh toán, Module báo cáo” là một sơ đồ hệ thống, không phải hành trình. Hãy viết bằng động từ của người dùng: xem dịch vụ, chọn giờ, xác nhận.
Cắt lát theo lớp kỹ thuật. Lát đầu là cơ sở dữ liệu, lát hai là API, lát ba là giao diện, nghĩa là phải đợi đến cuối mới có thứ để người dùng thử. Mỗi lát nên đi trọn từ trái sang phải, dù mỏng.
Chi tiết quá sớm. Viết acceptance criteria cho từng thẻ ngay trong buổi đầu làm buổi họp kéo dài và bản đồ khó sửa. Một dòng cho mỗi thẻ là đủ, chi tiết để dành cho refinement.
Lát đầu tiên chứa mọi thứ. Nếu lát đầu có cả đặt cọc, tích điểm và báo cáo, đó vẫn là danh sách cũ được vẽ lại. Hỏi ở từng story: thiếu nó thì người dùng có còn đi hết hành trình không?
Vẽ một lần rồi cất đi. Bản đồ cần được xem lại sau mỗi bản phát hành, khi team đã học được điều gì đó từ người dùng thật. Story ở lát sau có thể lên, xuống, hoặc bị bỏ.
PO vẽ một mình. Bản đồ do một người vẽ dễ thiếu những bước mà người vận hành hay Developers nhìn ra ngay, như việc lễ tân cần biết ai sẽ đến.

Tóm tắt

User story mapping xếp story thành bản đồ hai chiều: hoạt động của người dùng theo hàng ngang, story theo mức cần từ trên xuống.
Epic là khối việc lớn. Bản đồ cho bạn một hướng tách epic: theo các bước người dùng làm, mỗi bước bắt đầu từ cách làm đơn giản nhất.
Bốn bước: chốt người dùng và mục tiêu, dựng backbone, treo story bên dưới, cắt lát đầu tiên.
Lát đầu tiên phải đi trọn hành trình, mỗi story mang lại điều người dùng thấy được, đủ mỏng để ra mắt sớm, và có một chỉ số để đo.
Dựng bản đồ cùng team, giữ mỗi thẻ một dòng, rồi đưa story của lát đầu vào backlog để refinement.

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.

Nhận bài mới qua email

Câu hỏi thường gặp

User story mapping là gì?

User story mapping là cách xếp user story thành bản đồ hai chiều: hàng ngang là các hoạt động của người dùng theo thứ tự thực hiện, cột dọc là các story xếp theo mức cần. Cách làm này do Jeff Patton mô tả, giúp team thấy toàn bộ hành trình và chọn phần làm trước.

Epic và user story khác nhau thế nào?

Epic là một khối việc lớn, cần tách thành nhiều user story nhỏ hơn và thường làm qua nhiều sprint. User story là một mẩu đủ nhỏ để team làm xong trong một sprint và vẫn mang lại điều có ích cho người dùng.

Walking skeleton là gì?

Walking skeleton là phiên bản nhỏ nhất của sản phẩm chạy được từ đầu đến cuối hành trình, dù mỗi bước còn rất đơn giản. Trên story map, nó là lát ngang đầu tiên, và có thể dùng làm bản phát hành đầu tiên.

Nguồn kiểm tra

Bài liên quan

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.
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.