User Story Mapping là gì? Ứng dụng thế nào?

Để có thể tối ưu hoá được giá trị sản phẩm của mình, các Product Owner phải làm chủ được Product backlog. Nhưng việc quản lý Backlog không hề dễ dàng. Các Product Owner luôn gặp khó khăn trong việc xác định sự ưu tiên của các Product Backlog Items. Sự khó khăn này bắt nguồn từ việc các Product backlog thường chứa đựng rất nhiều thứ khác nhau, đến từ nhu cầu của nhiều bên khác nhau: Khách hàng, CEO, các phòng ban… hay còn là các lỗi hoặc nợ kỹ thuật cần được xem xét.

Sự hỗn tạp này khiến nhiều Product Owner bối rối, và gặp khó khăn khi đưa ra quyết định nên ưu tiên Product Backlog Items nào trước. Hay làm sao kết nối những ưu tiên đó với mục tiêu chung của sản phẩm hoặc doanh nghiệp. Với lý do đó Jeff Patton đã nghĩ ra một phương pháp gọi là User Story Mapping, để giúp Product Owner có thể dễ dàng hơn trong việc sắp xếp thứ tự của các Product Backlog Items (PBIs).

Nói đơn giản: User Story Mapping là một phương pháp sắp xếp phân loại, trực quan hoá Product backlog, giúp cho Product backlog của bạn trở nên dễ quản lý hơn, và thể hiện được sự liên kết giữa người dùng và giá trị mà bạn muốn xây dựng cho họ.

Phương thức này vô cùng đơn giản (Xem hình dưới):

User Story Mapping

​Bạn sẽ cần 1 bức tường rộng để để thực hiện, khi là một Product Owner tôi thường đặt nó ở gần vị trí tôi ngồi nhưng vẫn dễ dàng để các bên liên quan có thể xem hoặc cập nhật dễ dàng khi cần thiết.

Product Backlog nếu được sắp xếp theo phương thức này sẽ vô cùng trực quan, giúp Product Owner sắp xếp được các nhu cầu cho sản phẩm của mình, dành cho ai, mang lại giá trị gì, và thể hiện được sự sắp xếp ưu tiên cho các PBIs.

1. Người dùng, đối tượng sử dụng sản phẩm (tầng cao nhất cần phân định rõ, người dùng sản phẩm gồm những ai, thuộc phân nhóm nào?). (Who)
2. Backbone/ Main activity: Đây là luồng hoạt động chính, nhu cầu hay mục đích chính của người dùng sản phẩm của bạn. (Ví dụ: Nhu cầu mua hàng của người mua hàng, hay nhu cầu bán hàng hoá của người bán hàng, nếu bạn đang xây dựng một trang bán hàng trực tuyến.) Nhu cầu này phải mang đến giá trị chính cho người dùng đó.
3. Epic: là tầng nhỏ hơn được chia nhỏ từ tầng backbone, thể hiện luồng những hoạt động của người dùng. Ví dụ: từ xác định nhóm người dùng (Who) - Người bán hàng -> có nhu cầu quản lý người mua hoặc hàng hoá của họ (Backbone) ->  Phần quản trị - backend quản lý sản phẩm tồn đọng (Epic) dành cho người bán hàng.
4. Một khi bạn đã có được Backbone và Epic, hãy nghĩ về người dùng của “phần sản phẩm” đó cần gì? Điều gì sẽ mang lại giá trị cho họ, và viết lên User story cho họ (chức năng), những lỗi cần cải thiện trong phần hệ thống đó, hay một cải tiến về hiệu năng nào đó. Ví dụ: trong trang login của người mua hàng/ khách hàng cuối có chức năng đăng nhập bằng tài khoản mạng xã hội, để giúp người mua hàng dễ dàng đăng ký và đăng nhập và không phải nhớ quá nhiều tài khoản v.v. Đặt người dùng quan trọng nhất từ trái sang, và PBIs nào trên cùng sẽ được thực hiện vào Sprint tiếp theo.

Các gợi ý:

• Nên làm với những người dùng quan trọng nhất, dựa trên họ, xây dựng, Backbone/ Main activity, có thể giúp và mang lại giá trị chính cho họ, sau đó chi tiết đến những Epic, những hoạt động và cuối dùng là PBIs cho người dùng đó. Sau đó tiếp tục với những User khác ít quan trọng hơn.
• Trong Backbone có thể có nhiều Epic, phần Epic: có thể thể hiện User Flow nếu muốn, chiều của User Flow sẽ là từ trái qua. (Ví dụ: Nếu Backbone là Quản lý đơn hàng -> Epic bao gồm: người bán hàng Login -> vào trang quản lý -> Quản lý đơn hàng chi tiết -> thực hiện ship hàng v.v)

​Một điều chú ý rằng, đây là một kỹ thuật để sắp xếp Product Backlog trở nên trực quan hơn, nên nó vẫn mang những tính chất cần có của một Artifact đó là tính minh bạch, nên bạn phải đảm bảo: Nó luôn được cập nhật, ai liên quan cũng có thể xem được dễ dàng, và ai cũng có thể hiểu được nó.

​Note: Đây là một ý tưởng cơ bản, phụ thuộc vào mỗi product khác nhau, các bạn sẽ có cách sắp xếp khác nhau cho phù hợp. Quan trọng nhất là nó phải giữ được tính chất cần có của một Product Backlog.
​