User Story là gì? Ví dụ? Cách viết tốt nhất?
Nội Dung
User Story là gì? Lâu lâu quay trở về những khái niệm cơ bản nhất của nghề dành cho các bạn mới vô “ngành” Business Analysis & Hệ thống thông tin quản lý 😋
Trong thời gian tới tụi mình sẽ làm series giải thích đưa ví dụ một số khái niệm và techniques BA, đặc biệt là mấy thuật ngữ Business Analysis hay có chữ User làm chúng ta nhức đầu như:
- User Story
- User Scenario
- Acceptance Criteria
- Use Case
User Story là gì?
User Story (US) là một câu chuyện có người dùng, việc cần làm và kết quả.
Các bạn sẽ sử dụng User Story khi tham gia vào một dự án Agile Scrum. User Story giúp tóm tắt nhanh yêu cầu của người dùng về một tính năng của phần mềm và được viết bằng ngôn ngữ kinh doanh, từ góc nhìn của người dùng.
Là <người dùng Foody>, tôi muốn <đặt lại đơn hàng cũ> để tôi có thể <nhanh chóng đặt món mà không mất thời gian tìm kiếm quán và chọn món ăn>.Epic Story là gì?
Epic Story kể một câu chuyện lớn tổng quát, bao gồm nhiều User Story, lớn tương đương khối lượng công việc phải làm trong nhiều đợt hay nhiều sprint. Khi bạn hoàn thành xong Epic Story nghĩa là bạn đã hoàn thành xong tất cả các story con của nó.
Ví dụ:
Epic Story
Là người dùng Foody, tôi muốn biết hiện tại có những chương trình giảm giá nào, để tôi có thể đặt món ăn với giá rẻ hơn, tiết kiệm tiền. Theo cách phân tích tâm lý và thói quen hành vì của người dùng, các nhà thiết kế và lập trình ứng dụng Foody sẽ chia ra các mục giảm giá khác nhau để thu hút người dùng qua các story như: giúp thông tin được tổ chức theo đúng mối quan tâm của Foodie.
Ví dụ User Story thuộc Epic Story
Là người dùng Foody, tôi muốn biết hiện tại ở gần chỗ tôi ở có quán nào giảm giá hay không, để tôi có thể đặt món ăn với giá rẻ hơn, tiết kiệm tiền ship và đồ ăn nóng hổi.Là người dùng Foody, tôi muốn biết các quán nào có chương trình giảm giá được cộng đồng thích nhất, để tôi có thể đặt món ngon hot với giá rẻ.Là người dùng Foody, tôi muốn biết quán ăn nào đang có chương trình giảm giá mạnh nhất, để tôi có thể đặt món với chi phí tiết kiệm nhất.
Ai là người viết User Story?
Trên lý thuyết, Scrum Member nào cũng có thể tham gia hoàn thiện User Story.
Tuy nhiên, trên thực tế khi đi làm ở một số dự án Outsourcing, bạn có thể thấy BA hoặc PO sẽ là hai người chính chịu trách nhiệm viết US, đảm bảo US có nội dung hoàn thiện (bao gồm cả Acceptance Criteria). Mọi người có thể đóng góp và thảo luận, ghi chú. Tuy nhiên, cuối cùng những nội dung được chốt trong story thường sẽ có dấu răng cuối cùng của BA hoặc PO. 🤣
Còn ở các dự án in-house hay Start-up, đôi khi bạn sẽ thấy có Developer tham gia viết luôn (vì thiếu người hoặc họ phải kiêm vai trò, hoặc đơn giản họ muốn giúp đỡ BA đẹp trai, đẹp gái, tốt tính các kiểu).
Như thế nào là một User Story hoàn thiện?
- Dễ đọc, dễ hiểu với người dùng và cả stakeholders
- I-Independent: Có thể triển khai độc lấp
- N-Negotiable: Được thảo luận và thống nhất giữa các Stakeholders (PO, Dev team, Business)
- V-Valuable: Có giá trị rõ ràng cho người dùng cuối
- E-Estimatable: Đôi ngũ lập trình có thể hiểu rõ, chia task để ước lượng được độ phức tạp
- S-Small: Story nhỏ vừa đủ, thường phải hoàn thành được trong vài ngày (max 40 giờ làm việc)
- T-Testable: Kiểm thử được
Quản lý User Story ở đâu?
User Story thường được viết trên giấy Sticky note (dán lên tường hoặc lên bảng), nhìn fancy lắm nhé. Mình hay thấy kiểu này ở công ty Startup nè. Ngoài ra, để quản lý chuyên nghiệp hơn thì mình có dùng qua phần mềm quản lý dự án như Confluence, JIRA và Trello.
Chill chill giải thích về US nhiêu đây thôi để chúng ta còn tiêu hoá thông tin. Nếu bạn có câu hỏi gì thì đừng ngại liên hệ “Chuyện của BA” hay comment dưới đây nhé.
Các bạn hãy theo dõi các kênh chia sẻ về nghề BA, PO của Khang & Mia
- Blog: https://duykhang.com/category/business-analyst/
- Facebook page: Chuyện của BA
- Youtube: Mia Thu Hương
Cám ơn các bạn!
– Mia
