Cách Viết User Story Hiệu Quả Cho Business Analyst

User story là gì?

Theo Wikipedia, User Story là một mô tả ngắn gọn về nhu cầu của người dùng trong một hệ thống phần mềm. Nó được viết từ góc nhìn của người dùng và tập trung vào giá trị mà họ mong muốn nhận được. User story cần trả lời được 3 câu hỏi này:

• Who: Ai là người sử dụng tính năng này? (Vai trò)
• What: Người dùng muốn làm gì? (Mục tiêu)
• Why: Nười dùng muốn làm điều đó?  (Lý do)

Ví dụ:  As a customer, I want to place an order online, so that I can receive the product without leaving my home.

User story có thể được viết ngắn gọn hoặc dài hơn ví dụ trên tùy thuộc vào nhu cầu của dự án. Tuy nhiên, BA cần chú ý là các user story phải rõ ràng, súc tích và có thể đo lường được.

Việc viết user story là một chuyện, BA còn phải biết được cách viết test case để làm sao tester có thể kiểm tra lại sản phẩm xem có bị sai sót chỗ nào hay không.

Acceptance Criteria là gì?

Acceptance Criteria hay còn gọi là “tiêu chí chấp nhận” hoặc "định nghĩa của việc đã hoàn thành". Acceptance Criteria (AC) là một tập hợp các điều kiện phải được đáp ứng để user story xem là hoàn chỉnh và được người dùng, khách hàng hoặc bất kỳ hệ thống nào khác chấp nhận. AC giúp chúng ta xác định rõ ràng những yêu cầu và kỳ vọng của khách hàng hoặc người dùng cuối, từ đó đảm bảo rằng sản phẩm của mình sẽ đáp ứng được những yêu cầu đó.

Cách viết AC có thể theo 2 phương pháp chính:

• Rule-based: Dựa trên danh sách kiểm tra (checklist) các quy tắc cần tuân theo.
• Scenario-based: Sử dụng cấu trúc “Given/When/Then” để mô tả các tình huống cụ thể.

Acceptance Criteria thường được trình bày dưới dạng các câu lệnh, nó có thể được xác nhận là đạt hay không đạt. Mỗi một user story hoặc product backlog item phải có ít nhất một acceptance criteria.

Mẹo viết user story hiệu quả dành cho BA

Dưới đây là một số cách để viết user story hiệu quả từ kinh nghiệm của chuyên gia:

Xác định người dùng và mục tiêu

Luôn đặt người dùng làm trọng tâm và viết User Story dựa trên nhu cầu, mong muốn và mục tiêu của họ. Sử dụng ngôn ngữ đơn giản, dễ hiểu để mọi người, kể cả những người không am hiểu kỹ thuật, đều có thể nắm bắt được. Tránh sử dụng thuật ngữ chuyên ngành hoặc ngôn ngữ kỹ thuật trừu tượng.

Ví dụ: Tính năng thanh toán bằng ví điện tử trên ứng dụng mua sắm

• Người dùng chính: Người mua sắm trực tuyến
• Mục tiêu:
  • Tạo trải nghiệm thanh toán nhanh chóng và tiện lợi
  • Tăng tỷ lệ thanh toán thành công
  • Giảm thiểu việc hủy đơn hàng do thanh toán phức tạp

Viết dạng chủ động

Mẹo hữu ích mà Topchuyengia muốn chia sẻ với bạn là phải viết theo hướng chủ động. Hãy thử viết từ góc độ user, nhấn mạnh vào nhu cầu thực sự và cấp bách của họ, cũng như việc user mong muốn chúng ta giải quyết vấn đề này. 

Chúng ta không nên mô tả những gì hệ thống có thể cung cấp. Thay vào đó hãy tập trung vào suy nghĩ “User cần gì”. Bạn nên nhớ:

• Nếu “System offer được gì cho user” thì gọi là Solution Space.
• Còn nói theo cách “User cần gì” là Problem Space.

Do đó lưu ý khi viết, chúng ta chỉ nên nói đến Problem Space, tức là “User đang bị như thế này và user đang muốn cái này”. Tuyệt đối không cần đưa ra Solution chi tiết gì vào đây. 

Ví dụ, một User Story tốt có thể là: “Là nhà tuyển dụng, tôi muốn được thông báo về lịch hẹn phỏng vấn trước hai ngày để có thời gian chuẩn bị”. Điều này mở ra khả năng giải quyết vấn đề khác nhau, có thể nhận qua email, SMS, zalo, in-app,.

Tránh viết như sau: “Là nhà tuyển dụng, tôi muốn hệ thống gửi thông báo trên ứng dụng về lịch phỏng vấn trước 2 ngày”. Điều này giới hạn phạm vi giải pháp và nó theo góc nhìn “system offer được gì”. Vô hình chung đã khóa suy nghĩ mình lại, không nghĩ thoáng ra được.

Nhớ rằng, chúng ta chỉ nên tập trung vào việc xác định vấn đề trong không gian vấn đề, không phải đưa ra giải pháp chi tiết ngay từ đầu.

Áp dụng nguyên tắc INVEST

Bạn có thể đọc lại nguyên tắc viết User Story INVEST ở bên trên để hiểu thêm về cách viết này.

Đơn giản nhưng đầy đủ

Một user story tốt nên đủ ngắn gọn để dễ hiểu nhưng đủ thông tin để các stakeholder và nhóm phát triển có thể làm việc với nó mà không cần phải giải thích quá nhiều.

Tham gia cộng tác

Bạn nên hợp tác với end-user, các stakeholder khác và đội ngũ phát triển để đảm bảo rằng mọi người đều có cùng sự hiểu biết về user story và mục tiêu của nó.

Cập nhật User Story thường xuyên khi có thay đổi hoặc phát sinh yêu cầu mới. Đừng quên sử dụng các công cụ quản lý dự án để theo dõi tiến độ và đảm bảo User Story được hoàn thành đúng thời hạn.

Ví dụ: Bạn nên có nhiều cuộc họp định kỳ để giải đáp thắc mắc và chắc chắn rằng họ hiểu bạn.

Luôn học hỏi và cải thiện

Bạn có thể tham gia các khóa học BA, hội thảo hoặc đọc sách về viết User Story hoặc tư vấn 1:1 trên Askany để được chia sẻ kinh nghiệm và học hỏi từ các chuyên gia BA khác.

Đánh giá khả thi và đo lường hiệu quả

Đánh giá khả năng thực hiện và đo lường hiệu quả của User Story một cách rõ ràng. Sử dụng các tiêu chí cụ thể để xác định mức độ hoàn thành của tính năng.

Ví dụ: Xác nhận tính thực tế và đo lường kết quả của User Story "Tìm kiếm sản phẩm bằng giọng nói" một cách chính xác. Xem kết quả trả về có chính xác hay không để đánh giá mức độ hoàn thiện của chức năng.

Sử dụng "So that, In order to"

Bạn cũng có thể áp dụng cấu trúc "So that, In order to" để xác định tại sao tính năng cần phải được triển khai. Điều này giúp làm rõ mục đích và lợi ích của tính năng đó.

Sử dụng công cụ 3C

Bạn có thể sử dụng công cụ 3C bao gồm (Card, Conversation, Confirmation) để thu thập và xác nhận yêu cầu từ người dùng.

Ngoài ra, chuyên gia của Askany khuyên bạn nên tổ chức các buổi workshop với người dùng để thảo luận và ưu tiên các User Story. Đồng thời sử dụng các template User Story để tiết kiệm thời gian và đảm bảo tính nhất quán.

Các ví dụ về cách viết user story

User story là một công việc nhỏ nhất nhưng vô cùng quan trọng trong dự án Agile và Scrum, giúp định hình nhu cầu và mong muốn của người dùng cuối cùng một cách rõ ràng.

Trong khuôn khổ Agile, user story thường tuân theo một mẫu đơn giản. Nó sẽ mô tả “ai”, “cái gì” và “tại sao” theo một yêu cầu cụ thể.

• Who wants something?
• What do they want?
• Why do they want it?

Mẫu sau đây là một trong những mẫu phổ biến nhất:

“As [persona], I want to [action], so that I can [benefit].”

Đối với mỗi story, người viết sẽ bao gồm một nhân vật người dùng, hành động họ muốn thực hiện hoặc khả năng họ muốn có, và kết quả mà họ hy vọng đạt được. Dưới đây là một số ví dụ để dễ hình dung:

1. As an online gamer, I want to have a multiplayer option, so that I can play online with my friends.
2. As a student, I want to access course materials online, so that I can learn anytime, anywhere.
3. As an office worker, I want to be able to schedule meetings online, so that I can save time and effort
4. As an ebook reader, I want to be able to adjust the font size, so that I can read books more comfortably

Về cơ bản, User story không khác gì User Requirement. Nhưng với User story thì chỉ gói gọi trong một tính năng rõ ràng, cụ thể mà User cần. Nó mang lại sự gọn gàng, có tổ chức, trình tự và giúp BA dễ quản lý hơn.

Tại sao cần có user story?

Đối với những ai mới làm quen với Agile thì user story có vẻ như là một bước không cần thiết. Họ nghĩ rằng, chỉ cần chia dự án lớn (epic) thành hàng loạt task nhỏ (nhiệm vụ/công việc) và tiến hành lập trình là xong. Nhưng user story mang lại cho nhóm developer thông tin quan trọng và là cầu nối liên kết các task với giá trị mà task đó mang lại.

Để dễ dàng hình dung hơn, dưới đây là một số lợi ích của User story mang lại:

• Tập trung vào người dùng: User story giúp coder tập trung vào người dùng cuối (end-user). Họ là những người trực tiếp sử dụng sản phẩm phần mềm được tạo ra. Danh sách task chỉ giúp nhóm coder tập trung vào những nhiệm vụ cần được hoàn thành. 
• Thúc đẩy sự hợp tác: User story tạo điều kiện cho sự hợp tác giữa các bên liên quan. Với mục tiêu đã đề ra, mọi người có thể cùng nhau quyết định cách tốt nhất để phục vụ người dùng và giúp nhóm đạt được mục tiêu đó.
• Đưa ra nhiều giải pháp sáng tạo: User story thúc đẩy tư duy phản biện và sáng tạo, khuyến khích nhóm suy nghĩ quyết đoán (critical thinking) để đưa ra cách tốt nhất giải quyết hiệu quả.

Nguyên tắc đánh giá user story

Sau khi đã biết cách viết user story, Topchuyengia sẽ gợi ý cho bạn nguyên tắc INVEST để đánh giá user story:

• I - Independent (Độc lập): BA cần đảm bảo mỗi user story đều có khả năng phát triển độc lập mà không phụ thuộc vào các user story khác.
• N - Negotiable (Thương lượng): User story phải linh hoạt để điều chỉnh dựa trên giai đoạn triển khai và phản hồi từ người dùng. 
• V - Valuable (Có giá trị): User story cần thể hiện được lợi ích, giá trị cho người dùng, khách hàng và stakeholders. 
• E - Estimable (Đo lường): User story phải đo lường được thì BA mới có thể quản lý nguồn nhân lực cần thiết để phát triển user story. 
• S - Small (Nhỏ): Kích thước của user story cần đảm bảo hoàn thành trong một Sprint (bao gồm quá trình kiểm thử). 
• T - Testable (Kiểm tra): Cuối cùng, BA cần đảm bảo user story có thể được kiểm tra dễ dàng (nghĩa là đáp ứng nhu cầu khách hàng, đủ rõ ràng để đánh giá tính hoàn thiện của user story).