Product Backlog Refinement – Phần 1
Một nhiệm vụ khó khăn bậc nhất của Scrum là làm Product Backlog Refinement. Câu hỏi tôi thường phải trả lời khi hướng dẫn về Scrum là “Làm Product Backlog Refinement là làm những gì?”; “Làm thế nào để ngăn việc thảo luận lan man hoặc việc đi vào quá chi tiết?”; “Ai cần tham dự?”; “Ước lượng nên đưa ra khi nào?”
Trong blog này tôi sẽ giúp bạn có được một số practice tốt và hướng dẫn bạn về các hoạt động cần làm trong Product Backlog Refinement. Sẽ có 3 chủ đề là:
- Trước khi bạn đưa một item vào cuộc họp
- Làm gì trong một buổi họp nhằm mục tiêu Product Backlog Refinement?
- Cách dẫn dắt một buổi họp làm Product Backlog Refinement
‘Ready state’
Mục đích của Product Backlog Refinement là làm việc với Scrum Team và các stakeholders đưa các Product Backlog items vào trạng thái ‘ready state’. Điều đó nghĩ là gì? Nghĩa là development team có được ý tưởng về một backlog item thỏa mãn:
- Đủ rõ ràng cụ thể, sao cho họ hiểu được stakeholders muốn cái gì và vì sao lại muốn có cái đó.
- Đủ nhỏ, sao cho item có thể được làm hoàn chỉnh trong vòng 1 sprint (mà tốt nhất là chỉ vài ba ngày) đáp ứng đúng định nghĩa DONE (HOÀN THÀNH)
Hoạt động này là sự tương tác trao đổi, thảo luận giữa Product Owner, Development Team và các stakeholders. Nếu bạn nghĩ rằng có một mẫu thiết kế chuẩn cho một item đạt mức ‘Ready state’ thì bạn đã nhầm. Khi một item được gọi là ‘Ready state’ nó phụ thuộc nhiều khía cạnh như kinh nghiệm của Scrum Team hoặc kiến thức về sản phẩm. Thậm chí cái Ready state khác nhau theo từng item tùy theo cân nhắc của Development Team. Khá mất thời gian để làm Product Backlog Refinement và nếu bạn biết cách làm một cách đúng đắn thì sẽ tiết kiệm được nhiều công sức khi bước sang Sprint planning.
Trước khi đem một item vào cuộc họp
Phần quan trọng nhất của Product Backlog refinement thực ra được thực hiện trước khi bạn bắt đầu refining nó. Sử dụng thời gian Scrum Team kém hiệu quả nhất chính là khi bạn refine một item không có đóng góp gì cho product vision. Với vai trò là Product Owner bạn cần hiểu đúng stakeholder cần cái gì và vì sao lại cần.
Nếu hiểu lý do ẩn sau một yêu cầu/mong muốn thì một Product Owner dễ dàng phán xét liệu yêu cầu đó có đóng góp vào đạt được mục tiêu dài hạn của sản phẩm hay không. Nếu không có hiểu biết này Product Owner rất dễ đi trệch khỏi những item nằm trong product vision, chẳng hạn mở ra cơ hội mới cho thị trường, mà lại bị thuyết phục tập trung vào những item chỉ phục vụ cho lý do tồn tại của chính Product team mà thôi. Lưu ý rằng một Product backlog có đến 100 item cũng có thể coi là quá nhiều đối với 1 Product team.
3 chặng của mức độ Readiness
Tính minh bạch ‘transparency’ là một trụ cột giá trị trong Scrum framwork. Product Backlog phải được nhìn thấy tường minh bởi Scrum Team và các stakeholders từng item, thứ tự ưu tiên và mức độ “ready state” của từng item đó. Hãy xem sơ đồ Kanban board sau đây về 3 chặng mức độ Readiness của Product Backlog.
Mỗi một Product Backlog item thông thường sẽ đi qua 3 cuộc họp refinement thì mới đạt đến ‘ready state’: T-shirt sizing, Magic estimation và Ready for Sprint.
Thoạt tiên khi một item được nêu ra bởi stakeholder Development Team sẽ cố gắng ước lượng thô về size của nó. T-shirt sizing là một cách ước lượng thường dùng: người ta tuy không biết chính xác thế nào là cỡ S nhưng thường dễ nhất trí với nhau về mối tương quan giữa cỡ S với cỡ M và cỡ L của các t-shirt. Mức độ công sức bỏ ra làm một item cũng được ước lượng theo size S, size M hay size L, tương tự như sizing của sơ mi vậy. Bước tiếp theo là gắn cho item một số story point nào đó. Phương pháp được sử dụng ở đây là Magic estimation hoặc Silent estimation không cần tốn thời gian thảo luận sâu trên mỗi item. Bước cuối cùng là Development Team làm Planing poker: ước tính size của item bằng một trong các số Fibonacci (1, 2, 3, 5, 8, 13, 21 …) – một kỹ thuật ước lượng tốn thời gian nên chỉ thực hiện với những item mà bạn thực sự muốn triển khai và cần dựa theo những ước lược bạn từng làm trước đó và đã chứng tỏ đáng tin cậy.
Trong blog tiếp theo tôi sẽ thảo luận với các bạn về những gì diễn ra trong một cuộc họp Product Backlog refinement.
Theo Stephan van Rooden
