User Story và các nguyên tắc ứng dụng trong dự án Scrum

Giống như tuyên ngôn quan trọng của Agile: đặt con người và sự cộng tác lên hàng đầu, User story đặt người dùng cuối vào trung tâm của cuộc trò chuyện. Thông qua những câu chuyện của người dùng, Scrum team sẽ hiểu những gì mình đang xây dựng và giá trị mà điều đó mang lại. 

User Story là gì?

User story là mô tả ngắn gọn về yêu cầu sản phẩm dưới góc nhìn của người dùng. Trong lĩnh vực phát triển phần mềm, User story giúp tóm tắt nhanh yêu cầu của khách hàng về tính năng của sản phẩm.

Nói cách khác, User story là một câu chuyện có người dùng, việc cần làm và kết quả. Theo đó, nó được viết theo định dạng sau: 

Là <người dùng cụ thể/vai trò> 

tôi muốn <làm gì đó>

để <phục vụ mục đích nào đó>

Ví dụ: Là một người hành khách, tôi muốn đặt xe cho chuyến đi của mình.

Phân biệt User Story và Epic Story

Epic được định nghĩa như một User story lớn, có độ dài hơn một Sprint. Từ một Epic, có thể chia thành các nhiệm vụ con (task) hoặc các story nhỏ hơn tùy thuộc vào yêu cầu khách hàng. Cùng tham khảo bảng bên dưới:

Ví dụ về Epic: Là người dùng Shopee, tôi muốn biết hiện tại đang có những chương trình khuyến mãi nào để mua hàng.

Theo phân tích hành vi và tâm lý người dùng, đội lập trình ứng dụng Shopee sẽ chia ra các mục khuyến mãi khác nhau qua các story như:

#1. Là người săn sale trên Shopee, tôi muốn biết hiện tại đang có những mã giảm giá nào để áp dụng vào đơn hàng của mình.

#2. Là người quan tâm đến thời trang hàng hiệu, tôi muốn biết hiện tại các shop thời trang nào đang có chương trình giảm giá để tham khảo mua hàng.

Ai là người viết story?

Trên lý thuyết, toàn bộ các thành viên trong Scum team đều có thể tham gia viết User story. Tuy nhiên trên thực tế, Product Owner (PO) và Business Analyst (BA) thường sẽ là người trực tiếp tham gia vào việc viết story. Các thành viên khác đóng vai trò thảo luận và ghi chú. Trong trường hợp lý tưởng nhất, người dùng sản phẩm sẽ trực tiếp viết story.

Như thế nào là một story chất lượng?

Một story hoàn thiện, trước tiên phải đảm bảo dễ đọc, dễ hiểu đối với cả Scrum team, người dùng và Stakeholders. Bên cạnh đó, User story cần thỏa mãn các tiêu chí I.N.V.E.S.T. Cụ thể:

• I – Independent (Độc lập): có thể triển khai độc lập. Điều này cho phép PO tự do thay đổi thứ tự của nó trong Product Backlog mà không ảnh hưởng tới các story khác.
• N – Negotiable (Thương lượng được): được thảo luận và thống nhất giữa PO, các thành viên Nhóm phát triển và Stakeholders.
• V – Valuable (Có giá trị): User stories phải có giá trị rõ ràng với người dùng.
• E – Estimable (Ước lượng được): nhóm phát triển có thể hiểu rõ yêu cầu để ước lượng được khối lượng công việc.
• S – Small (Kích thước phù hợp): story sắp được đưa vào sản xuất cần có kích thước nhỏ vừa đủ để hoàn thành trong một Sprint.
• T- Testable (Kiểm thử được): giúp đánh giá kết quả của User Story (đã đảm bảo theo đúng yêu cầu sản phẩm hay chưa, có phát sinh lỗi hay không)

Tại sao User Story quan trọng?

User story như một cách tiếp cận nhanh, giúp nhóm hiểu được những gì người dùng cần. Nếu áp dụng  hiệu quả, nhóm dự án có thể phát hành được các sản phẩm chất lượng cao, nhận được sự tin tưởng và hài lòng từ phía khách hàng. 

User story phục vụ cho các mục đích chính:

• Tập trung vào nhu cầu của người dùng.
• Nâng cao khả năng hợp tác: việc xác lập mục tiêu – tức tính năng yêu cầu của khách hàng – đòi hỏi tinh thần hợp tác của cả nhóm nhằm đạt được mục tiêu đề ra.
• Thúc đẩy các giải pháp sáng tạo: khuyến khích nhóm cùng suy nghĩ, thảo luận và sáng tạo để đưa ra giải pháp tốt nhất cho mục tiêu cuối cùng.
• Tạo ra động lực: mỗi story như một thử thách, và việc hoàn thành story giống như một chiến thắng nhỏ, từ đó tạo động lực cho các thành viên.

Một số lưu ý khi sử dụng User story

• Giữ cho story thật ngắn gọn. Theo quy chuẩn, User story tốt nhất có độ dài trong khoảng 1 – 2 dòng; tối đa là 5 dòng.
• Luôn đặt bản thân vào vị trí của người dùng khi viết story.
• User story cần được xác nhận trước khi đưa vào triển khai phát triển.
• Tùy vào mức độ ưu tiên, nội dung của story sẽ ngày càng cụ thể (ưu tiên cao: nội dung chi tiết; ưu tiên thấp: nội dung tổng quan)
• Ước lượng User story để khối lượng công việc được kiểm soát. Nếu đòi hỏi nhiều nguồn lực cho một User story, hãy chia nó thành các story nhỏ hơn.
• Giữ mối quan hệ cộng tác với người dùng cuối.

Bài viết thuộc series Agile 101. Nhấn vào đây hoặc hashtag agile 101 để xem thêm các bài viết cùng chuyên mục.