Backlog là gì? Cách quản lý backlog trong công việc

Backlog giúp nhóm nhìn rõ những công việc đang chờ thực hiện và quyết định việc nào cần làm trước. Khi yêu cầu đến từ nhiều người, một danh sách được quản lý thống nhất sẽ giúp bạn tránh cảnh mỗi thành viên giữ một phiên bản riêng. Tuy nhiên, chỉ ghi lại đầu việc chưa đủ để nhóm biết nên bắt đầu từ đâu.

Vậy backlog là gì, và làm thế nào để danh sách giúp nhóm lựa chọn thay vì chỉ ghi thêm việc? Sansan Academy cùng bạn phân biệt các backlog trong Scrum và cách quản lý yêu cầu từ lúc tiếp nhận đến khi xem lại kết quả.

Backlog là gì?

Backlog là danh sách công việc hoặc yêu cầu còn cần xử lý. Trong phát triển sản phẩm, danh sách có thể gồm tính năng mới, cải tiến, lỗi và công việc kỹ thuật. Nhóm xem xét các hạng mục để quyết định phần việc phù hợp với mục tiêu và khả năng thực hiện.

Một hạng mục nằm trong backlog không có nghĩa đã quá hạn, cũng không phải lời hứa sẽ được triển khai. Ý tưởng còn cần tìm hiểu và yêu cầu đủ rõ để bắt đầu có thể cùng nằm trong danh sách. Khi dùng Scrum, bạn cần phân biệt Product Backlog định hướng phát triển sản phẩm với Sprint Backlog chứa mục tiêu và kế hoạch của Sprint đang thực hiện.

Vai trò của backlog trong quản lý công việc

Nhóm có thể có nhiều ý tưởng tốt nhưng không đủ thời gian làm tất cả. Backlog giúp đặt các yêu cầu cạnh nhau để xem việc nào đáng làm trước và việc nào cần chờ. Danh sách chỉ hữu ích khi quyết định được giải thích và cập nhật, thay vì ghi thêm đầu việc rồi để đó.

Tập hợp yêu cầu để nhóm cùng theo dõi

Yêu cầu rải rác trong email, tin nhắn và ghi chú cá nhân dễ bị bỏ sót hoặc tiếp nhận nhiều lần. Một nơi lưu chung giúp người thực hiện tìm lại mô tả, nguồn đề xuất và nội dung đã trao đổi. Khi cần hỏi thêm, họ biết liên hệ với ai. Người đề xuất cũng có thể theo dõi yêu cầu thay vì phải nhắn lại cho từng thành viên.

Hãy phân biệt trạng thái đã tiếp nhận với đã chọn thực hiện. Ghi rõ quyết định và lý do giúp các bên biết điều gì đang chờ, tránh hiểu rằng mọi đề xuất đều đã được nhận làm.

Làm rõ thứ tự ưu tiên và cơ sở lựa chọn công việc

Nguồn lực có giới hạn nên nhóm cần giải thích vì sao một hạng mục được làm trước. Cơ sở lựa chọn có thể gồm giá trị cho người dùng, rủi ro, mức ảnh hưởng, công sức và các phụ thuộc. Việc sắp xếp Product Backlog cần xét nhiều yếu tố, thay vì chỉ gắn nhãn ưu tiên cao cho mọi yêu cầu.

Ví dụ, lỗi khiến khách không thể thanh toán có thể cần xử lý trước yêu cầu đổi màu giao diện. Nhóm nên làm rõ lỗi xảy ra ở đâu, ảnh hưởng đến ai và hậu quả nếu chờ. Những thông tin này giúp các bên trao đổi về sự đánh đổi giữa các lựa chọn. Quyết định không còn chỉ phụ thuộc vào người thúc giục nhiều nhất.

Hỗ trợ lập kế hoạch và điều chỉnh theo phản hồi

Các hạng mục đủ rõ giúp nhóm chọn phần việc cho giai đoạn tiếp theo. Trong Scrum, Developers trao đổi với Product Owner để lựa chọn công việc tại Sprint Planning. Mục tiêu Sprint, khả năng thực hiện sắp tới và kết quả các Sprint trước là những căn cứ cần xem xét. Danh sách mong muốn dài không có nghĩa nhóm phải nhận hết vào một Sprint.

Khi phản hồi cho thấy nhu cầu đã thay đổi, nhóm xem lại thứ tự Product Backlog và kế hoạch đang thực hiện. Khi làm việc theo phương pháp Agile, nhóm cần học từ kết quả và điều chỉnh, đồng thời vẫn bảo vệ Sprint Goal nếu dùng Scrum.

Product Backlog và Sprint Backlog trong Scrum

Product Backlog là danh sách có thứ tự những việc cần thiết để cải thiện sản phẩm. Product Goal nêu trạng thái tương lai mà nhóm hướng tới. Theo Scrum Guide 2020, Sprint Backlog gồm Sprint Goal, các hạng mục được chọn và kế hoạch tạo ra Increment, phần sản phẩm có thể sử dụng.

Product Owner có thể nhờ người khác thực hiện công việc quản lý Product Backlog nhưng vẫn chịu trách nhiệm về hiệu quả quản lý. Developers xây dựng và cập nhật Sprint Backlog khi hiểu thêm về công việc. Nếu cần đổi phạm vi, họ trao đổi với Product Owner và bảo vệ Sprint Goal, không coi danh sách đã chọn là bất biến.

Một hạng mục backlog cần có thông tin gì?

Thông tin của một hạng mục cần đủ để nhóm hiểu vấn đề, đánh giá và quyết định bước tiếp theo. Những việc sắp triển khai thường cần rõ hơn các ý tưởng còn xa. Bạn có thể bắt đầu với các nhóm thông tin dưới đây rồi điều chỉnh theo loại công việc, thay vì bắt mọi hạng mục điền cùng một biểu mẫu dài.

Mô tả yêu cầu và kết quả cần đạt

Đọc mô tả, người thực hiện cần biết ai gặp vấn đề và thay đổi nào sẽ giải quyết nhu cầu đó. Với tính năng nhắc lịch, hãy làm rõ lịch hẹn nào cần thông báo, gửi cho ai và trong điều kiện nào. Acceptance criteria nêu điều kiện chấp nhận cụ thể của yêu cầu. Cách ghi này rõ hơn một đề xuất chung chung như cải thiện trải nghiệm.

User story diễn đạt nhu cầu từ góc nhìn người dùng, còn task nêu công việc để thực hiện. Không phải mọi hạng mục đều cần viết thành user story, vì lỗi và việc kỹ thuật có thể phù hợp với cách mô tả khác.

Thứ tự ưu tiên và giá trị mong đợi

Giá trị mong đợi cần trả lời yêu cầu sẽ giúp ích cho ai và ở điểm nào. Ngăn đặt trùng giờ hoặc giúp khách hoàn tất đặt lịch là những mục đích cụ thể hơn việc chỉ ghi tăng trải nghiệm.

Vị trí trong backlog cần đi cùng lý do lựa chọn. Nếu hai yêu cầu có mức ảnh hưởng gần nhau, nhóm xem thêm rủi ro trì hoãn, công sức hoặc việc nào mở đường cho bước kế tiếp. Lưu lại căn cứ giúp bạn biết cần xem xét lại quyết định khi nhu cầu hoặc điều kiện thực hiện thay đổi.

Khóa học Kỹ năng quản lý thời gian

Sắp xếp ưu tiên, giới hạn công việc đang làm và bảo vệ thời gian cho nhiệm vụ quan trọng.

Xem khóa học

Ước lượng công sức thực hiện

Ước lượng cho biết nhóm đang hình dung độ lớn công việc ra sao, không phải một lời bảo đảm về ngày hoàn tất. Thiếu tài liệu tích hợp hoặc cần thử giải pháp đều có thể làm thay đổi nhận định ban đầu. Hãy ghi những giả định này cùng kết quả ước lượng để người đọc hiểu con số được hình thành từ đâu.

Trong Scrum, Developers thực hiện công việc chịu trách nhiệm ước lượng độ lớn hạng mục. Hướng dẫn Product Backlog Items của Scrum.org nêu nhiều cách ước lượng, trong đó story points dùng để so sánh tương đối. Story points không phải đơn vị bắt buộc của Scrum hay số giờ cố định cho mọi nhóm. Cần thống nhất cách hiểu trước khi dùng ước lượng để lựa chọn công việc.

Các phụ thuộc và điều kiện cần đáp ứng

Một việc có thể chưa triển khai được vì đang chờ dữ liệu, quyết định hoặc phần việc khác. Chẳng hạn, tính năng nhắc hẹn cần có lịch đặt đã được xác nhận và thông tin liên hệ hợp lệ. Ghi rõ phụ thuộc giúp nhóm biết phải tháo gỡ điều gì trước khi bắt đầu.

Bạn cũng nên nêu điều kiện để kiểm tra kết quả. Với nhiệm vụ tích hợp, nhóm cần biết môi trường thử nghiệm, quyền truy cập và người xác nhận đầu ra. Những thông tin này giúp phát hiện việc chưa sẵn sàng thay vì để thành viên bắt đầu rồi mới nhận ra đang thiếu đầu vào.

Quy trình xây dựng và quản lý backlog

Đừng chờ chọn được phần mềm mới bắt đầu xem lại các yêu cầu đang có. Trong quản lý dự án, mục tiêu, phạm vi và nguồn lực là căn cứ để thu thập, làm rõ rồi lựa chọn công việc. Sau mỗi đợt thực hiện, nhóm dùng kết quả và phản hồi để xem lại danh sách.

Xác định mục tiêu, thu thập và mô tả yêu cầu

Trước khi gom đầu việc, hãy xác định vấn đề nhóm đang cần giải quyết. Với ứng dụng đặt lịch, mục tiêu ban đầu có thể là giúp khách tự chọn một khung giờ còn trống. Mục tiêu đủ rõ giúp nhóm phân biệt nhu cầu phục vụ giai đoạn này với ý tưởng dành cho lúc khác.

Khi thu thập yêu cầu từ người dùng, bộ phận vận hành và người thực hiện, hãy ghi cả vấn đề và nguồn đề xuất. Sau đó trao đổi về kết quả cần đạt, không chỉ chép lại tên tính năng được gợi ý. Hạng mục còn thiếu thông tin cần được làm rõ trước khi lựa chọn, thay vì để người thực hiện tự đoán phạm vi.

Rà soát, gộp trùng và chia nhỏ hạng mục

Hai đề xuất tên khác nhau có thể cùng giải quyết một nhu cầu, nhưng cũng có thể chỉ giống nhau ở cách gọi. Đối chiếu đối tượng sử dụng, điều kiện và kết quả mong đợi trước khi gộp. Giữ lại nguồn đề xuất giúp bạn hỏi thêm hoặc thông báo quyết định cho đúng người. Với việc quá lớn, chia theo những phần kết quả có thể kiểm tra được, thay vì chỉ tách theo từng bộ phận phụ trách.

Backlog refinement là hoạt động liên tục làm rõ và điều chỉnh hạng mục, không phải một loại backlog hay sự kiện bắt buộc riêng của Scrum. Nhóm có thể cập nhật mô tả, thứ tự, độ lớn và chia nhỏ những việc sắp được chọn.

Không cần mô tả chi tiết toàn bộ danh sách ngay từ đầu. Tập trung vào các hạng mục gần triển khai, còn ý tưởng dài hạn chỉ cần đủ nghĩa để tiếp tục xem xét khi phù hợp.

Ước lượng, sắp xếp ưu tiên và lựa chọn công việc

Khi yêu cầu đã rõ, nhóm so sánh giá trị, rủi ro, công sức và phụ thuộc để lựa chọn. Việc chuẩn bị đầu vào đôi khi phải đi trước một tính năng được mong đợi hơn. Khối lượng nhận làm cũng cần phù hợp với mục tiêu và khả năng thực hiện của giai đoạn sắp tới.

MoSCoW giúp trao đổi về phạm vi với bốn nhóm yêu cầu. Cần chốt giai đoạn đang xét trước khi phân loại để các bên hiểu điều gì sẽ được làm và điều gì chưa làm lần này.

• Must Have: Bắt buộc có để giải pháp dùng được trong phạm vi đã thống nhất.
• Should Have: Quan trọng nhưng có thể thiếu tạm thời nếu vẫn có cách đáp ứng nhu cầu.
• Could Have: Mong muốn có, nhưng ảnh hưởng khi thiếu thấp hơn Should Have.
• Won’t Have this time: Đã thống nhất không thực hiện trong giai đoạn này, không đồng nghĩa bị loại vĩnh viễn.

Để so sánh ý tưởng sản phẩm, RICE của Intercom xem xét reach, impact, confidence và effort. Reach cần cùng một khoảng thời gian so sánh, còn confidence phản ánh độ tin cậy của ước lượng. Điểm số hỗ trợ trao đổi chứ không quyết định thay nhóm, vì phụ thuộc hoặc nhu cầu thiết yếu có thể khiến việc điểm thấp phải được làm trước. MoSCoW và RICE là những lựa chọn hỗ trợ, không phải yêu cầu bắt buộc của Scrum.

Theo dõi kết quả và cập nhật backlog

Sau đợt thực hiện, hãy đối chiếu kết quả với điều kiện đã thống nhất, không chỉ đánh dấu xong vì người phụ trách đã ngừng làm. Trong Scrum, Definition of Done nêu các yêu cầu chất lượng đối với Increment. Hạng mục chưa đáp ứng yêu cầu này không được coi là phần sản phẩm đã hoàn tất để phát hành. Acceptance criteria của từng yêu cầu và Definition of Done có vai trò khác nhau, nên đạt một tính năng mong muốn chưa thay thế việc kiểm tra chất lượng chung.

Phản hồi về kết quả giúp nhóm quyết định giữ, đổi hoặc bỏ các yêu cầu còn chờ. Với hạng mục lâu chưa được chọn, hãy xem nhu cầu còn tồn tại không và vì sao chưa xử lý, thay vì mặc định tuổi của yêu cầu là lý do giữ lại hoặc loại bỏ.

Ba ví dụ áp dụng backlog

Trong các tình huống giả định sau, mỗi nhóm có một cách chọn công việc theo nhu cầu đang giải quyết. Hãy chú ý lý do thay đổi thứ tự và điều kiện để bắt đầu, không chỉ tên đầu việc trong danh sách.

Backlog phát triển một ứng dụng đặt lịch

Một nhóm đang xây ứng dụng cho phòng khám với ba yêu cầu: chọn khung giờ, gửi nhắc hẹn và đánh giá sau khám. Nhóm chọn mục tiêu ban đầu là để khách tự đặt lịch mà không cần gọi điện. Vì vậy, khả năng xem giờ trống và xác nhận lịch được xem xét trước tính năng đánh giá.

Yêu cầu chọn khung giờ được mô tả thành user story về nhu cầu của người đặt lịch. Nhóm làm rõ tiêu chí chấp nhận, chẳng hạn không cho hai khách đặt cùng một chỗ trống. Các task thực hiện gồm xử lý dữ liệu lịch, tạo giao diện và kiểm tra tình huống đặt đồng thời.

Sau khi thử nghiệm, nhóm nhận ra lịch trống chưa cập nhật đúng khi lễ tân đổi lịch. Hạng mục xử lý đồng bộ được đưa lên trước nhắc hẹn vì ảnh hưởng trực tiếp đến việc đặt chỗ. Tình huống này cho thấy thứ tự cần thay đổi khi nhóm hiểu thêm về vấn đề.

Backlog của nhóm marketing

Giả sử nhóm marketing chuẩn bị ra mắt sản phẩm mới, đồng thời nhận đề xuất viết bài, làm video và tổ chức sự kiện. Nhóm ghi nhận các ý tưởng theo mục tiêu ra mắt và trao đổi thêm về đối tượng, thông tin sản phẩm cần có.

Chốt thông điệp là đầu vào để viết nội dung, còn trang giới thiệu cần sẵn sàng trước khi chạy quảng cáo dẫn khách đến đó. Khi thời gian hạn chế, nhóm lựa chọn phần việc phục vụ trực tiếp đợt ra mắt. Những ý tưởng cho giai đoạn sau vẫn được lưu nhưng chưa đưa vào lịch đăng. Nhờ phân biệt ý tưởng với nội dung đã chọn thực hiện, các thành viên biết cần phối hợp ở phần việc nào.

Backlog yêu cầu chăm sóc khách hàng

Giả sử bộ phận chăm sóc khách hàng đang chờ xử lý yêu cầu đổi thông tin, kiểm tra thanh toán và phản ánh không dùng được dịch vụ. Mỗi yêu cầu cần có thời điểm tiếp nhận, mức ảnh hưởng, nội dung trao đổi và người theo dõi. Trường hợp khách không thể sử dụng dịch vụ có thể cần kiểm tra sớm, nhưng nhóm vẫn phải theo dõi thời gian chờ của các yêu cầu khác. Lịch sử trao đổi giúp nhân viên tiếp nhận biết việc đã làm, tránh buộc khách giải thích lại từ đầu.

Nếu nhiều khách phản ánh cùng một lỗi, liên kết các yêu cầu với vấn đề chung giúp phối hợp xử lý mà vẫn giữ hồ sơ của từng người. Khi có kết quả, từng khách cần nhận thông tin phù hợp với trường hợp của mình, không chỉ một thông báo rằng lỗi chung đã đóng.

Những sai lầm khiến backlog khó quản lý

Danh sách dài nhưng người thực hiện vẫn không biết bắt đầu từ đâu là dấu hiệu cần xem lại cách quản lý. Trở ngại có thể nằm ở yêu cầu chưa rõ, quyết định ưu tiên không nhất quán hoặc phần việc được chọn vượt khả năng thực hiện.

Mô tả yêu cầu mơ hồ, thiếu kết quả cần đạt

Các tên như nâng cấp hệ thống hoặc cải thiện nội dung không chỉ ra vấn đề cụ thể. Người thực hiện phải tự đoán phạm vi, còn người đề xuất có thể kỳ vọng một kết quả khác. Sự khác nhau này thường chỉ lộ ra khi nhóm đã làm một phần công việc.

Bạn nên bổ sung đối tượng sử dụng, thay đổi cần có và cách kiểm tra đầu ra. Nếu vẫn chưa thể thống nhất, hãy dành thời gian làm rõ trước khi lựa chọn hạng mục. Mô tả ngắn nhưng đủ nghĩa sẽ hữu ích hơn một văn bản dài chứa nhiều yêu cầu chưa được quyết định.

Đánh dấu quá nhiều hạng mục là ưu tiên cao

Khi phần lớn danh sách đều được gắn ưu tiên cao, nhãn này không giúp người thực hiện phân biệt nên làm gì trước. Nhóm có thể quay về cách chọn theo người thúc giục nhiều nhất dù đã có backlog.

Hãy trao đổi về hậu quả trì hoãn và sự đánh đổi khi nhận một yêu cầu mới. Nếu việc mới phải làm ngay, các bên cần biết phần việc nào sẽ lùi và vì sao. Một thứ tự có lý do rõ sẽ hữu ích hơn việc tiếp tục thêm nhãn khẩn cấp mà không điều chỉnh kế hoạch.

Giữ yêu cầu trùng lặp hoặc lỗi thời

Yêu cầu có thể được ghi nhận lại qua nhiều kênh, khiến nhóm đánh giá cùng một nhu cầu nhiều lần. Khi gộp, hãy giữ thông tin liên quan và lý do quyết định để các bên tra cứu. Chỉ giống tên chưa đủ để kết luận hai yêu cầu trùng nhau.

Với việc không còn phục vụ mục tiêu, ghi rõ lý do loại hoặc lưu trữ và thông báo cho người đề xuất khi cần. Một hạng mục nằm lâu trong danh sách vẫn có thể quan trọng, nên cần xét nhu cầu hiện tại chứ không dọn theo thời gian lưu đơn thuần.

Chọn khối lượng công việc vượt quá năng lực nhóm

Cộng thời gian làm từng đầu việc chưa phản ánh hết công sức của một đợt thực hiện. Nhóm còn cần trao đổi, kiểm tra, hỗ trợ và xử lý trở ngại. Người nghỉ phép hoặc đầu vào chờ bên ngoài cũng ảnh hưởng phần việc có thể hoàn tất. Bỏ qua những điều này dễ khiến nhiều hạng mục được bắt đầu nhưng ít kết quả được bàn giao.

Hãy đối chiếu khả năng thực hiện đã quan sát với điều kiện sắp tới trước khi nhận thêm việc. Nếu phát hiện quá tải, trao đổi để điều chỉnh lựa chọn và phạm vi, thay vì chỉ yêu cầu mọi người làm nhanh hơn.

Chọn công cụ khi chưa thống nhất cách quản lý

Jira, Trello hay bảng tính đều cần một cách phối hợp rõ để danh sách có ích. Nhóm phải biết ai tiếp nhận, ai quyết định thứ tự và khi nào xem lại yêu cầu. Chuyển dữ liệu sang phần mềm không tự trả lời các câu hỏi này. Hãy thống nhất cách làm trước, rồi chọn tính năng giúp người tham gia theo dõi và cập nhật thuận tiện hơn.

Nếu dùng bảng Kanban, các trạng thái cần thể hiện tiến trình công việc cùng điều kiện chuyển bước và cách xử lý việc bị chặn. Nhóm nhỏ có thể bắt đầu bằng bảng tính, miễn là các bên dùng chung thông tin và biết quyết định nào đang có hiệu lực.

Kết luận

Backlog hữu ích khi giúp nhóm hiểu yêu cầu và đưa ra quyết định thực hiện có căn cứ. Bạn nên bắt đầu bằng mục tiêu rõ, mô tả đủ thông tin và một thứ tự phù hợp với nguồn lực. Việc rà soát cần được duy trì khi có phản hồi hoặc thay đổi, để danh sách tiếp tục phản ánh nhu cầu thực tế.

Nếu đang quản lý một backlog khó theo dõi, hãy chọn một nhóm hạng mục sắp thực hiện để làm rõ trước. Kiểm tra yêu cầu trùng, bổ sung kết quả cần đạt và trao đổi về phần việc khả thi. Sau đợt thực hiện đầu tiên, dùng kết quả quan sát được để điều chỉnh cách lựa chọn công việc tiếp theo.