USER STORY

User Story là một tài liệu sơ giản về yêu cầu sản phẩm với góc nhìn người dùng. Thông thường, User Story do khách hàng, hoặc đại điện của khách hàng viết, tuy nhiên nếu có sự cộng tác của Nhóm Phát triển thì nhóm và khách hàng sẽ có sự chia sẻ hiểu biết về sản phẩm tốt hơn.

Với những nhóm dùng bảng vật lý thì User Story được viết trên các thẻ nhỏ hoặc trên các miếng giấy dán. Nhóm có thể dán các thẻ này lên bảng như những hạng mục của Product Backlog.

User story có định dạng:

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

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

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

User story nên theo mô hình 3C:

• Card (Thẻ): Thông thường, User Story được viết trên một thẻ nhỏ. Điều đó có nghĩa là nó thường ngắn để có thể viết trên một thẻ. Nếu bạn có viết trên một hệ thống khác như Trello, Jira, Assembla hoặc Redmine cũng nên giữ nó ngắn.
• Conversation (Trao đổi): Story là những câu truyện giữa khách hàng và Nhóm Phát triển. Do đó chi tiết của User Story được làm rõ thông qua các cuộc trao đổi (nên là trực tiếp) với khách hàng. Nội dung của User Story sẽ ngày càng cụ thể tuy thuộc vào độ ưu tiên của nó (nếu ưu tiên cao, cần làm sớm thì sẽ có nọi dung chi tiết, nếu ưu tiên thấp thì chỉ chứa nội dung chung).
• Confirmation (Xác nhận): User Story có tiêu chí chấp nhận (Acceptance Criteria) để khách hàng suy nghĩ cụ thể về yêu cầu và Nhóm Phát triển có thể hiểu yêu cầu rõ hơn và xác nhận được khi nào sản phẩm hoàn thành.

User story cũng nên tuân theo các tiêu INVEST:

• Independent (Độc lập): Độc lập với các User Story khác. Điều này giúp Product Owner tự do thay đổi thứ tự của nó trong Product Backlog và Nhóm Phát triển dễ dàng phát triển.
• Negotiable (Thương lượng được): Tính đàm phán được giúp cho Nhóm Phát triển và Product Owner cùng nhau xây dựng nội dung chi tiết và phụ hợp hơn cho những thay đổi trong tương lai. Nếu không có tính năng này thì việc thích nghi với sự thay đổi gặp khó khăn.
• Valuable (Có giá trị): User Story phải có giá trị với khác hàng. Những người làm kỹ thuật có thể thấy việc làm khung làm việc, cơ sở dữ liệu hoặc thiết kế là quan trọng. Tuy nhiên với khách hàng thì không. Điều này rất lưu ý với những Product Owner có nền tảng kỹ thuật, có thể họ sẽ biết Agile thành một mô hình phát triển Waterfall trá hình!
• Estimable (Ước lượng được): Một User Story tốt có thể ước lượng được mặc dù không cần chính xác. Những User Story lớn hoặc không rõ ràng thường khó để ước lượng. Khả năng ước tính được giúp nhóm ước lượng tốt hơn công việc sẽ làm và cả kế hoạch phát hành. Rõ ràng điều này phụ thuộc vào khả năng của nhóm.
• Sized appropriately (Kích thước phù hợp): Những User Story sắp được đưa vào sản xuất cần có kích thước nhỏ (đồng nghĩa với việc được mô tả rõ ràng hơn), những User Story chưa được đưa vào sản xuất trước mắt có thể có kích thước lớn hơn.
• Testable (Kiểm thử được): Nếu nhóm phát triển biết như thế nào là User Story đó hoàn thành – có thể kiểm thử được rõ ràng thì họ có thể hiểu rõ hơn công việc của mình, ít gây hiểu nhầm. Các mô hình phát triển BDD hoặc ATDD có giá trị vì yêu cầu có thể kiểm thử được.