Bạn phải làm gì khi thực hiện Product Backlog refinement?
Refinement Meeting
Scrum tuyên bố rằng:
Scrum Team quyết định khi nào và theo cách nào để hoàn thành refinement. Refinement thường không chiếm quá 10% công suất làm việc của Development Team
Thực tế điều này nghĩa là trong suốt sprint một Scrum Team phân bổ 3 time slots mỗi slot 1 h để làm việc với Product Owner và stakeholders cho việc refinement. Thời lượng như thế đủ cho Product Owner và Development Team tạo được một dòng liên tục các item chuyển thành trạng thái Ready. Lý tưởng thì Scrum Team luôn có sẵn 2 sprint của các task/item đã ready trên Product backlog sao cho nếu Product Owner nghỉ phép hoặc nghỉ ốm thì cả team vẫn tiếp tục có việc để làm. Nếu không sẽ có tình huống team phải vật lộn vất vả để có được các item ở trạng thái ready, cho sprint trước mắt.
Các item còn mơ hồ trở thành đầu vào cho quá trình Product Backlog refinement và Development Team phải mất nhiều thời gian thảo luận về các giải pháp khác nhau có thể lựa chọn thì đây là dấu hiệu của việc làm chưa đúng đắn Product Backlog refinement. Team dành ra cố định 10 phút để thảo luận 1 item. Sau 10 phút nếu không có một định hướng giải pháp nào được chốt thì cuộc thảo luận được dừng lại và Scrum Team phải quyết định tiếp theo phải làm gì. Chẳng hạn Product Owner có thể sẽ phải kiểm tra lại với các stakeholders về một số giả định, hoặc Development Team sẽ phải làm một số home work để nghiên cứu thêm về giải pháp.
Việc thảo luận trực tiếp giữa Development Team với các stakeholder có lúc là cần thiết để làm product backlog refinement, vì hai bên có thể tránh được việc thực hiện ước lượng dựa trên giả định mâu thuẫn nhau.
Spikes
Có nguồn gốc từ Extreme Programming, Spike [việc đột xuất] được định nghĩa là một story hoặc một task nhằm trả lời cho một câu hỏi hoặc nhằm thu thập thông tin, chứ không phải nhằm làm ra một sản phẩm.
Khi làm Product Backlog refinement một team có thể quyết định làm một spike. Spike này sẽ được đưa vào Sprint backlog hiện tại. Mong muốn là làm xong spike này sẽ có một kết quả, trước khi có buổi họp tiếp theo, giúp cho một item đang mơ hồ sẽ tiến gần hơn đến trạng thái ready.
Hai đặc tính của một spike là
- Có mục tiêu và kết quả rõ ràng một đặc trưng giống như mọi item khác của sprint backlog.
- Có khung thời gian cố định [time-boxed] để hoàn thành. Ví dụ 1 h. Chỉ sau khung 1 h đó bạn mới quyết định có nới thêm thời gian cho spike hay không.
Rủi ro lớn nhất khi đưa thêm một spike vào là Scrum Team dường như khuyến khích việc làm ra kế hoạch và thiết kế chi tiết hơn mức cần thiết. Bạn cần nhớ rằng spike là ngoại lệ chứ không được chấp nhận là thông lệ của Scrum Team.
3 công việc cần làm trong Product Backlog Refinement
Với một Product Owner thì thực hiện Product Backlog Refinement là một trọng tâm công việc. Chất lượng làm Product Backlog Refinement do kỹ năng & kinh nghiệm của Product Owner quyết định. Một item được đẩy vào quá trình refinement thì đòi hỏi người ta phải có một ý tưởng rõ ràng rằng muốn đạt được kết quả gì từ item đó. Ba việc bạn phải làm để thực hiện Product Backlog Refinement là: Slicing [chia nhỏ], Estimating [ước lượng] và Acceptance criteria [Các tiêu chí nghiệm thu].
Slicing
Mục đích của Product Backlog refinement là làm cho một item trong Product Backlog đạt đến trạng thái Ready. Có nghĩa là item phải trở nên đủ nhỏ để có thể bắt đầu đưa vào Sprint để làm [phát triển]. Điều này đôi khi cần sự sáng tạo. Story splitting cheat sheet là một công cụ hay giúp cho Team khám phá các khả năng chia nhỏ một item. Ở đây có vai trò của Scrum Master hoặc Agile Coach hướng dẫn cho team chia nhỏ item đến mức độ nào là vừa đủ.
Estimation
Gây tranh cãi nhất khi áp dụng Scrum Framework chính là khi team ước lượng số story point. Scrum Framework chỉ đơn giản nói rằng bạn phải ước lượng số điểm cho mỗi item, mà không hướng dẫn ước lượng như thế nào. Bất kể cách nào phù hợp với hoàn cảnh thực tế của bạn đều OK.
Gắn một số điểm cho một item không có nghĩa là bạn đã đưa item đến trạng thái ready. Product backlog refinement sẽ trở nên dễ dàng hơn rất nhiều nếu như mọi người tham gia thảo luận đều thống nhất với nhau rằng mọi ước lượng mặc định là KHÔNG chính xác. Nếu không cùng nhau hiểu rõ điểm này thì các cuộc thảo luận refinement sẽ dẫn đến sự bực bội cho người tham dự. Sau đây là những kỹ thuật giúp team đưa ra ước lượng số story point.
T-shirt sizing
Kỹ thuật này dễ làm và nhanh chóng. Mọi người chọn ước lượng một item theo size S, size M hay size L giống như là đánh cỡ cho một cái sơ-mi vậy
Magic estimation
Một cách ước lượng nhanh chóng cho nhiều item cùng một lúc.
Planning poker
Kỹ thuật ước lượng nổi tiếng nhất và được quảng bá bởi Mike Cohn. Rất tốn thời gian để làm nhưng hiệu quả.
Acceptance Criteria
Viết các tiêu chí nghiệm thu cho một feature mới là điều người ta đã làm từ nhiều thập kỷ nay. Cả Scrum team hợp tác cùng định nghĩa các tiêu chí nghiệm thu, và tốt nhất là trong quá trình làm Product Backlog refinement. Mức độ chi tiết của các tiêu chí nghiệm thu phụ thuộc nhiều vào trình độ và kinh nghiệm của các nhân sự tham gia và nhất là vào chất lượng tương tác giữa Product Owner và Development Team.
Mức độ hiệu quả của buổi họp làm Product Backlog refinement sẽ tăng lên nhiều nếu như Product Owner hiểu được Development Team cần độ chi tiết đến đâu. Chỉ cần sử dụng một teamplate thể hiện user story cũng có thể là đủ để một backlog item đạt trạng thái ready. Product Owner cần phải dành ít thời gian viết các tiêu chí nghiệm thu và dành nhiều thời gian hơn để thực hiện kiểm thử thường xuyên và có thể điều chỉnh lại các tiêu chí cho phù hợp.
Theo Stephan van Rooden
Product Backlog Refinement explained
- #ProjectManagement
- #PMP
- #PMPExam
- #HoChiMinh
- #QuanLyDuAn
- #TemplatesForProjectManagement