Product backlog là gì?
Product Backlog là kho dự trữ tính năng/ công việc đi từ Epic (những mảng việc lớn, có thể phải dành vài tháng để hoàn thiện) đến Features (các tính năng, cấu phần nhỏ hơn của mảng việc lớn, có thể làm theo vài tuần) đến User Stories (chi tiết hạng mục phát triển được quy về thời lượng vài ngày)
Không chỉ đội phát triển phần mềm mới sử dụng được Product backlog, trên thực tế tại fundacionfernandovillalon.com tất cả các team đều sử dụng được Product Backlog như là một kho lưu trữ các hạng mục công việc.
Nếu như Product Backlog của team phát triển sản phẩm là danh sách các tính năng, thì Product Backlog của team Marketing là danh sách các sản phẩm hướng tới mục tiêu tạo lead như 1 tài liệu freebie, video, landing page giới thiệu sản phẩm…
Trong Product backlog, các tính năng mong muốn này sẽ được sắp xếp theo thứ tự ưu tiên như thế nào?
Thông thường PO có thể dựa trên các yếu tố sau:
Giá trị đem lại cho khách hàng, Độ khó của việc triển khai các hạng mục, Mức độ feedback sớm hay muộn, Mối quan hệ tương quan giữa các task.Bạn đang xem: Product backlog là gì
Ai sở hữu Product Backlog?
Product Owner là người chịu trách nhiệm quản lý và bảo trì Product Backlog. Cụ thể họ sẽ:
Xác định các tính năng, hạng mục cần được phát triểnĐánh giá độ ưu tiên của các hạng mục và sắp xếp chúng theo thứ tự ưu tiên từ cao đến thấpLàm mịn các hạng mụcLàm rõ và đảm bảo các hạng mục này minh bạch tới tất cả các bênThế nào là 1 Product Backlog tốt?
Roman Pichler và Mike Cohn đã đề xuất các đặc điểm của 1 Product Backlog tốt. Tuân theo quy tắc DEEP - viết tắt các chữ cái đầu của các đặc điểm sau:
Detailed appropriately - Đủ chi tiết hợp lý
Không phải hạng mục nào trong Product Backlog cũng đang ở cùng 1 mức độ chi tiết tại một thời điểm.
Product backlog items đa dạng về kích thước
Các hạng mục công việc dự định làm trước nên được xếp ở phía trên cùng của backlog. Các hạng mục này cần nhỏ và chi tiết để có thể đưa vào Sprint gần nhất.
Các hạng mục chưa thể làm ngày hoặc cần đợi sau khi hoàn thành các hạng mục khác trước thì nên xếp ở phía dưới của backlog. Chúng có thể đang quá lớn, chưa được làm cụ thể chi tiết.
Khi càng gần đến các hạng mục này (dạng epic), chúng ta có thể bẻ nhỏ thành một tập hợp các user story nhỏ hơn và sẵn sàng để chuyển giao trong các Sprint tới. Nếu chúng ta làm rõ chúng quá sớm thì có thể mất công sức đi vào quá chi tiết, thậm chí một thay đổi từ phía khách hàng có thể dẫn tới không làm epic đó nữa.
Nhưng nếu gần đến hạng mục đó rồi, mà vẫn chưa được bẻ nhỏ hơn thì có thể đội phát triển sẽ bị chậm lại tiến độ phát triển họ.
Vì vậy cần thiết phải cân bằng được sự vừa đủ, vừa đúng lúc (just-in-time) trong việc thiết lập các hạng mục và thứ tự ưu tiên trong Product Backlog.
Emergent - Tiến hóa
Product Backlog luôn luôn là 1 thực thể động, không bao giờ tĩnh tại.
Nó sẽ được cập nhật thường xuyên nhờ vào dòng chảy thông tin liên tục giữa khách hàng hàng, PO và đội phát triển.
Ví dụ: khách hàng thay đổi yêu cầu họ mong muốn ban đầu, hay một số vấn đề kỹ thuật không lường trước được xảy ra có thể dẫn đến thêm bớt hạng mục, hoặc thay đổi ưu tiên trong Product Backlog.
Những sự thay đổi này cần được Product Owner cân nhắc, và cân bằng lại, sắp xếp lại Product Backlog.
Estimated - Được ước tính
Mỗi hạng mục của Product backlog đều có 1 kích cỡ tương ứng với nỗ lực cần bỏ ra để phát triển hạng mục đó (như hình dưới đây).
Hình ảnh các hạng mục trong Product Backlog đã được ước tính
PO có thể phải sử dụng các thông tin ước tính này để xác định thứ tự ưu tiên của các hạng mục trong Product Backlog. Các hạng mục ưu tiên cao và lớn (đang ở top đầu trong Product Backlog) là một dấu hiệu chỉ báo cho PO thấy cần có thêm sự tinh chỉnh trước khi chúng được đưa vào Sprint gần kề.
Các hạng mục lớn này có thể được ước tính theo story points hoặc số ngày cần thiết để hoàn thành. Cũng không cần thiết phải quá chính xác, chỉ cần vừa đủ chính xác, vì những hạng mục ở đầu của backlog nhỏ hơn và chi tiết hơn thì sẽ được ước lượng chính xác hơn.
Sẽ là khó khăn để ước lượng nỗ lực dành cho các hạng mục epic ở dưới cùng của backlog. Nhiều team có thể bỏ qua việc estimate hạng mục này hoặc dùng estimate theo số đo của áo T-shirt (S, M, L, XL, XXL,...) để ước lượng một cách tương đối.
Prioritized - Được sắp xếp ưu tiên
Mặc dù Product backlog là một danh sách các hạng mục công việc được sắp xếp theo thứ tự ưu tiên nhưng không phải tất cả các hạng mục ta đều có thể sắp xếp được chính xác ưu tiên.
Hình ảnh các hạng mục Product backlog được sắp theo thứ tự ưu tiên
Nếu ta có thể đặt ưu tiên cho các hạng mục ở gần, dự định đưa vào 1 vài Sprint tới thì rất tốt. Tiếp đến, xếp ưu tiên cho các hạng mục chúng ta dự định phát hành trong đợt 1 là vừa đủ. Nếu xếp ưu tiên vượt quá giai đoạn phát hành 1 thì có thể sẽ tốn thời gian.
Ví dụ, chúng ta có thể tuyên bố là 1 hạng mục sẽ dự kiến phát hành vào lần phát hành số 2 hoặc 3 trong Product Roadmap. Tuy nhiên nếu đang ở đầu lần phát hành 1, chúng ta không nên dành thời gian lo lắng sắp xếp các tính năng mà ta sẽ làm trong giai đoạn 2 hoặc 3. Vì rất có thể các ý tưởng liên quan đến 2 giai đoạn sau sẽ thay đổi đáng kể sau khi ta hoàn thành lần phát hành 1.
Làm mịn Product Backlog
Để có 1 Product Backlog đúng chuẩn DEEP, chúng ta cần phải chủ động quản lý, tổ chức, sắp xếp Product backlog, hoạt động này gọi là làm mịn (grooming).
Làm mịn Product Backlog là gì?
Làm mịn bao gồm 3 hoạt động chính:
Tạo và tinh chỉnh các hạng mục trong Product backlog (gọi là Product backlog items - PBI)Ước lượng các PBIsSắp xếp thứ tự ưu tiên cho các PBIsHình minh họa công việc làm mịn Product Backlog
Ở một thời điểm thích hợp, các hạng mục cần được ước tính để giúp xác định trật tự của chúng trong backlog, và giúp xác định xem còn cần thêm hạng mục nào hay không.
Khi có những thông tin mới từ phía khách hàng/thị trường hoặc từ ban lãnh đạo, các stakeholder, một hạng mục mới được khởi tạo và thêm vào trong backlog.
Xem thêm: Ngâm Bể Xi Măng Bao Lâu Thì Thả Cá Được Cá?Cần Xử Lý Như Thế Nào Để Thả Được Cá
Tất nhiên, nếu ưu tiên thay đổi thì chúng ta sẽ cần sắp xếp lại các hạng mục. Và khi đến gần hơn với các hạng mục to, chúng ta sẽ cần bẻ nhỏ hạng mục to thành các hạng mục nhỏ hơn. Rồi chúng ta cũng cần xác định xem hạng mục nào không còn cần thiết để bỏ chúng đi.
Đó là tất cả các hoạt động liên quan đến làm mịn Product Backlog.
Ai sẽ tham gia hoạt động Làm mịn Product Backlog?
Làm mịn là hoạt động cộng tác được dẫn dắt bởi Product Owner, với sự tham gia của các bên liên quan (stakeholders) có ảnh hưởng đến các hạng mục công việc, kể cả bên trong lẫn bên ngoài, bao gồm cả Scrum Master và đội phát triển.
Cộng tác trong làm mịn backlog
Tuy nhiên chỉ có 1 người ra quyết định, đó là Product owner.
Product owner cần hiểu rằng sự cộng tác, đối thoại giữa tất cả các thành viên liên quan sẽ tạo ra trí tuệ tập thể với các góc nhìn đa chiều, từ đó mang đến những thông tin quan trọng cho quyết định của Product owner.
Thông thường, đội phát triển sẽ dành khoảng 10% thời lượng của mỗi Sprint để hỗ trợ Product Owner trong hoạt động làm mịn. Team này sẽ giúp tạo các hạng mục hoặc review các hạng mục, đồng thời bẻ nhỏ các hạng mục lớn thành các hạng mục nhỏ hơn. Team này cũng sẽ ước tính kích cỡ của các Product backlog item và giúp PO sắp xếp thứ tự ưu tiên dựa trên mối tương quan về mặt kỹ thuật và các giới hạn về nguồn lực.
Khi nào hoạt động làm mịn diễn ra?
Scrum framework không đề cập cụ thể khi nào nên tổ chức hoạt động làm mịn mà chỉ nhấn mạnh sự cần thiết của nó.
Trong một môi trường có nhiều sự không chắc chắn, chúng ta cần phải thường xuyên sẵn sàng kiểm tra và thích nghi Product backlog với các thay đổi. Product backlog sẽ tiến hóa liên tục trong suốt quá trình chúng ta phát triển sản phẩm, và xử lý các vấn đề phát sinh, không mong muốn. Do đó, cần đảm bảo rằng hoạt động làm mịn là một phần thiết yếu trong cách chúng ta quản lý công việc.
Khi làm việc với development team, PO có thể sẽ muốn hẹn gặp đội này 1 tuần/lần hoặc 1 lần trong 1 Sprint. Đặt lịch như vậy giúp team sẽ lưu ý dành một khoảng thời gian nhất định cho hoạt động làm mịn trong Sprint khi họp Sprint Planning.
Một cách khác, nhiều team lại muốn dàn đều hoạt động làm mịn này trong cả Sprint, hơn là dành 1 khoảng thời gian cố định. Họ có thể lấy một ít thời gian sau daily scrum để làm mịn một vài hạng mục.
Hoạt động này cũng không cần thiết phải có mặt tất cả các thành viên. Chỉ những thành viên có kiến thức chuyên môn và quan tâm, muốn giúp đỡ PO hoàn thành việc làm mịn. Lần này là người A, lần sau sẽ là người B hỗ trợ PO.
Ngoài cách cố định 1 lịch hoặc dàn trải hàng ngày, thì một số team còn coi làm mịn là một hoạt động trong Sprint Review. Khi mọi người đều có cái nhìn tổng quan về hướng đi của sản phẩm trong Sprint tiếp theo, các hạng mục mới thường được khởi tạo, hoặc các hạng mục đang có sẵn sẽ được sắp xếp lại, hoặc bỏ đi nếu thấy không cần thiết.
Như vậy, vấn đề không phải là khi nào nên tổ chức làm mịn mà cần bảo đảm rằng hoạt động làm mịn là thiết yếu, được hòa vào dòng chảy của công việc phát triển sản phẩm, để chuyển giao được giá trị nhanh và linh hoạt tới khách hàng.
Template cho Product Backlog
Copy template cho Product Backlog tại đây
Cột User Story: Điền mô tả các User Story theo công thức Là , tôi muốn để Cột Độ ưu tiên: Sắp xếp thứ tự ưu tiên cho mỗi user story theo thứ tự từ (1-n)