Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn là Scrum Master của một nhóm 6 Developer tại một startup fintech ở TP.HCM. Mỗi sáng, Daily Scrum trôi qua trong sự nhạt nhẽo: mỗi người báo cáo "hôm qua tôi làm task A, hôm nay tôi làm task B" — rồi giải tán. Sprint Backlog có 18 mục, mỗi người ôm vài mục rời rạc, ai làm việc nấy. Đến cuối Sprint, nhóm hoàn thành... một nửa số mục, nhưng không có cái gì "chạy được" để demo cho stakeholder. Mọi người làm việc rất chăm, rất bận rộn, nhưng kết quả lại tản mát, không tạo ra giá trị nào rõ ràng.
Vấn đề ở đây không phải là kỹ năng, không phải là năng suất. Vấn đề là nhóm thiếu một thứ gắn kết: Sprint Goal.
Trong kỳ thi PSM I, Sprint Goal là một trong những khái niệm bị hiểu sai nhiều nhất — và cũng là một trong những chủ đề được hỏi nhiều nhất. Người ta thường nhầm Sprint Goal với "danh sách những việc cần làm trong Sprint" (đó là Sprint Backlog), hoặc nghĩ rằng Sprint Goal chỉ là một câu khẩu hiệu cho vui. Sự thật sâu sắc hơn nhiều: theo Scrum Guide 2020, Sprint Goal là Commitment (cam kết) của Sprint Backlog — là cái "tại sao" làm cho cả Sprint có ý nghĩa.
Bài học này sẽ giúp bạn hiểu thấu đáo Sprint Goal: nó là gì, vì sao nó tạo ra sự coherence (gắn kết) cho cả nhóm, ai tạo ra nó, và nó vận hành như thế nào trong suốt Sprint. Đây là kiến thức vừa thi cử, vừa thực chiến.
Khái niệm cốt lõi
Sprint Goal là gì theo Scrum Guide 2020?
Scrum Guide 2020 định nghĩa rõ ràng: "The Sprint Goal is the single objective for the Sprint." — Sprint Goal là mục tiêu duy nhất của Sprint. Nó là Commitment của Sprint Backlog.
Hãy nhớ cấu trúc này, vì PSM I rất hay test: mỗi Artifact trong Scrum đều chứa một Commitment đi kèm để tăng tính minh bạch và tập trung.
- Product Backlog có Commitment là Product Goal.
- Sprint Backlog có Commitment là Sprint Goal.
- Increment có Commitment là Definition of Done.
Vì sao Sprint Goal tạo ra coherence?
Đây là điểm cốt lõi nhất, và cũng là từ khóa mà Scrum Guide dùng: coherence (sự gắn kết, nhất quán).
Scrum Guide viết: "The Sprint Goal creates coherence and focus, encouraging the Scrum Team to work together rather than on separate initiatives."
Hãy đọc kỹ câu này. Nếu không có Sprint Goal, Developers dễ rơi vào tình trạng làm việc song song nhưng rời rạc (parallel disconnected work) — mỗi người ôm một task không liên quan gì đến nhau, giống như sáu người chèo thuyền nhưng mỗi người chèo về một hướng. Sprint Goal đóng vai trò như ngôi sao Bắc Đẩu chung: nó buộc tất cả mọi người hướng về cùng một mục tiêu, làm việc cùng nhau thay vì rời rạc.
Khi có một mục tiêu chung, Developers tự nhiên sẽ phối hợp: nếu một người gặp khó khăn ở phần ảnh hưởng đến Sprint Goal, những người khác sẽ xúm vào giúp, vì đó là mục tiêu chung của họ, chứ không phải "việc của riêng anh ta". Đó chính là coherence.
Sprint Goal mang lại sự linh hoạt (flexibility)
Một điểm tinh tế mà nhiều người bỏ qua: Sprint Goal tạo ra sự linh hoạt về phạm vi (scope). Scrum Guide nói rõ: "As the Developers work during the Sprint, they keep the Sprint Goal in mind. If the work turns out to be different than they expected, they collaborate with the Product Owner to negotiate the scope of the Sprint Backlog within the Sprint without affecting the Sprint Goal."
Nghĩa là: trong Sprint, scope có thể được thương lượng lại giữa Developers và Product Owner — thêm bớt, điều chỉnh các mục — miễn là Sprint Goal vẫn đạt được. Sprint Goal cố định, nhưng cách thức đạt được nó (các mục cụ thể) thì mềm dẻo. Điều này khác hẳn tư duy "đã commit là phải làm đủ 100% số mục đã chọn". Bạn cam kết với mục tiêu, không phải cam kết với danh sách task.
Ai tạo ra Sprint Goal? Khi nào?
Sprint Goal được toàn bộ Scrum Team tạo ra (crafted) trong Sprint Planning. Đây là điểm PSM I rất hay bẫy.
- Sprint Goal không phải do Product Owner áp đặt một mình.
- Sprint Goal không phải do Scrum Master quyết định.
- Trong Sprint Planning, Product Owner đề xuất sản phẩm có thể tăng giá trị và tiện ích như thế nào trong Sprint này; cả Scrum Team cùng cộng tác để định hình một Sprint Goal truyền đạt vì sao Sprint này có giá trị với các bên liên quan.
Một Sprint chỉ có MỘT Sprint Goal
Sprint Goal là "the single objective" — mục tiêu duy nhất. Một Sprint không có hai, ba Sprint Goal. Nếu nhóm cảm thấy cần nhiều mục tiêu rời rạc, đó là dấu hiệu Sprint thiếu trọng tâm. Việc cô đọng thành một mục tiêu duy nhất chính là cách Scrum ép nhóm phải tập trung.
Tình huống thực tế
Tình huống 1: Tiki và chiến dịch Sale 11.11
Giả định một nhóm phát triển tại Tiki chuẩn bị cho mùa sale lớn 11.11. Trước khi áp dụng Sprint Goal một cách nghiêm túc, Sprint Backlog của họ trông như thế này: "Sửa bug giỏ hàng", "Thêm filter danh mục mỹ phẩm", "Refactor API thanh toán", "Cập nhật banner trang chủ", "Tối ưu tốc độ load ảnh". Mười hai mục, không liên quan gì nhau.
Đến Sprint Review, họ hoàn thành 8/12 mục, nhưng Giám đốc sản phẩm hỏi: "Vậy hệ thống đã sẵn sàng chịu tải cho 11.11 chưa?" — Không ai trả lời được, vì các mục được làm rải rác, không cái nào hoàn chỉnh một bức tranh.
Diễn giải: Scrum Master đề xuất nhóm đặt một Sprint Goal duy nhất cho Sprint kế tiếp: "Đảm bảo luồng thanh toán chịu được tải 5.000 đơn hàng đồng thời mà không lỗi." Ngay lập tức, mọi thứ thay đổi. Tại Daily Scrum, Developers không còn báo cáo task rời rạc; họ hỏi nhau "việc của chúng ta hôm nay có giúp luồng thanh toán chịu tải tốt hơn không?". Khi một Developer phát hiện việc "Cập nhật banner" không liên quan gì đến Sprint Goal, Product Owner đồng ý đẩy mục đó sang Sprint sau. Khi một bottleneck mới ở tầng database xuất hiện, ba người xúm vào xử lý cùng nhau vì nó đe dọa Sprint Goal.
Bài học rút ra: Sprint Goal biến một đống task rời rạc thành một nỗ lực gắn kết. Scope (các mục cụ thể) được thương lượng linh hoạt trong Sprint, nhưng mục tiêu thì cố định. Cuối Sprint, câu hỏi của Giám đốc sản phẩm có câu trả lời rõ ràng: "Có, chúng tôi đã đạt mục tiêu."
Tình huống 2: Startup giao đồ ăn ở Jakarta — khi không có Sprint Goal
Một startup giao đồ ăn tại Jakarta (gọi là FoodGo) có nhóm 7 Developer. Văn hóa của họ là "làm càng nhiều task càng tốt". Trong một Sprint, Product Owner nhồi 25 mục Product Backlog vào Sprint Backlog mà không có một Sprint Goal nào — lý do là "tất cả đều quan trọng".
Kết quả: Daily Scrum kéo dài 30 phút vì mỗi người báo cáo một mớ task khác nhau và không ai hiểu bức tranh tổng thể. Khi một Developer nghỉ ốm 3 ngày, không ai dám đụng vào phần việc của anh ta vì "không biết nó phục vụ cho cái gì". Cuối Sprint, nhóm hoàn thành 15/25 mục nhưng không có tính năng nào sẵn sàng ra mắt. Stakeholder thất vọng vì không thấy giá trị nào hiện hữu.
Diễn giải: Vì không có Sprint Goal, nhóm mất khả năng prioritize trong Sprint — khi bất ngờ xảy ra (Developer nghỉ ốm), họ không có tiêu chí nào để quyết định "việc gì cần hi sinh, việc gì phải giữ". Mọi thứ đều quan trọng nghĩa là không có gì thực sự quan trọng. Họ cũng mất luôn khả năng tự tổ chức phối hợp, vì không có mục tiêu chung để xúm lại.
Bài học rút ra: Sprint Goal không chỉ là "câu khẩu hiệu". Nó là công cụ ra quyết định trong Sprint. Khi có biến cố, nhóm hỏi: "Việc này có giúp đạt Sprint Goal không?" — và từ đó biết cái gì cần giữ, cái gì có thể bỏ. Không có Sprint Goal, nhóm mất la bàn.
Tình huống 3: Nhóm Banking tại Singapore — Sprint Goal cứu Sprint khỏi bị cancel
Một nhóm tại một ngân hàng số ở Singapore đặt Sprint Goal: "Cho phép khách hàng mở tài khoản tiết kiệm online hoàn toàn không cần ra chi nhánh." Sprint Backlog gồm 10 mục: form đăng ký, xác thực eKYC, tích hợp API ngân hàng lõi, màn hình xác nhận, email thông báo...
Giữa Sprint, đội pháp chế thông báo rằng tính năng "lãi suất khuyến mãi" (vốn là 2 trong 10 mục) phải hoãn vì chưa được duyệt. Trong một nhóm không có Sprint Goal rõ ràng, đây có thể là khủng hoảng. Nhưng nhóm này nhìn lại Sprint Goal và nhận ra: hai mục bị hoãn không phải là điều kiện cần để đạt Sprint Goal "mở tài khoản tiết kiệm online". Họ cùng Product Owner thương lượng, gỡ hai mục đó ra, thay bằng việc làm chắc luồng xác thực eKYC. Sprint Goal vẫn đạt được, Sprint không cần hủy.
Diễn giải: Sprint Goal cho nhóm sự linh hoạt về scope mà không phá vỡ cam kết. Vì cam kết là với mục tiêu, chứ không phải với danh sách 10 mục cố định, nhóm có thể điều chỉnh các mục miễn là mục tiêu vẫn còn nguyên. Lưu ý quan trọng cho PSM I: chỉ khi bản thân Sprint Goal trở nên lỗi thời/không còn ý nghĩa thì Sprint mới bị hủy (cancel) — và chỉ Product Owner mới có quyền hủy Sprint.
Bài học rút ra: Sprint Goal là điểm tựa cho sự linh hoạt. Nó tách bạch giữa "mục tiêu bất biến" và "phương tiện có thể thay đổi". Đó là sức mạnh của empiricism trong thực hành.
Hướng dẫn từng bước
Đây là cách vận hành Sprint Goal đúng "by the book" qua từng giai đoạn của Sprint:
Bước 1 — Trong Sprint Planning, bắt đầu từ "tại sao". Product Owner trình bày mục tiêu sản phẩm (Product Goal) và đề xuất Sprint này có thể tăng giá trị như thế nào. Đừng nhảy ngay vào việc chọn task. Hãy thảo luận: "Nếu Sprint này thành công, điều giá trị nhất mà chúng ta đạt được là gì?"
Bước 2 — Cả Scrum Team cùng craft Sprint Goal. Đây là nỗ lực cộng tác của toàn nhóm, không phải PO áp đặt. Cô đọng thành một mục tiêu duy nhất, diễn đạt được giá trị (outcome), không phải liệt kê task (output). Ví dụ tốt: "Khách hàng có thể thanh toán bằng ví điện tử." Ví dụ kém: "Hoàn thành 8 user story về thanh toán."
Bước 3 — Hoàn tất Sprint Goal trước khi Sprint Planning kết thúc. Đây là yêu cầu bắt buộc của Scrum Guide. Sau khi có Sprint Goal, Developers mới chọn các mục Product Backlog phù hợp và lập kế hoạch để giao Increment.
Bước 4 — Dùng Sprint Goal làm kim chỉ nam tại Daily Scrum. Daily Scrum là sự kiện để Developers inspect tiến độ hướng tới Sprint Goal và điều chỉnh Sprint Backlog. Mỗi ngày hãy hỏi: "Chúng ta có đang tiến gần Sprint Goal không? Nếu không, hôm nay cần điều chỉnh gì?"
Bước 5 — Thương lượng scope khi cần, giữ nguyên mục tiêu. Khi công việc hóa ra khác dự kiến, Developers cộng tác với Product Owner để điều chỉnh scope của Sprint Backlog — nhưng không ảnh hưởng đến Sprint Goal.
Bước 6 — Tại Sprint Review, kiểm chứng kết quả so với Sprint Goal. Cùng stakeholder xem xét Increment đã làm được gì và liệu Sprint Goal đã đạt hay chưa, từ đó điều chỉnh hướng đi tiếp theo.
Lỗi thường gặp & mẹo
Lỗi 1: Nhầm Sprint Goal với Sprint Backlog. Sprint Backlog là toàn bộ "cái gì + như thế nào" (các mục + kế hoạch); Sprint Goal là "tại sao" (mục tiêu duy nhất). Sprint Goal nằm trong Sprint Backlog như một thành phần, không phải là vật thay thế. Mẹo nhớ: Sprint Goal = Commitment của Sprint Backlog.
Lỗi 2: Viết Sprint Goal như một danh sách task. "Làm xong 10 user story" không phải Sprint Goal. Đó chỉ là output. Sprint Goal phải nói về giá trị/outcome. Mẹo: thử thêm chữ "để..." vào cuối — nếu không trả lời được "để làm gì", thì đó chưa phải mục tiêu.
Lỗi 3: Để Product Owner áp đặt Sprint Goal một mình. Sai. Sprint Goal do cả Scrum Team cùng craft. PO khởi xướng "tại sao", nhưng mục tiêu là sản phẩm chung.
Lỗi 4: Đặt nhiều Sprint Goal cho một Sprint. Một Sprint = một Sprint Goal duy nhất. Nhiều mục tiêu = mất focus.
Lỗi 5: Nghĩ rằng không đạt hết số mục thì Sprint thất bại. Sai. Cam kết là với Sprint Goal, không phải với số lượng mục. Nếu Sprint Goal đạt nhưng vài mục phụ chưa xong, Sprint vẫn thành công. Ngược lại, làm xong hết mục nhưng không tạo ra mục tiêu có giá trị thì cũng chưa hẳn thành công.
Lỗi 6: Nhầm về việc hủy Sprint. Sprint chỉ bị hủy khi Sprint Goal trở nên lỗi thời/vô nghĩa, và chỉ Product Owner có thẩm quyền hủy. Việc một vài mục bị bỏ giữa chừng không phải lý do để hủy Sprint.
Mẹo thi PSM I: Khi gặp câu hỏi có lựa chọn kiểu "Developers phải hoàn thành tất cả các mục đã chọn trong Sprint Backlog" — hãy cảnh giác, đáp án đó thường sai. Scrum cam kết với mục tiêu, không cam kết với phạm vi cố định.
Bài tập thực hành
Bài tập 1 — Phân biệt đúng/sai: Với mỗi phát biểu, xác định Đúng hay Sai theo Scrum Guide 2020, và giải thích ngắn:
- Sprint Goal phải được hoàn tất trước khi kết thúc Sprint Planning.
- Một Sprint có thể có nhiều Sprint Goal nếu công việc đa dạng.
- Scrum Master là người chịu trách nhiệm viết Sprint Goal.
- Scope của Sprint Backlog có thể được thương lượng lại trong Sprint mà không ảnh hưởng đến Sprint Goal.
- Nếu Developers không hoàn thành hết các mục đã chọn, Sprint coi như thất bại.
Bài tập 3 — Tình huống ra quyết định: Giữa Sprint, một mục chiếm khoảng 30% công sức bị phát hiện là không khả thi về kỹ thuật trong thời gian còn lại. Mục này không phải điều kiện cần để đạt Sprint Goal. Là Scrum Master, bạn hướng dẫn nhóm hành động theo các bước nào? Ai cần tham gia quyết định về scope?
(Gợi ý tự kiểm tra Bài tập 1: 1-Đúng; 2-Sai, chỉ một Sprint Goal duy nhất; 3-Sai, cả Scrum Team craft; 4-Đúng; 5-Sai, cam kết là với Sprint Goal.)
Tóm tắt
- Sprint Goal là mục tiêu duy nhất của Sprint và là Commitment của Sprint Backlog — tương ứng với Product Goal cho Product Backlog và Definition of Done cho Increment.
- Sprint Goal tạo ra coherence và focus, khuyến khích nhóm làm việc cùng nhau thay vì làm các nỗ lực rời rạc, song song mà không kết nối.
- Sprint Goal do toàn bộ Scrum Team cùng craft trong Sprint Planning và phải hoàn tất trước khi Sprint Planning kết thúc.
- Cam kết là với mục tiêu, không phải với danh sách mục cố định: scope có thể thương lượng giữa Developers và Product Owner trong Sprint, miễn là không ảnh hưởng Sprint Goal.
- Sprint Goal là kim chỉ nam tại Daily Scrum (inspect tiến độ tới Sprint Goal) và là thước đo tại Sprint Review.
- Sprint chỉ bị hủy khi Sprint Goal trở nên lỗi thời, và chỉ Product Owner có quyền hủy Sprint.