Mở đầu — vì sao bài này quan trọng
Nếu bạn từng đi thi PSM I, hoặc từng ngồi quan sát một nhóm Scrum thật sự làm việc, bạn sẽ nhanh chóng nhận ra rằng Sprint Backlog là một trong những artifact bị hiểu sai nhiều nhất. Rất nhiều người — kể cả những Scrum Master đã làm việc vài năm — vẫn nghĩ Sprint Backlog chỉ đơn giản là "danh sách task của Sprint" hay "cái board Jira có mấy cột To Do / Doing / Done". Cách hiểu đó không sai hoàn toàn, nhưng nó thiếu hẳn linh hồn của artifact này.
Trong đề thi PSM I, Scrum Backlog xuất hiện ở rất nhiều câu hỏi, và đáng chú ý là phần lớn các câu hỏi đó không hỏi "Sprint Backlog là gì" một cách trực tiếp. Chúng hỏi gián tiếp: Ai sở hữu Sprint Backlog? Ai được phép thay đổi nó? Sprint Backlog có bao gồm Sprint Goal không? Khi nào nó được cập nhật? Nếu bạn chỉ thuộc lòng định nghĩa mà không hiểu bản chất, bạn sẽ rơi bẫy ngay.
Bài này tập trung đúng một thứ: Sprint Backlog với tư cách là artifact và commitment đi kèm với nó là Sprint Goal. Tôi sẽ không lan sang chi tiết cách viết Sprint Goal (việc đó là của Bài 22), cũng không đi sâu vào Sprint Planning (Bài 13) hay phân biệt Product Backlog với Sprint Backlog (Bài 45). Ở đây, ta mổ xẻ chính artifact Sprint Backlog: nó gồm những gì, ai sở hữu, được tạo ra và tiến hóa như thế nào, và tại sao Scrum Guide 2020 lại gắn nó với một commitment.
Khái niệm cốt lõi
Sprint Backlog gồm ba phần
Theo Scrum Guide 2020, Sprint Backlog được cấu thành từ ba phần, và bạn nên thuộc lòng cấu trúc này như thuộc bảng cửu chương:
- The why — Sprint Goal: mục tiêu duy nhất của Sprint, lý do tồn tại của Sprint đó. Đây chính là commitment của Sprint Backlog.
- The what — tập hợp các Product Backlog Item được chọn cho Sprint: những hạng mục mà Developers cam kết sẽ làm trong Sprint này để phục vụ Sprint Goal.
- The how — kế hoạch khả thi để bàn giao Increment: cách thức (an actionable plan for delivering the Increment) mà Developers dự định hoàn thành các item đã chọn.
Điểm cực kỳ quan trọng — và là nơi nhiều người sai: Sprint Goal là một phần CỦA Sprint Backlog, không phải là một thứ tách rời nằm bên cạnh. Sprint Backlog không phải chỉ là "what + how"; nó bao gồm cả "why". Khi đề thi hỏi "Sprint Backlog bao gồm những gì?", nếu đáp án nào thiếu Sprint Goal thì đáp án đó không đầy đủ.
Sprint Backlog là "kế hoạch của Developers, cho Developers"
Scrum Guide nói rõ: "The Sprint Backlog is a plan by and for the Developers." Đây là một câu mang tính quyết định cho rất nhiều câu hỏi về quyền sở hữu (ownership).
- Ai sở hữu Sprint Backlog? Developers. Không phải Scrum Master, không phải Product Owner, không phải quản lý dự án.
- Ai được phép thay đổi Sprint Backlog trong Sprint? Chỉ Developers. Họ là người duy nhất có quyền cập nhật, thêm bớt task, điều chỉnh plan.
- Product Owner có thể thương lượng (negotiate) phạm vi với Developers nếu hiểu biết mới xuất hiện, nhưng PO không tự ý sửa Sprint Backlog.
Sprint Backlog là một bức tranh thời gian thực (real-time picture)
Sprint Backlog không phải tài liệu "viết một lần xong để đó". Scrum Guide mô tả nó là "a highly visible, real-time picture of the work that the Developers plan to accomplish during the Sprint." Nghĩa là:
- Nó được cập nhật liên tục trong suốt Sprint, đặc biệt là tại Daily Scrum khi Developers inspect tiến độ và adapt kế hoạch.
- Khi Developers học được điều gì mới — phát hiện một task bị bỏ sót, một task hóa ra không cần thiết, hay khối lượng công việc lớn hơn dự kiến — họ cập nhật Sprint Backlog ngay.
- Có đủ chi tiết để họ có thể inspect tiến độ tại Daily Scrum.
Commitment của Sprint Backlog: Sprint Goal
Một trong những đóng góp lớn của Scrum Guide 2020 là gắn mỗi artifact với một commitment để tăng tính minh bạch (transparency) và sự tập trung (focus):
- Product Backlog → commitment là Product Goal
- Sprint Backlog → commitment là Sprint Goal
- Increment → commitment là Definition of Done
Sprint Goal là commitment vì nó cho Developers một mục tiêu chung để hướng tới, tạo sự gắn kết và linh hoạt. Nếu giữa Sprint, Developers nhận ra một vài Product Backlog Item không cần thiết để đạt Sprint Goal, họ có thể bỏ chúng đi mà vẫn hoàn thành commitment. Ngược lại, họ có thể thêm việc nếu việc đó phục vụ Sprint Goal. Cái neo là Goal, không phải danh sách item.
Phân biệt nhanh để khỏi nhầm
- Sprint Goal là commitment, không phải toàn bộ artifact.
- Tập PBI đã chọn + plan là phần "vật chất" của artifact.
- Sprint Backlog là tập con (subset) của Product Backlog cộng thêm Sprint Goal và plan. Nó không chứa toàn bộ Product Backlog.
Tình huống thực tế
Tình huống 1 — Tiki và "cái board không phải là Sprint Backlog"
Hãy hình dung một nhóm phát triển tại một công ty thương mại điện tử lớn ở Việt Nam, ta gọi là nhóm Checkout của Tiki (bối cảnh giả định hợp lý). Nhóm có 6 Developers, dùng Jira với ba cột quen thuộc: To Do, In Progress, Done. Sprint kéo dài 2 tuần.
Trong một buổi audit nội bộ, một Agile Coach mới về hỏi nhóm: "Sprint Goal của Sprint này là gì?" Cả nhóm im lặng vài giây. Một bạn dev trả lời: "Tụi em làm 14 ticket trong Sprint này, đây board nè anh." Coach hỏi tiếp: "Vậy nếu anh xóa 14 ticket đó đi và chỉ để lại một câu, câu đó là gì?" Không ai trả lời được.
Diễn giải: Nhóm này có "what" (14 ticket) và "how" (cái board chia task), nhưng thiếu hẳn "why" — Sprint Goal. Cái board Jira của họ chỉ là phần thân của Sprint Backlog, còn thiếu linh hồn. Hậu quả thực tế: khi giữa Sprint phát hiện một ticket phức tạp hơn dự kiến, nhóm không biết nên hy sinh ticket nào, vì không có Goal để làm điểm neo quyết định. Mọi ticket đều "quan trọng như nhau", và họ ôm hết, dẫn tới cuối Sprint không hoàn thành nổi việc gì cho ra hồn.
Bài học: Sprint Backlog mà thiếu Sprint Goal thì không phải Sprint Backlog đúng nghĩa. Một board Jira không tự động là Sprint Backlog. Goal là cái cho phép nhóm linh hoạt thương lượng scope mà vẫn giữ được hướng đi.
Tình huống 2 — Một fintech ở Singapore và việc PO "đẩy thêm việc giữa Sprint"
Một startup fintech ở Singapore, sản phẩm là ví điện tử. Sprint đang chạy đến ngày thứ 4 thì có một đối tác ngân hàng yêu cầu gấp một tính năng mới. Product Owner lập tức vào Jira, tự tay thêm 3 ticket mới vào Sprint hiện tại và gán cho Developers, kèm tin nhắn "ưu tiên cao nhất, làm liền".
Scrum Master của nhóm phản ứng: anh không cấm việc thêm — Scrum không cấm thêm việc vào Sprint nếu nó phục vụ Sprint Goal. Nhưng anh chỉ ra hai vấn đề. Thứ nhất, PO không phải người được tự ý sửa Sprint Backlog — đó là kế hoạch của và cho Developers. Việc thêm scope phải được thương lượng với Developers, không phải áp đặt. Thứ hai, 3 ticket mới này chẳng liên quan gì đến Sprint Goal hiện tại (đang là "hoàn thiện luồng nạp tiền qua QR"), nên nhồi vào sẽ phá vỡ focus.
Cách xử lý đúng: Scrum Master facilitate một cuộc trao đổi ngắn. Nếu yêu cầu mới thật sự khẩn cấp đến mức làm Sprint Goal trở nên vô nghĩa, thì lựa chọn nằm ở khả năng hủy Sprint (chỉ PO mới có quyền hủy — chi tiết ở Bài 36). Nếu không, nó được đưa vào Product Backlog và xem xét cho Sprint sau.
Bài học: Quyền sở hữu Sprint Backlog thuộc về Developers. PO thương lượng, không áp đặt. Và mọi thay đổi scope đều phải soi qua lăng kính Sprint Goal — nếu không phục vụ Goal, nó không thuộc về Sprint này.
Tình huống 3 — Nhóm ở FPT Software và Daily Scrum làm Sprint Backlog "sống"
Một nhóm tại FPT Software làm dự án outsourcing cho khách Nhật. Ban đầu nhóm coi Sprint Backlog là cái họ lập ra trong Sprint Planning rồi để nguyên. Ở Daily Scrum, họ chỉ "báo cáo status" cho Scrum Master nghe, không động đến Sprint Backlog.
Đến giữa Sprint, một Developer phát hiện rằng để hoàn thành item "tích hợp API thanh toán", cần thêm một bước xử lý webhook mà lúc Planning không ai lường tới. Theo thói quen cũ, bạn ấy cứ âm thầm làm thêm mà không cập nhật vào Sprint Backlog. Kết quả: tại Daily Scrum, bức tranh tiến độ bị méo — board hiển thị "gần xong" trong khi thực tế còn cả một mảng việc ẩn. Transparency bị phá vỡ.
Sau khi được Scrum Master coaching, nhóm thay đổi: mỗi khi học được điều mới, họ cập nhật Sprint Backlog ngay trong ngày — thêm task webhook vào, điều chỉnh kế hoạch. Daily Scrum trở thành nơi họ inspect chính Sprint Backlog (real-time picture) và adapt plan để vẫn đạt Sprint Goal.
Bài học: Sprint Backlog là bức tranh thời gian thực, được Developers cập nhật liên tục, ít nhất là mỗi ngày tại Daily Scrum. Một Sprint Backlog "chết" (không cập nhật) sẽ phá hủy tính minh bạch và khiến Daily Scrum mất ý nghĩa.
Hướng dẫn từng bước
Dưới đây là cách một Sprint Backlog hình thành và tiến hóa, nhìn từ góc độ artifact (không đi sâu vào kỹ thuật facilitate Sprint Planning):
- Bắt đầu từ Sprint Planning — xác định "why". Toàn Scrum Team cùng craft Sprint Goal. Sprint Goal này trở thành phần đầu tiên và là commitment của Sprint Backlog. Goal phải đủ rõ để làm điểm neo cho mọi quyết định trong Sprint.
- Chọn "what" — tập Product Backlog Item. Developers, qua thảo luận với PO, chọn các PBI từ Product Backlog mà họ tin có thể hoàn thành trong Sprint để phục vụ Sprint Goal. Tập này trở thành phần thứ hai của Sprint Backlog.
- Lập "how" — kế hoạch khả thi. Developers phân rã các PBI đã chọn thành các đơn vị công việc nhỏ hơn (thường là task), tạo thành actionable plan để bàn giao Increment. Mức chi tiết do chính Developers quyết định.
- Hiển thị minh bạch. Đưa Sprint Backlog ra một nơi mọi người đều thấy — board vật lý hoặc Jira/Trello/Azure DevOps. Nhớ: cái board chỉ là biểu diễn của Sprint Backlog, và phải kèm Sprint Goal được hiển thị rõ ràng.
- Cập nhật mỗi ngày tại Daily Scrum. Developers inspect tiến độ so với Sprint Goal, adapt kế hoạch (the how) nếu cần. Thêm task mới phát sinh, bỏ task không cần, điều chỉnh thứ tự.
- Thương lượng scope khi cần. Nếu trong Sprint biết thêm điều gì, Developers và PO có thể renegotiate phạm vi (thêm/bớt PBI) — nhưng Sprint Goal giữ nguyên. Đây là cách Scrum cân bằng giữa cam kết và linh hoạt.
- Đóng Sprint Backlog tại Sprint Review. Khi Sprint kết thúc, công việc chưa xong không tự động chuyển sang Sprint sau; nó quay về Product Backlog để PO sắp xếp lại thứ tự. Sprint Backlog của Sprint mới sẽ được lập lại từ đầu.
Lỗi thường gặp & mẹo
Lỗi 1 — Nghĩ Sprint Backlog = danh sách task. Sai. Nó là Sprint Goal (why) + tập PBI đã chọn (what) + plan (how). Thiếu Sprint Goal là thiếu một phần ba artifact.
Lỗi 2 — Tin rằng Scrum Master hoặc PO sở hữu Sprint Backlog. Sai. Developers sở hữu. Chỉ Developers được sửa. PO thương lượng scope, không áp đặt.
Lỗi 3 — Coi Sprint Backlog là bất biến sau Planning. Sai. Nó là real-time picture, cập nhật liên tục, đặc biệt tại Daily Scrum.
Lỗi 4 — Lẫn lộn "scope thay đổi được" với "Goal thay đổi được". Scope có thể được làm rõ và thương lượng lại; Sprint Goal thì giữ nguyên suốt Sprint. Đây là cái bẫy kinh điển của PSM I.
Lỗi 5 — Hiểu commitment là "phải làm xong 100% item đã chọn". Sai. Commitment của Sprint Backlog là Sprint Goal — một mục tiêu, một điểm neo cho tính minh bạch, không phải lời hứa hoàn thành toàn bộ scope. Số lượng PBI hoàn thành có thể khác dự kiến mà Sprint vẫn thành công nếu Goal đạt được.
Lỗi 6 — Nhồi toàn bộ Product Backlog vào Sprint Backlog. Sprint Backlog chỉ chứa một tập con các PBI được chọn cho Sprint này, không phải toàn bộ.
Mẹo thi cử: Khi gặp câu hỏi về Sprint Backlog, hãy tự hỏi ba điều: (a) Đáp án có nhận đúng ba phần why–what–how không? (b) Đáp án có gán đúng quyền sở hữu cho Developers không? (c) Đáp án có phân biệt được scope (co giãn) với Sprint Goal (cố định) không? Lọc qua ba câu hỏi này, bạn sẽ tránh được phần lớn các bẫy.
Mẹo nhớ commitment: Ghép cặp artifact–commitment thành một câu thần chú — "Product Backlog cam kết bằng Product Goal, Sprint Backlog cam kết bằng Sprint Goal, Increment cam kết bằng Definition of Done." Đọc đi đọc lại đến khi bật ra tự động.
Bài tập thực hành
- Tự kiểm tra định nghĩa: Không nhìn tài liệu, viết ra ba phần của Sprint Backlog kèm từ khóa why/what/how cho từng phần. Sau đó đối chiếu với bài.
- Phân vai ownership: Với mỗi tình huống sau, xác định ai có quyền/trách nhiệm và hành động đúng là gì: (a) PO muốn thêm 2 PBI vào Sprint đang chạy; (b) Một Developer muốn bỏ một PBI vì thấy không cần để đạt Sprint Goal; (c) Scrum Master muốn sắp xếp lại thứ tự task trên board.
- Phân tích tình huống Tiki: Quay lại Tình huống 1. Hãy viết một Sprint Goal giả định cho nhóm Checkout đó, rồi chỉ ra: nếu giữa Sprint một ticket phình to, Goal đó giúp họ quyết định hy sinh ticket nào như thế nào.
- Bẫy commitment: Viết một câu trả lời ngắn (2–3 câu) giải thích vì sao "không hoàn thành hết PBI đã chọn nhưng đạt Sprint Goal" vẫn có thể coi là một Sprint thành công về mặt commitment.
- Soi câu hỏi mẫu: Tự đặt 3 câu hỏi trắc nghiệm dạng PSM I về Sprint Backlog (mỗi câu 4 đáp án), trong đó cài ít nhất một bẫy về ownership và một bẫy về scope-vs-goal. Tự giải và giải thích vì sao các đáp án sai lại sai.
Tóm tắt
- Sprint Backlog là một artifact của Scrum, gồm ba phần: Sprint Goal (why) + tập Product Backlog Item được chọn (what) + kế hoạch khả thi để bàn giao Increment (how).
- Commitment của Sprint Backlog là Sprint Goal — một điểm neo cho tính minh bạch và focus, không phải lời hứa hoàn thành toàn bộ scope.
- Sprint Backlog là kế hoạch của và cho Developers: Developers sở hữu và là người duy nhất được thay đổi nó. PO thương lượng scope, không áp đặt.
- Nó là bức tranh thời gian thực, cập nhật liên tục, đặc biệt tại Daily Scrum khi Developers inspect và adapt.
- Scope có thể được làm rõ và thương lượng lại; Sprint Goal giữ nguyên suốt Sprint. Đây là cái bẫy thi cử quan trọng nhất.
- Một cái board Jira không tự động là Sprint Backlog nếu thiếu Sprint Goal và không được cập nhật sống động.