Product Backlog nói ngắn gọn là danh sách những tính năng mà bạn mong muốn Development Team sẽ làm và biến nó thành hiện thực trong tương lai
Product Backlog là sản phẩm thuộc thẩm quyền của Product Owner và được xem như bản kế hoạch của Development Team
Product Backlog dịch ngắn gọn sang tiếng việt là “Danh sách tính năng tồn động của sản phẩm” là một danh sách các tính năng mới, thay đổi các tính năng hiện có, sửa lỗi, thay đổi cơ sở hạ tầng hoặc các hoạt động khác mà nhóm có thể cung cấp để đạt được kết quả cụ thể.
Product Backlog là nguồn thông tin tin cậy duy nhất cho kế hoạch mà một đội nhóm (development team) dựa vào để làm việc. Điều đó có nghĩa là không có gì được thực hiện mà không phải là từ Product Backlog. Tuy nhiện, sự hiện diện của một tính năng được lên kế hoạch trên Product Backlog không đồng nghĩa là nó sẽ đảm bảo được thực hiện trong tương lai. Xin nhắc lại 1 quy tắc trong tuyên ngôn Agile (Agile Manifesto) là Chấp Nhận Thay Đổi giá trị hơn Làm Theo Kế Hoạch. Vì vậy, không có gì đảm bảo 100% là Product Backlog sẽ được thực hiện.
Thông thường Product Backlog sẽ chức 4 loại thông tin sau cho sản phẩm
- Features
- Bugs
- Technical Work
- Knowledge acquisition
Ai Sẽ Quản Trị Product Backlog?
Trong Scrum, cho dù tất cả mọi người của Scrum Team (bao gồm Product Owner, Scrum Master, Development Team) để có thể thêm vào Product Backlog bất cứ khi nào họ muốn, người sau cuối đảm bảo Product Backlog được gọn gàng và theo thứ tự đó là Product Owner. Và chỉ duy nhất có Product Owner, có toàn bộ thẩm quyền để ra quyết định sau cùng đối với Product Backlog
Product Backlog Có Khác Sprint Backlog Hay Không?
Hình dạng thì có vẻ không khác nhưng định nghĩa cơ bản là khác nhau hoàn toàn. Ví dụ như:
- Product Backlog là do Product Owner quản trị, trong khi Sprint Backlog là do Development Team quản trị
- Product Backlog luôn tồn tại, trong khi Sprint Backlog được lên kế hoạch và đầu mỗi Sprint mới.
Và vì vậy, nhìn vào thì chúng ta luôn thấy Sprint Backlog luôn luôn nhỏ hơn Product Backlog.
Bao Lâu Thì Nên “Dọn Dẹp” Lại Product Backlog?
Theo quy định của Scrum Guide thì tối đa là 10% trong tổng số thời gian làm việc của Development Team. Ví dụ: Sprint dài 4 tuần thì nên dành 1 trọn vẹn 2 ngày trong thời gian để dọn dẹp Product Backlog và đảm bảo các thông tin trên đó được rõ ràng, và tương tự như vậy, Sprint 2 tuần thì dành 1 ngày, 1 tuần thì là nửa buổi.
Tất nhiên, đó chỉ là thời gian tối đa, còn dùng bao nhiêu thời gian của team vào việc đó thì hoàn toàn tuỳ thuộc và sự đồng thuận của cả team.