Mở đầu — vì sao bài này quan trọng
Nếu bạn đang ôn thi PSM I, có một câu hỏi gần như chắc chắn sẽ xuất hiện dưới nhiều biến thể khác nhau: "Sprint Backlog là gì đối với Developers — một cam kết (commitment) hay một dự báo (forecast)?" Và đây chính là nơi rất nhiều thí sinh trả lời sai, bởi vì trong tư duy quản lý dự án truyền thống, người ta đã quá quen với việc "cam kết" sẽ hoàn thành đúng phạm vi, đúng hạn.
Scrum 2020 dùng từ ngữ cực kỳ thận trọng và có chủ đích. Từ "commit" (cam kết cứng về phạm vi) đã bị loại bỏ khỏi mô tả Sprint Backlog từ phiên bản Scrum Guide 2011, và đến 2020 thì khái niệm cam kết (commitment) được tái định nghĩa hoàn toàn — nó gắn với mục tiêu, không gắn với danh sách công việc. Hiểu sai chỗ này không chỉ làm bạn mất điểm trong phòng thi, mà còn khiến bạn vận hành Scrum sai trong thực tế: ép team "cam kết" hoàn thành 100% Sprint Backlog, rồi biến mỗi Sprint Review thành một phiên xét xử khi có hạng mục chưa xong.
Bài học này tập trung làm rõ một ranh giới cốt lõi: Sprint Backlog là một forecast — dự báo tốt nhất của Developers; còn Sprint Goal mới là commitment. Tôi sẽ giải thích vì sao Scrum cố tình không "commit" về phạm vi, khái niệm capacity (năng lực) đứng ở đâu trong bức tranh này, và làm sao để vận dụng đúng cả khi thi lẫn khi làm việc thật.
Khái niệm cốt lõi
Forecast là gì trong Scrum?
Forecast (dự báo) là ước lượng tốt nhất tại thời điểm hiện tại về những gì Developers tin rằng họ có thể hoàn thành trong Sprint, dựa trên hiểu biết hiện có. Nó là một phán đoán có cơ sở, không phải một lời hứa chắc chắn.
Trong Scrum Guide 2020, Sprint Backlog được mô tả gồm ba phần: vì sao (Sprint Goal), cái gì (các Product Backlog item được chọn cho Sprint), và như thế nào (kế hoạch để chuyển những item đó thành một Increment). Phần "cái gì" — danh sách item được chọn — chính là phần mang bản chất forecast. Developers nhìn vào năng lực và hiểu biết của mình ở thời điểm Sprint Planning, rồi nói: "Chúng tôi tin mình có thể hoàn thành ngần này."
Điểm mấu chốt: forecast có thể thay đổi trong Sprint. Khi Developers học được điều mới, họ có thể đàm phán lại phạm vi với Product Owner — thêm, bớt, hoặc làm rõ các item — miễn là không làm ảnh hưởng đến Sprint Goal. Đây là tính chất "có thể điều chỉnh" (negotiable) đặc trưng của một dự báo. Bạn không "đàm phán lại" một cam kết cứng; nhưng bạn hoàn toàn có thể tinh chỉnh một dự báo khi có thông tin mới.
Commitment là gì trong Scrum 2020?
Đây là chỗ Scrum Guide 2020 tạo ra một thay đổi quan trọng về ngôn ngữ. Phiên bản 2020 giới thiệu khái niệm commitment gắn với từng artifact:
- Product Backlog có commitment là Product Goal.
- Sprint Backlog có commitment là Sprint Goal.
- Increment có commitment là Definition of Done.
Sự khác biệt này tinh tế nhưng cực kỳ then chốt cho PSM I:
| Yếu tố | Bản chất | Tính chất |
|---|---|---|
| Sprint Goal | Commitment | Cố định trong Sprint, không thương lượng lại |
| Các item trong Sprint Backlog | Forecast | Có thể điều chỉnh, miễn không hại Sprint Goal |
Capacity — năng lực — đứng ở đâu?
Capacity (năng lực) là lượng công việc thực tế mà team có thể đảm đương trong một Sprint, có tính đến những yếu tố như: số ngày làm việc, ngày nghỉ phép, lễ Tết, thời gian dành cho họp hành, hỗ trợ vận hành, hay thành viên đi đào tạo.
Lưu ý quan trọng cho người thi PSM I: Scrum Guide không hề bắt buộc dùng "capacity planning" hay bất kỳ công thức tính năng lực nào. Capacity là một kỹ thuật bổ trợ (complementary practice) giúp Developers đưa ra forecast hợp lý hơn, chứ không phải một thành phần chính thức của Scrum. Tương tự, "velocity" (vận tốc), "story points" cũng không nằm trong Scrum Guide.
Vai trò thật sự của capacity là làm cho forecast tốt hơn. Nếu tháng tới có Tết Nguyên đán và ba thành viên nghỉ một tuần, năng lực giảm rõ rệt, nên dự báo về số item hoàn thành cũng phải giảm theo. Nhưng dù tính toán capacity kỹ đến đâu, kết quả cuối cùng vẫn chỉ là một forecast, không bao giờ trở thành một cam kết cứng về phạm vi. Đây là lý do triết học sâu xa: Scrum dựa trên empiricism (chủ nghĩa thực nghiệm) — ta thừa nhận rằng công việc phát triển sản phẩm phức tạp đến mức không thể dự đoán chính xác tương lai. Cam kết cứng về phạm vi trong môi trường bất định là một lời hứa không trung thực.
Vì sao Scrum cố tình không "commit" về phạm vi?
Bởi vì phần lớn công việc Scrum giải quyết là công việc phức tạp (complex), nơi có nhiều ẩn số hơn là biến số đã biết. Trong môi trường như vậy:
- Ép cam kết phạm vi cứng buộc team phải hoặc đệm thời gian (padding) quá mức, hoặc hy sinh chất lượng để "kịp cam kết".
- Cam kết phạm vi cứng triệt tiêu khả năng học hỏi và điều chỉnh — vốn là trái tim của Scrum.
- Nó chuyển trọng tâm từ kết quả có giá trị (Sprint Goal) sang hoàn thành danh sách (output), dễ dẫn đến tình trạng "làm xong việc nhưng không tạo ra giá trị".
Tình huống thực tế
Ví dụ 1 — Tiki và bài học "cam kết 12 story, xong 9"
Một nhóm phát triển tại một sàn thương mại điện tử lớn ở Việt Nam (tạm gọi theo mô hình Tiki) có thói quen từ thời làm theo waterfall: mỗi đầu Sprint, Scrum Master cũ yêu cầu team "cam kết" hoàn thành 12 user story, ghi rõ ra để báo cáo lên cấp trên.
Sprint nào team cũng căng thẳng. Có Sprint họ làm xong 9/12 story, và Sprint Review biến thành buổi giải trình: "Vì sao thiếu 3 story?" Áp lực khiến team bắt đầu khai báo "xong" cả những story chưa đạt Definition of Done, đẩy nợ kỹ thuật và bug sang Sprint sau.
Khi một Scrum Master mới về, anh đổi cách tiếp cận. Thay vì cam kết "12 story", team xác định một Sprint Goal rõ ràng: "Cho phép khách hàng thanh toán bằng ví điện tử MoMo trong luồng checkout." Danh sách 12 story trở thành forecast — dự báo tốt nhất. Khi giữa Sprint phát hiện việc tích hợp MoMo phức tạp hơn dự kiến, team đàm phán với Product Owner, gạt 3 story phụ (không liên quan trực tiếp tới Sprint Goal) sang Sprint sau, dồn lực hoàn tất luồng thanh toán.
Kết quả: Sprint Goal đạt được — khách hàng thanh toán MoMo được. Ba story bị hoãn không còn là "thất bại", vì chúng vốn chỉ là dự báo. Bài học: khi cam kết là mục tiêu chứ không phải danh sách, team tập trung vào giá trị và minh bạch hơn, thay vì làm đẹp con số.
Ví dụ 2 — Startup fintech và Tết Nguyên đán
Một startup fintech tại TP.HCM có team 6 Developers, velocity trung bình khoảng 40 story point mỗi Sprint hai tuần. Đầu năm, họ lên kế hoạch cho Sprint trùng dịp Tết: 4 thành viên nghỉ phép tổng cộng 9 ngày-người trong Sprint.
Product Owner ban đầu muốn "vẫn lấy 40 point như mọi khi cho kịp deadline ra mắt tính năng vay tiêu dùng". Scrum Master can thiệp, hướng dẫn team tính lại capacity: trừ đi 9 ngày-người nghỉ, năng lực thực tế chỉ còn khoảng 60% bình thường. Forecast hợp lý cho Sprint này là khoảng 22–25 point.
Quan trọng hơn, team không "cam kết" con số 22 point đó. Họ đặt Sprint Goal khiêm tốn nhưng có giá trị: "Hoàn thiện và kiểm thử được luồng đăng ký khoản vay cơ bản (chưa gồm tính lãi suất động)." Khi Tết đến và một thành viên phải nghỉ thêm 2 ngày ngoài dự kiến, forecast lung lay, nhưng Sprint Goal vẫn đạt vì nó được phạm vi hóa vừa sức.
Bài học: capacity giúp tạo ra một forecast trung thực thay vì một con số ảo tưởng; còn Sprint Goal được đặt vừa sức với năng lực thực tế thì vẫn là kim chỉ nam vững vàng dù dự báo dao động.
Ví dụ 3 — Grab và việc đàm phán lại phạm vi giữa Sprint
Một team tại một công ty công nghệ khu vực Đông Nam Á (mô hình Grab) làm tính năng đặt xe theo nhóm. Sprint Goal: "Người dùng có thể tạo và chia sẻ một chuyến đi nhóm tối đa 4 người." Forecast ban đầu gồm 8 item, trong đó có 2 item về giao diện tùy biến màu nhóm và biểu tượng nhóm.
Đến giữa Sprint, Developers phát hiện logic chia hóa đơn cho nhóm phức tạp hơn nhiều so với ước lượng. Nếu cứ ôm đủ 8 item, họ sẽ làm dở dang nhiều thứ và trượt Sprint Goal. Họ chủ động ngồi lại với Product Owner. PO đồng ý rằng việc tùy biến màu và biểu tượng không cốt yếu cho mục tiêu, nên hai item đó được gỡ khỏi Sprint Backlog.
Lưu ý: đây không phải "bỏ cam kết". Sprint Goal — cam kết thật sự — vẫn nguyên vẹn và đạt được. Cái thay đổi chỉ là forecast về phạm vi công việc, và việc thay đổi này hoàn toàn hợp lệ trong Scrum, miễn không gây hại cho Sprint Goal.
Bài học: forecast linh hoạt là một tính năng, không phải lỗi. Khả năng đàm phán lại phạm vi mà vẫn giữ vững mục tiêu chính là điều phân biệt một team Scrum trưởng thành với một team chỉ "chạy danh sách".
Hướng dẫn từng bước
Đây là cách vận dụng đúng forecast và capacity trong một Sprint thực tế, bám sát tinh thần Scrum Guide:
- Bắt đầu từ Sprint Goal (commitment), không phải từ danh sách. Trong Sprint Planning, Product Owner đề xuất Product Goal đang hướng tới và giá trị Sprint cần tạo ra. Cả Scrum Team cùng tạo ra một Sprint Goal — đây là cam kết thật sự của Sprint.
- Đánh giá năng lực (capacity) một cách trung thực. Developers xem xét: số ngày làm việc thực tế, ngày nghỉ, lễ Tết, thời gian dành cho hỗ trợ vận hành hay họp. Đây là bước biến "ước lượng cảm tính" thành "dự báo có cơ sở".
- Chọn các Product Backlog item làm forecast. Dựa trên Sprint Goal và capacity, Developers — và chỉ Developers — quyết định lấy bao nhiêu item vào Sprint Backlog. Đây là forecast tốt nhất của họ, không ai được ép buộc số lượng.
- Lập kế hoạch "như thế nào". Developers chia nhỏ công việc đủ để biết mình có thể đạt Definition of Done. Việc này càng làm rõ thì forecast càng đáng tin.
- Trong Sprint, theo dõi và điều chỉnh forecast. Mỗi ngày tại Daily Scrum, Developers kiểm tra tiến độ hướng tới Sprint Goal và điều chỉnh Sprint Backlog khi cần. Nếu có việc phát sinh hoặc một item hóa ra không cần thiết, họ đàm phán lại phạm vi với Product Owner.
- Bảo vệ Sprint Goal bằng mọi giá hợp lý. Khi phải cắt giảm, hãy cắt những item không phục vụ trực tiếp Sprint Goal trước. Mục tiêu được giữ; dự báo được uốn nắn.
- Tại Sprint Review, kiểm tra Increment so với Sprint Goal, không phải so với danh sách item ban đầu. Câu hỏi đúng là "Ta có đạt được điều mình hướng tới không?", không phải "Ta có làm xong đủ 8 cái gạch đầu dòng không?".
Lỗi thường gặp & mẹo
Lỗi 1 — Coi Sprint Backlog là cam kết cứng. Đây là sai lầm phổ biến nhất và là cái bẫy số một trong PSM I. Hãy khắc cốt: Sprint Backlog (phần item) là forecast; chỉ Sprint Goal mới là commitment.
Lỗi 2 — Nghĩ rằng "không cam kết phạm vi" nghĩa là team được tùy tiện. Sai. Developers vẫn nỗ lực hết sức để hoàn thành forecast và đạt Sprint Goal. Forecast linh hoạt không phải cái cớ để buông lỏng trách nhiệm.
Lỗi 3 — Lẫn lộn capacity/velocity với Scrum chính thống. Trong phòng thi, nếu một câu hỏi ngụ ý rằng "Scrum yêu cầu tính velocity/capacity/story point", hãy cảnh giác — Scrum Guide không bắt buộc các kỹ thuật này. Chúng hữu ích nhưng là bổ trợ.
Lỗi 4 — Để người ngoài quyết định số lượng item. Chỉ Developers mới được quyết định lượng công việc đưa vào Sprint Backlog. Product Owner hay manager ép số lượng là vi phạm self-management.
Lỗi 5 — Đổ lỗi khi forecast không đạt đủ. Nếu Sprint Goal đạt nhưng vài item dự báo chưa xong, đó không phải thất bại. Hãy đưa các item chưa xong trở lại Product Backlog và để Product Owner sắp xếp lại thứ tự ưu tiên.
Mẹo ghi nhớ cho phòng thi: Nhẩm một câu thần chú — "Forecast = các item; Commitment = Sprint Goal. Item uốn theo thực tế; mục tiêu thì giữ vững." Khi gặp từ "commit" trong đề liên quan tới Sprint Backlog, gần như chắc chắn đáp án "đúng theo sách" sẽ né tránh ý "cam kết cứng về phạm vi".
Mẹo thực hành: Khi viết Sprint Goal, hãy đảm bảo nó diễn đạt kết quả/giá trị, không phải liệt kê công việc. "Hoàn thành 8 story" không phải Sprint Goal; "Cho phép khách thanh toán bằng MoMo" mới là Sprint Goal.
Bài tập thực hành
- Phân loại nhanh. Với mỗi mục sau, ghi rõ nó là forecast hay commitment: (a) danh sách 10 user story chọn cho Sprint; (b) câu "Cho phép người dùng đặt lại mật khẩu qua email"; (c) Product Goal; (d) số story point team dự kiến hoàn thành. (Gợi ý đáp án: a = forecast; b = commitment dạng Sprint Goal; c = commitment của Product Backlog; d = forecast.)
- Tính capacity. Team bạn có 5 Developers, Sprint 2 tuần (10 ngày làm việc). Tuần tới có 1 ngày lễ, một thành viên nghỉ 3 ngày, mỗi thành viên dành trung bình 20% thời gian cho hỗ trợ vận hành. Hãy ước lượng số ngày-người thực sự dành cho công việc Sprint, và thảo luận: con số này tạo ra forecast hay commitment?
- Viết lại Sprint Goal. Đây là một "Sprint Goal" sai: "Hoàn thành tất cả 7 item trong Sprint Backlog." Hãy viết lại thành một Sprint Goal đúng cho bối cảnh một ứng dụng giao đồ ăn (gợi ý: nói về giá trị/kết quả người dùng nhận được).
- Tình huống đàm phán. Giữa Sprint, Developers nhận ra sẽ không kịp 2 trong 6 item, nhưng 2 item đó không cốt yếu cho Sprint Goal. Hãy mô tả họ nên làm gì, ai cần tham gia quyết định, và vì sao điều này không vi phạm Scrum.
Tóm tắt
- Sprint Backlog (phần các item được chọn) là một forecast — dự báo tốt nhất của Developers tại thời điểm Sprint Planning, có thể điều chỉnh khi có thông tin mới.
- Sprint Goal là commitment — cam kết thật sự của Sprint trong Scrum 2020; nó định hướng và giữ tính tập trung, không thay đổi trong Sprint.
- Scrum 2020 gắn mỗi artifact với một commitment: Product Backlog → Product Goal; Sprint Backlog → Sprint Goal; Increment → Definition of Done.
- Scrum cố tình không "commit" về phạm vi vì công việc phát triển sản phẩm là phức tạp; cam kết phạm vi cứng đi ngược lại empiricism và triệt tiêu khả năng học hỏi, điều chỉnh.
- Capacity, velocity, story point là kỹ thuật bổ trợ, không bắt buộc trong Scrum Guide; chúng giúp forecast tốt hơn nhưng không biến forecast thành cam kết cứng.
- Chỉ Developers quyết định lượng công việc đưa vào Sprint Backlog; họ có thể đàm phán lại phạm vi với Product Owner miễn không gây hại cho Sprint Goal.
- Trong phòng thi: khi thấy từ "commit" gắn với Sprint Backlog, hãy nghiêng về đáp án phân biệt rõ forecast và commitment.