Một product backlog “khoẻ mạnh” cũng giống như một con người khoẻ mạnh: được trải chuốt, có tổ chức và cởi mở.

Một backlog được ưu tiên tốt không chỉ giúp việc lập kế hoạch phát hành và thực hiện quá trình lặp dễ dàng hơn mà còn truyền tải tất cả những gì nhóm agile dự định dành thời gian thực hiện, bao gồm cả công việc nội bộ mà khách hàng sẽ không bao giờ chú ý đến. Điều này giúp bạn đưa ra kỳ vọng với các bên liên quan và các nhóm khác, đặc biệt khi họ mang lại công việc bổ sung cho bạn, và biến thời gian kỹ thuật trở thành tài sản cố định.

Product backlog là gì?

Product backlog – công việc tồn đọng của sản phẩm là một danh sách ưu tiên các công việc của nhóm phát triển, dựa trên lộ trình và các yêu cầu của sản phẩm. Các hạng mục quan trọng nhất được hiển thị ở trên cùng backlog để nhóm biết những gì cần phân phối trước. Nhóm phát triển không giải quyết backlog theo tốc độc của Product Owner, và Product Owner không thúc giục nhóm phát triển làm việc. Thay vào đó, nhóm phát triển lấy công việc từ backlog khi họ có khả năng thực hiện nó, một cách liên tục (kanban) hoặc lặp đi lặp lại (scrum).

Mẹo: Hãy giữ mọi thứ trong một trình theo dõi issue (issue tracker) duy nhất. Đừng sử dụng nhiều hệ thống để theo dõi các lỗi, yêu cầu và các hạng mục công việc kỹ thuật. Hãy giữ chúng trong một backlog duy nhất.

Bắt đầu với hai chữ R

Một Roadmap (lộ trình) và các Requirement (yêu cầu) chính là nền tảng cho một backlog sản phẩm. Các kế hoạch lộ trình được chia thành nhiều epic và mỗi epic bao gồm các yêu cầu và user story (câu chuyện người dùng). Hãy lấy ví dụ bằng lộ trình của một sản phẩm hư cấu có tên là Teams in Space.

Vì trang web Teams in Space là kế hoạch đầu tiên trong lộ trình, chúng ta sẽ chia nhỏ nó thành các epic (được hiển thị bằng màu xanh lá cây, xanh lam và xanh dương nhạt) và các user story cho mỗi epic.

Product Owner sắp xếp các user story thành một danh sách duy nhất cho nhóm phát triển. Product Owner có thể chọn phân phối một epic đã hoàn thành trước (bên trái), hoặc một số story từ các epic khác nhau (bên phải) nếu việc sử dụng chúng để kiểm tra chương trình quan trọng hơn. Hãy xem cả hai ví dụ dưới đây.

Điều gì ảnh hưởng đến thứ tự ưu tiên của Product Owner?

• Ưu tiên của khách hàng
• Tính cấp thiết của việc nhận phản hồi
• Độ khó thực hiện tương đối
• Mối quan hệ giữa các hạng mục công việc (ví dụ: công việc B sẽ dễ dàng hơn nếu ta làm A trước)

Mặc dù Product Owner có nhiệm vụ sắp xếp thứ tự ưu tiên cho backlog, nhưng không phải Product Owner tự mình thực hiện công việc này. Product Owner tìm kiếm các ý kiến đóng góp và phản hồi từ khách hàng, nhà thiết kế và nhóm phát triển để tối ưu hoá khối lượng công việc của mọi người và việc phân phối sản phẩm.

Giữ cho backlog “khoẻ mạnh”

Một khi backlog được xây dựng, điều quan trọng là bạn phải thường xuyên bảo trì nó để bắt kịp với chương trình. Product Owner nên xem xét lại backlog trước cuộc họp lập kế hoạch cho mỗi lần lặp để đảm bảo mức độ ưu tiên là chính xác và phản hồi từ lần lặp cuối cùng đã được tổng hợp. Việc xem xét và kiểm tra thường xuyên backlog thường được gọi là “backlog grooming” (hay backlog refinement) trong các vòng agile.

Khi các công việc tồn đọng nhiều hơn, Product Owner cần phân nhóm các công việc trong backlog thành các hạng mục ngắn hạn (near-team) và các hạng mục dài hạn (long-term). Các hạng mục ngắn hạng cần được xác định một cách chi tiết và rõ ràng: bạn cần soạn thảo các user story, sắp xếp sự hợp tác giữa nhóm thiết kế và phát triển, đồng thời thực hiện các ước tính cho việc phát triển. Các hạng mục dài hạn có thể vẫn còn mơ hồ, tuy nhiên bạn vẫn nên có những ước tính sơ bộ từ nhóm phát triển để dễ dàng sắp xếp thứ tự ưu tiên cho chúng. Tất nhiên, các ước tính sẽ còn thay đổi sau khi nhóm hiểu hết về mỗi hạng mục và bắt đầu các công việc liên quan đến chúng.

Backlog đóng vai trò kết nối Product Owner và nhóm phát triển. Product Owner có thể tự do sắp xếp thứ tự ưu tiên trên backlog bất cứ lúc nào, dựa trên phản hồi của khác hàng, các ước tính được tinh chỉnh và các yêu cầu mới. Tuy nhiên, khi công việc đang được tiến hành, bạn nên giữ các thay đổi ở mức tối thiểu vì chúng sẽ làm gián đoạn nhóm phát triển và ảnh hưởng đến sự tập trung, luồng công việc, cũng như tinh thần của nhóm.

Mẹo: Một khi backlog phát triển vượt quá khả năng lâu dài của nhóm, bạn có thể đóng các issue mà nhóm sẽ không bao giờ làm việc tới. Hãy gắn cờ những issue đó với một giải pháp cụ thể, chẳng hạn như out of scope (ngoài phạm vi) trong trình theo dõi issue để sử dụng cho việc nghiên cứu trong tương lai.

Những trường hợp nên tránh

• Product Owner sắp xếp thứ tự ưu tiên cho backlog khi bắt đầu dự án, nhưng không điều chỉnh nó khi nhận được phản hồi từ nhà phát triển và các bên liên quan.
• Nhóm chỉ đưa vào backlog những vấn đề khách hàng phải đối mặt.
• Backlog được lưu trữ dưới dạng tài liệu cục bộ và không được chia sẻ thường xuyên, khiến các bên liên quan không được cập nhật thông tin.

Backlog sản phẩm duy trình tính nhanh nhẹn cho nhóm như thế nào?

Các Product Owner có kinh nghiệm sẽ biết cách xử lý nghiêm ngặt backlog sản phẩm của họ, làm cho nó trở thành một bản phác thảo các hạng mục công việc đáng tin cậy và được chia sẻ.

Các bên liên quan sẽ tác động đến thứ tự ưu tiên trên backlog, và đó là một điều tốt. Những cuộc thảo luận về những gì quan trọng sẽ đồng bộ hoá các ưu tiên của mọi người, đồng thời thúc đẩy văn hoá nhóm, đảm bảo mọi người đều có chung suy nghĩ về sản phẩm và quy trình.

Lưu ý: Product Owner quyết định mức độ ưu tiên của các hạng mục công việc trong backlog, còn nhóm phát triển quyết định tốc độ thực hiện công việc thông qua backlog. Đây có thể là một mối quan hệ không mấy dễ dàng đối với những Product Owner mới, những người có xu hướng “thúc giục” nhóm làm việc. 

Backlog sản phẩm cũng đóng vai trò nền tảng trong việc lập kế hoạch cho mỗi lần lặp. Tất cả các hạng mục công việc nên được đưa vào backlog: user story, lỗi, thay đổi thiết kế, khoản nợ kỹ thuật, yêu cầu của khách hàng, hạng mục hành động từ Retrospective, v.v. Điều này đảm bảo các hạng mục công việc của mọi người được đưa vào cuộc thảo luận tổng thể trong mỗi lần lặp. Sau đó, các thành viên trong nhóm có thể trao đổi và đàm phán với Product Owner trước khi bắt đầu quá trình lặp lặp, với những hiểu biết đầy đủ về mọi thứ cần phải thực hiện.

Theo Atlassian