Tại Sao Cần Làm Mịn Product Backlog (Product Backlog Grooming)?

Trước tiên cần xem xét sự hiểu biết của ứng viên về vai trò của Product Owner trong quy trình Scrum:

• Một Product Owner luôn bao quát, chia sẻ, và truyền thông tầm nhìn của sản phẩm cho mọi người. Họ chia sẻ lại cho cả khách hàng và các bên có liên quan trong nội bộ của mình.
• Với quy trình, một Product Owner như là một người 'gác đền' của Product Backlog, và do đó cũng là người đại diện tổ chức 'sở hữu' sản phẩm.
• Một Product Owner phải chịu trách nhiệm tối ưu hóa giá trị mà sản phẩm cung cấp cho cả khách hàng và tổ chức.
• Nhằm mục đích tối đa hóa giá trị sản phẩm, Product Owner phải được trao quyền để đưa ra các quyết định đại diện cho doanh nghiệp liên quan tới sản phẩm.
• Nếu Product Owner không được trao quyền 'sở hữu' sản phẩm, thì họ thực chất không phải là một Product Owner, và tổ chức của anh ta cũng không thực hành Scrum.
• Product Owner là người đại diện duy nhất của các bên có liên quan ở trong và ngoài tổ chức, trong giới hạn mà nhóm quan tâm.
• Product Owner phải hiểu được Tại sao và có ảnh hưởng đến Ai và Cái gì, nhưng không nên quan tâm đến việc Làm thế nào. Quy trình phát triển sản phẩm thì luôn dưa trên sự công tác và nổ lực của cả nhóm.
• Product Owner cần phải làm việc sâu sát với Nhóm Scrum và đặc biệt là với ScrumMaster và Agile Coach – như là những đồng minh của họ.
• Product Owner nên tham gia tích cực vào những sự kiện trong Scrum, đặc biệt những buổi Làm mịn Product Backlog, Lập kế hoạch Sprint, và những buổi Sơ kết Sprint.
• Product Owner cần ngồi làm việc cùng với Nhóm Phát triển để tránh việc trì hoãn công việc, sai sót trong truyền thông, và những vấn đề khác phát sinh do khoảng cách giữa các bên.
• Trái ngược với lẽ thông thường, Product Owner hoặc không là tác giả của các User Story và cũng không là môt kỹ sư đưa ra những yêu cầu, nhưng hơn thế anh ta là một nhà ngoại giao và điều phối giữa các biên có liên quan và Nhóm Scrum.

 

Những vấn đề xảy ra đối với Product Backlog 

• Thời gian meeting quá dài dẫn đội phát triển rất mệt mỏi gây ra mất tập trung.
• Câu chuyện người dùng và giá trị người dùng kỳ vọng đạt được không được Product Owner và Stakehoders chia sẻ rõ ràng.
• Product Backlog Item – PBI (thông thường là User story hoặc các yêu cầu kỹ thuật khác) không được sắp xếp độ ưu tiên hợp lý.
• Product Owner không trình bày cho đội phát triển về mối quan hệ các User Story trong một tính năng, và các tính năng liên quan trong module mà được triển khai trong các Sprint trước đó.
• Product Owner chỉ tập trung đánh độ ưu tiên cho các User Story lớn hoặc chưa hợp lý.
• Đội phát triển thụ động trong việc khai phá vấn đề kỹ thuật, đóng gióp vào công việc viết User Story, điều kiện nghiệm thu Acceptance Criteria (hoặc User Acceptance Testing – UAT)
• Các thành viên trong đội phát triển không thực hành các kỹ thuật INVEST để phân rã các các User Story lớn (Epic).
• Đội phát triển không có cách hiểu yêu cầu giống nhau và đôi khi quá tập trung vào thảo luận chi tiết làm sao để triển khai một User Story thay vì tập trung vào hiểu câu chuyện người dùng.
• Kết quả ước lượng kích thước (Size) của User Story chỉ xác định trên một số thành viên có kinh nghiệm cụ thể thay vì cả đội phát triển.
• Những giải pháp kỹ thuật hệ thống lớn chưa sẳn sàng cho đội phát triển triển hình dung cách triển khai thiết kế.

 

Sau đây là một số mẹo tổ chức Product Backlog Grooming hiệu quả:

1) Chuẩn bị trước trước khi sự kiện Product Backlog Grooming diễn ra:

• Scrum Master cần giúp Product Owner áp dụng một số kỹ thuật để xác định lại xem độ ưu tiên mà Product Owner và Stakehoders đã đưa ra hợp lý hay chưa?
• Scrum Master cần làm việc với Product Owner xem các giá trị người dùng kỳ vọng đạt được đã được đề cập trong mỗi PBI chưa?
• Scrum Master cần làm việc với Product Owner để xác định các giả định – assumptions, ràng buộc – constraints, và phụ thuộc – dependencies liên quan đến các PBI có độ ưu tiên cao.
• Scrum Master cần làm việc với Product Onwer và System Architect để xem các giải pháp triến trúc thổng thể đã được thiết kế hoặc các PBI có độ ưu tiên ảnh hưởng đến kiến trúc như thế nào?
• Scrum Master giúp Product Owner xác định xem số lượng PBI có sẵn sàng cho đủ team triển khai trong 3 sprints kế tiếp không?
• Scrum Master xem thời gian diễn ra sự kiện có phù hợp với Sprint đang diễn ra hay không?

2) Trong quá trình diễn ra sự kiện:

• Scrum Master đảm bảo tất cả các thành viên tham gia cam kết và Product Owner phải có mặt ở sự kiện meeting này.
• Product Owner trình bày về tổng qua các BPI có độ ưu tiên cao và giúp đội phát triển nhìn thấy mối liên hệ với BPI liên quan, kế hoạch release để đội phát triển cập nhật tầm nhìn và lộ trình phát hành sản phẩm.
• Product Owner trình bày giá trị người dùng cần đạt được ở mỗi BPI, mối liên hệ nghiệm vụ với những user story khác liên quan.
• Product Owner trình bày các điều kiện nghiệp thu – UAT cho từng user story và Scrum Master tạo điều kiện để đội phát triển đóng góp để xác định điều kiện gì cần thêm, điều chỉnh hoặc loại loại trừ.
• Scrum Master tạo điều kiện cho nhóm phát triển thực hành INVEST để giúp cả team xác định Epic và tiếp tục rả thành các User Story nhỏ hơn.
• Scrum Master tạo điều kiện cho đội phát triển thông qua việc đặt câu hỏi đúng và giúp họ xác định các trở ngại về kỹ thuật, kiến trúc hiện có.
• Scrum Master tạo điều kiện cho đội phát triển thực hiện ước lượng size cho user story bằng kỹ thuật Planning Poker. Và tiếp tục qua sát hành vi bất thường của từng thành viên để đưa ra hướng huấn luyện kiệp thời.
• Cả Product Owner và Scrum Master không nói cho đội phát triển về cách thiết kế hệ thống và không đưa ra giá trị ước lượng.

3) Tiếp tục sau sự kiện kết thúc:

• Scrum Master làm việc với Product Owner và System Architect, các đội kỹ thuật liên quan để tìm hướng giải quyết cho những phản hồi của đội phát triển về kỹ thuật.
• Scrum Master làm việc chặt chẽ với Product Owner để đảm bảo những yêu cầu cần bổ xung bởi đội phát triển được nghi lại.  

Nguồn: apexglobal