Có một “myth” thú vị về backlog, khi request nào đó được “đưa vào backlog” tương đương ý nghĩa với việc đưa vào hàng chờ và chưa biết khi nào đến lượt thực hiện. Dù thực tế là vậy, backlog cũng có thể có vai trò “đúng đắn” hơn trong tiến trình build và phát triển một sản phẩm.
Định nghĩa
Sơ khởi, backlog giống như một chiếc kho chứa mọi việc cần làm liên quan đến sản phẩm: từ tính năng mới, cải thiện UI/UX, bug, tech debts… – những thứ mà chưa cam kết làm ngay, nhưng được ghi lại để xem xét sau. Diễn giải cơ bản, backlog trả lời cho câu hỏi: trong ngắn hạn, team cần deliver những “tasks” cụ thể nào.
Còn sprint backlog là phiên bản thu nhỏ của kho đó – danh sách chọn lọc những việc sẽ thực sự được làm trong một sprint kéo dài vài tuần. Ở nhiều công ty mà Py từng làm việc, hai khái niệm này thường dùng với ý nghĩa tương tự nhau, nhưng dĩ nhiên cũng sẽ có số ít team phân biệt rạch ròi giữa backlog và sprint backlog để tránh miscom. Vì backlog chứa những việc chưa có estimate rõ ràng, còn sprint backlog thì buộc phải có ước lượng cụ thể về effort và thời gian.
Tổng quan mà nói, backlog là khái niệm ở task-level, nên nhắc đến backlog là nhắc đến Epic, User Story rồi đến AC – Acceptance Criteria hay DoD (Definition of Done). Tùy vào “độ lớn” của project, sản phẩm hay tính năng, đôi khi một task list cơ bản cũng có thể dùng với vai trò của backlog – miễn là nó giúp team có cùng một điểm tựa chung để biết việc gì cần làm trước, việc gì có thể để sau.
Zoom-out
Vậy backlog sinh ra từ bước nào trong process làm sản phẩm? Theo lý thuyết thì backlog sẽ xuất hiện sau khi đã có roadmap. Roadmap thì thường gắn liền với JTBD (Job-to-be-done), mang tính chất high-level để trả lời cho câu hỏi: để giải quyết vấn đề của người dùng thì cần làm những gì và thứ tự thế nào.
Dù vậy, theo Py quan sát thì thường PO trẻ sẽ bắt đầu với backlog trước rồi mới “mapping” những items liên quan và ước định thời gian hoàn thành để ra roadmap. Kể cả bản thân Py trước đây khi làm roadmap cũng tiếp cận theo cách tương tự như vậy. Theo cách này, roadmap có thể sẽ có tính khả thi cao nhưng đánh đổi có thể không giải đúng vấn đề của user đang cần cũng như không đảm bảo được tính cấp thiết. Thế nên, Py cũng dần thay đổi cách làm, define roadmap trước rồi mới đến backlog.
Chỉ là cả backlog1 và roadmap2 đều là “khái niệm” nên trong khuôn khổ một bài blog, Py chưa tìm được cách diễn giải qua vài dòng ví dụ ngắn gọn. Nên cuối bài viết, Py có dẫn link 2 bài viết của product plan, “rất đề xuất” các bạn đọc qua.
Zoom-in
Nhìn cận, ai là người tạo ta backlog, và backlog chứa những gì?
Theo Scrum Guide, Product Owner (PO) là người chịu trách nhiệm chính cho backlog: quyết định mục nào được đưa vào, mục nào cần loại bỏ, và thứ tự ưu tiên ra sao3. PO giống như “người gác cổng”, đảm bảo rằng mỗi hạng mục trong backlog đều gắn liền với roadmap và tầm nhìn sản phẩm. Vì thực tế, backlog thường được hình thành và tinh chỉnh cùng với các stakeholders, developer và designer – những người trực tiếp góp phần biến ý tưởng thành sản phẩm chạy ngoài đời thực.
Chất lượng của backlog thì phụ thuộc vào chất lượng của từng thành tố nhỏ trong đó: những epic và user story. Để phân biệt, thường người ta dùng tiêu chí “có thể hoàn thành trong một sprint hay không”: nếu quá lớn, đó là epic; nếu đủ nhỏ và rõ ràng, đó là story (đoạn này mang tính kinh nghiệm là chính). Và để đánh giá tính “chuẩn mực”, nhiều team dựa vào nguyên tắc INVEST – Independent, Negotiable, Valuable, Estimable, Small, Testable4.
Danh sách những epic và story đã được sắp xếp theo thứ tự ưu tiên ấy chính là backlog.
Tản mạn
Đúng như tên gọi, đây chỉ là vài dòng phảng phất suy nghĩ cá nhân của mình về cách dùng backlog, nên hoàn toàn mang tính chủ quan.
Theo hướng lý luận trên, “core value” của backlog chính là thứ tự ưu tiên. Cũng vì vậy mà trong thực tế, backlog thường trở thành một tấm khiên: mỗi khi có request “gấp” nhưng chưa rõ impact, hoặc thậm chí chưa biết sẽ giải quyết vấn đề gì, thì khả năng cao nó sẽ được vào backlog và đợi.
Nhưng căn cơ, backlog là tập hợp của các ý tưởng, lượt thảo luận về những gì nên làm để tiếp tục phát triển sản phẩm, tính năng – một khía cạnh ít khi được nhắc đến. Qua đó, principle của người làm sản phẩm cũng được phản ánh. Từ cách viết một story, cách tổ chức epic, cho đến thứ tự ưu tiên… tất cả đều soi chiếu tư duy của PO trong việc cân bằng giữa ngắn hạn và dài hạn, giữa áp lực phải chạy và khát vọng xây bền.
Thế nên, trong một chừng mực có thể, Py vẫn dành lượng resource nhất định để “quản backlog”, chẳng hạn như đọc lại danh sách các request rời rạc xem có cách giải nào đó “generic” hơn không, hay thách thức bản thân về “cách” nào đó “công bằng” hơn để đánh điểm ưu tiên cho mỗi yêu cầu. Backlog, theo cách đó, không chỉ là “công việc tồn đọng”, mà còn là phương tiện nuôi dưỡng trực giác làm sản phẩm.
- Productboard. (n.d.). Product backlog
- ProductPlan. (n.d.). Product roadmap vs. product backlog.
- Schwaber, K., & Sutherland, J. (2020). The Scrum Guide: The definitive guide to Scrum: The rules of the game. Scrum.org.
- Agile Alliance. (n.d.). INVEST.
Cám ơn bạn đã nán lại cho đến những dòng cuối cùng này.
Chúc bạn nhiều may mắn và bình an.
Anpy
Leave a Reply