Sau nhiều năm áp dụng mô hình Scrum vào phát triển sản phẩm Garoon, chúng tôi đánh giá rằng Backlog là rất quan trọng và việc thực hiện Backlog refinement sẽ đảm bảo các mục trong backlog của sản phẩm luôn ở trạng thái sẵn sàng cho các Sprint sắp tới, giúp nhóm làm việc hiệu quả và mang lại giá trị kinh doanh cho sản phẩm.
Bài viết này xin giới thiệu về Backlog refinement trong Scrum.
Backlog refinement là gì?
Product Backlog refinement là một quy trình diễn ra thường xuyên, liên tục trong quản lý dự án Scrum. Trong quá trình này, Nhóm Phát Triển và Product Owner sẽ họp lại để xem xét, tinh chỉnh và sắp xếp độ ưu tiên của các hạng mục trong Product Backlog (Product Backlog Item - PBI) và thảo luận về các chi tiết trong từng hạng mục.
Mục đích của Backlog refinement
Đảm bảo Product Backlog luôn được cập nhật và sẵn sàng để thực hiện trong các sprint sắp tới, từ đó việc thực hiện các công việc cũng sẽ được suôn sẻ hơn, tập trung tối đa vào việc tạo ra sản phẩm/phần mềm tốt nhất.
Thành phần tham dự và vai trò
Thành phần tham dự
- Product Owner
- Nhóm Phát Triển
- Scrum Master
Vai trò
Product Owner
- Làm rõ hạng mục Product backlog (PBI): Product Owner làm việc chặt chẽ với Nhóm Phát Triển để làm rõ các user story hoặc backlog, cung cấp thêm thông tin chi tiết, trả lời các câu hỏi và đảm bảo rằng nhóm hiểu được yêu cầu và mục tiêu của từng hạng mục.
- Sắp xếp độ ưu tiên: Product Owner sắp xếp độ ưu tiên của các PBI dựa trên product vision, giá trị doanh nghiệp, nhu cầu của khách hàng, nhu cầu thị trường và mục tiêu chiến lược.
- Chia tách user story: Nếu một PBI quá lớn hoặc phức tạp, Product Owner sẽ cùng với Nhóm Phát Triển để chia nó thành các user story nhỏ hơn và dễ quản lý hơn.
- Xác định tiêu chí chấp nhận (Condition of acceptance): Product Owner làm việc với Nhóm Phát Triển để xác định tiêu chí chấp nhận rõ ràng và có thể đo lường được cho từng PBI. Các tiêu chí này làm cơ sở để xác định khi nào một user story được coi là “hoàn thành” và đáp ứng các tiêu chuẩn chất lượng được yêu cầu.
- Facilitate Backlog refinement: Product Owner tạo điều kiện cho Backlog refinement diễn ra với sự tham gia của Nhóm Phát Triển và các bên liên quan khác. Product Owner khuyến khích các cuộc thảo luận cởi mở, thu thập ý kiến đóng góp và đảm bảo rằng mọi người đều có sự hiểu biết chung về PBI.
- Theo dõi Backlog refinement: Product Owner theo dõi tiến trình refinement và đảm bảo rằng nó phù hợp với tiến độ và mục tiêu tổng thể của dự án. Product Owner phối hợp cùng với nhóm để xác định mọi vấn đề hoặc trở ngại có thể ảnh hưởng đến quá trình refinement và thực hiện các hành động cần thiết để giải quyết chúng.
Nhóm Phát Triển
- Làm rõ hạng mục Product Backlog: Đặt câu hỏi và tìm kiếm sự rõ ràng về bất cứ sự mơ hồ nào để hiểu rõ ràng về các yêu cầu và phạm vi của từng hạng mục, để xác định tiêu chí chấp nhận rõ ràng hơn.
- Ước tính (Estimate): cung cấp các ước tính về nỗ lực và độ phức tạp của từng hạng mục.
- Chia tách user story: Nếu một PBI quá lớn hoặc phức tạp, Nhóm Phát Triển sẽ cùng với Product Owner chia nó thành các user story nhỏ hơn và dễ quản lý hơn.
Scrum Master
- Scrum Master tuy không có vai trò trực tiếp trong việc xác định hay sắp xếp độ ưu tiên PBI mà có vai trò đảm bảo rằng quy trình refinement diễn ra suôn sẻ, thúc đẩy giao tiếp hiệu quả giữa Owner và Nhóm Phát Triển.
- Scrum Master có thể giúp giải quyết xung đột và đảm bảo rằng nhóm tuân thủ các phiên refinement được diễn tra trong thời gian đã định.
Agenda của một buổi Backlog refinement
Khai mạc
- Nhanh chóng lướt qua agenda của cuộc họp
- Đảm bảo danh sách người tham gia là phù hợp với mục đích của cuộc họp
Rà soát các PBI
- Đi qua từng PBI
- Thảo luận từng PBI để làm rõ chi tiết, yêu cầu và tiêu chí chấp nhận
- Xem xét chia nhỏ các PBI lớn hơn thành các nhiệm vụ nhỏ hơn
- Ghi lại thông tin bổ sung hoặc thay đổi đối với từng PBI
Ước tính nỗ lực (estimate)
- Ước tính nỗ lực hoặc quy mô tương đối của các PBI
- Sử dụng các kỹ thuật ước tính như story point, T-shirt sizing
- Thảo luận và thống nhất về ước tính cho từng PBI
- Lưu ý/cân nhắc bất kỳ sự phụ thuộc hoặc kỹ thuật nào liên quan đến từng PBI
Sắp xếp độ ưu tiên
- Đánh giá mức độ ưu tiên của từng PBI, điều chỉnh khi cần thiết và cùng quyết định về thứ tự tương đối của các PBI
Tóm tắt next action
- Tóm tắt các quyết định quan trọng được đưa ra trong cuộc họp
- Xác định bất kỳ mục hành động hoặc nhiệm vụ nào cần được giải quyết và đưa ra khung thời gian cho nó
- Phân công trách nhiệm cho các thành viên trong nhóm cho các nhiệm vụ cụ thể
Tóm tắt cuộc họp
- Tóm tắt lại những nội dung chính của cuộc họp
- Xác nhận ngày và giờ của cuộc họp tiếp theo nếu thích hợp
Các cách để buổi Backlog refinement diễn ra hiệu quả
Tạo và chia sẻ chương trình họp
Giống với các cuộc họp khác, chương trình họp là điều cần thiết để duy trì các cuộc thảo luận diễn ra theo đúng mục đích họp. Vì vậy, Product Owner cần tạo và chia sẻ trước chương trình họp trước khi diễn ra để các thành viên trong Nhóm Phát triển có thể chuẩn bị trước và cho phép họ đưa ra phản hồi sớm nếu có. Việc này cũng sẽ giúp các thành viên tham gia buổi Backlog refinement tập trung vào các backlog đã chọn và hoàn thành buổi Backlog refinement thành công trong khuôn khổ thời gian của cuộc họp.
Tại công ty chúng tôi còn áp dụng quy tắc Product Owner phải đăng kí chương trình họp ít nhất trước 1 giờ để thành viên tham dự có sự chuẩn bị tốt nhất.
Sử dụng Definition of Ready
Một câu hỏi đặt ra là làm thế nào để chúng ta biết khi nào thì một PBI đã được sàng lọc đủ rõ ràng và đủ nhỏ để có thể hoàn thành trong 1 Sprint. Định nghĩa về mức độ sẵn sàng - Definition of Ready (DoR) sẽ giúp việc đó.
Definition of Ready là một bộ tiêu chí đã được các member trong Scrum team thống nhất để cho biết liệu một backlog đã sẵn sàng để nhóm xử lý hay chưa, liệt kê các điều kiện phải được đáp ứng trước khi một PBI được phép đưa vào Sprint.
Bằng cách thiết lập một DoR rõ ràng, Scrum team có thể giảm đáng kể sự mơ hồ, giúp nâng cao hiệu quả của việc lập kế hoạch và thực hiện sprint một các suôn sẻ hơn:
Tìm đúng người phù hợp tham gia Backlog refinement
Quá trình refinement backlog hiệu quả cần có những người phù hợp tham gia.
Những người phù hợp là bất kỳ ai có thể cung cấp đủ các quan điểm cần thiết để mang lại giá trị cho người dùng. Trong refinement, bạn cần phải biết thông tin về nhu cầu của khách hàng và người dùng, biết cách thiết kế, code, test và triển khai, và bất kỳ ràng buộc nào khác đối với giải pháp của mình.
Nếu những điều này không được xem xét hoặc nhận ra trong quá trình refinement thì sẽ dẫn đến khó khăn trong quá trình thực hiện công việc.
Giữ cho backlog DEEP
DEEP là một tiêu chuẩn được sử dụng khá phổ biến hướng đến việc xây dựng một Product Backlog tốt, gồm 4 tính chất:
D - Detailed appropriately (Chi tiết một cách hợp lý)
Trong Product Backlog, không phải bất cứ hạng mục công việc nào cũng cần thể hiện một cách chi tiết. Thông thường, những việc quan trọng phải làm trước sẽ được sắp xếp ở phía trên cùng của Product Backlog. Những công công việc này cần phải chi tiết để có thể đưa vào Sprint gần nhất.
Mức độ chi tiết thường giảm dần theo độ ưu tiên và cần thiết của hạng mục công việc đó.
E - Estimated – Được ước tính
Tất các các hạng mục trong Product Backlog cần phải được ước tính. Việc ước tính thường sẽ do Nhóm Phát Triển thực hiện trong buổi Backlog refinement này.
E - Emergent – Tiến hóa
Product Backlog không phải là một danh sách cố định các hạng mục cần phát triển mà sẽ luôn có sự thay đổi, cập nhật theo thời gian. Mục đích là để sản phẩm đạt được tính cạnh tranh và hữu ích cao hơn.
P - Prioritized – Tính ưu tiên
Các hạng mục trong Product Backlog cần được sắp xếp theo độ ưu tiên để tối ưu hóa giá trị của sản phẩm được phát triển. Những hạng mục nào cần đưa vào phát triển sớm sẽ nằm phía trên của Product Backlog.
Cám ơn bạn đã quan tâm đến bài viết này. Hy vọng bài viết này đã cung cấp cho bạn hiểu biết tổng quát và một số cách để nâng cao hiệu quả của quá trình thực hiện Product Backlog refinement.
Tài liệu tham khảo
- Cẩm nang Scrum - Học viện Agile
- https://www.atlassian.com/agile/scrum/backlog-refinement
