Mở đầu — vì sao bài này quan trọng
Nếu bạn từng xem một đội Scrum chạy hết Sprint này đến Sprint khác mà vẫn cảm giác "làm xong mấy task nhưng chẳng đi tới đâu", thì khả năng cao họ đang thiếu một thứ: Sprint Goal. Đây là một trong những khái niệm bị hiểu sai nhiều nhất trong Scrum, và cũng là phần xuất hiện dày đặc trong đề thi PSPO I.
Rất nhiều ứng viên rớt PSPO I không phải vì không thuộc Scrum Guide, mà vì hiểu Sprint Goal theo kiểu "danh sách việc cần làm trong Sprint" — một quan niệm sai hoàn toàn. Sprint Goal không phải là tổng các Product Backlog Item (PBI) được kéo vào Sprint. Nó là một mục đích duy nhất, một lý do để cả Scrum Team đoàn kết và làm việc với nhau trong suốt Sprint.
Quan trọng hơn, ở vai trò Product Owner, bạn không thể tách Sprint Goal khỏi Product Goal. Hai commitment này tạo thành một chuỗi: Product Goal là đích đến dài hạn của sản phẩm, còn mỗi Sprint Goal là một bước cụ thể, đo lường được, tiến về phía đích đó. Hiểu được mối quan hệ này chính là sự khác biệt giữa một PO biết "viết yêu cầu" và một PO biết "dẫn dắt sản phẩm".
Trong bài này, chúng ta sẽ đào sâu Sprint Goal: nó là gì, ai tạo ra nó, vì sao nó là commitment, và đặc biệt là nó gắn kết với Product Goal ra sao. Đây là kiến thức nền tảng để bạn không chỉ vượt qua kỳ thi mà còn trở thành một PO thực sự tạo ra giá trị.
Khái niệm cốt lõi
Sprint Goal là gì?
Theo Scrum Guide 2020, Sprint Goal là mục tiêu duy nhất (single objective) của Sprint. Nó là commitment (cam kết) của Sprint Backlog — giống như cách Product Goal là commitment của Product Backlog, và Definition of Done là commitment của Increment.
Hãy nhớ cấu trúc ba lớp này, vì nó hay xuất hiện trong đề thi:
- Product Backlog → commitment là Product Goal
- Sprint Backlog → commitment là Sprint Goal
- Increment → commitment là Definition of Done
Đặc tính của Sprint Goal
Có vài đặc tính bạn cần khắc cốt ghi tâm:
Một Sprint Goal cho mỗi Sprint. Đây là điểm rất hay bị bẫy trong đề thi. Mỗi Sprint chỉ có đúng một Sprint Goal — không phải hai, không phải ba. Nếu đội cảm thấy cần nhiều mục tiêu, đó thường là dấu hiệu Sprint Goal được viết quá hẹp (kiểu task), thay vì là một mục đích bao quát đủ rộng.
Sprint Goal tạo sự gắn kết (coherence). Scrum Guide dùng chính xác từ này: Sprint Goal khiến Developers làm việc cùng nhau thay vì làm những việc riêng lẻ. Nó là chất keo gắn các PBI lại với nhau thành một khối có ý nghĩa.
Sprint Goal cung cấp tính linh hoạt (flexibility). Đây là điểm tinh tế. Phạm vi (scope) công việc cụ thể có thể được thương lượng lại giữa PO và Developers trong Sprint — miễn là không làm ảnh hưởng tới Sprint Goal. Nếu Developers phát hiện cần thêm hoặc bớt PBI để đạt được Sprint Goal, họ có thể điều chỉnh. Sprint Goal là cố định; cách đạt được nó thì linh hoạt.
Sprint Goal được tạo ra tại Sprint Planning. Toàn bộ Scrum Team cùng tạo Sprint Goal trong Sprint Planning. Đây là sản phẩm của sự hợp tác, không phải PO áp đặt một mình.
Ai chịu trách nhiệm về Sprint Goal?
Câu trả lời cho PSPO I: Cả Scrum Team cùng tạo Sprint Goal, nhưng vai trò có sự phân công.
Product Owner mang đến mục tiêu kinh doanh và giá trị — PO đề xuất Sprint Goal nên hướng tới điều gì để tối đa hóa giá trị, dựa trên Product Goal và Product Backlog đã được sắp xếp thứ tự. Tuy nhiên, Sprint Goal cuối cùng là kết quả thương lượng: Developers đánh giá xem họ có thể làm gì, và cả đội cùng chốt một Sprint Goal khả thi và có ý nghĩa.
Đây là điểm khác biệt quan trọng so với quan niệm cũ: PO không đơn phương "giao" Sprint Goal. PO định hướng giá trị, Developers định hình tính khả thi, và Sprint Goal nảy sinh từ cuộc đối thoại đó.
Product Goal — đích đến mà Sprint Goal phục vụ
Để hiểu mối quan hệ, ta cần nhắc lại Product Goal (chi tiết bạn đã học ở Bài 9). Product Goal là mục tiêu tương lai dài hạn của sản phẩm — trạng thái mà cả đội đang nỗ lực đạt tới. Sản phẩm chỉ có một Product Goal tại một thời điểm; phải hoàn thành (hoặc từ bỏ) nó trước khi nhận một Product Goal mới.
Bây giờ là phần quan trọng nhất của bài này:
> Mỗi Sprint Goal là một bước đệm (stepping stone) tiến về phía Product Goal.
Hãy hình dung Product Goal như đỉnh núi, còn các Sprint Goal là những chặng nghỉ trên đường leo. Mỗi Sprint, đội leo thêm một chặng. Khi tất cả các chặng cộng lại, đội tới đỉnh. Nếu Sprint Goal không hướng về Product Goal, thì đội đang leo một ngọn núi khác — bận rộn nhưng lạc đường.
Mối quan hệ giữa Sprint Goal và Product Goal
Mối quan hệ này có ba tầng ý nghĩa:
1. Tính định hướng (alignment). Sprint Goal phải đóng góp một phần cụ thể vào Product Goal. PO chịu trách nhiệm đảm bảo sự liên kết này — đây chính là một phần của việc "maximizing value".
2. Tính tiệm tiến (incremental progress). Product Goal quá lớn để hoàn thành trong một Sprint. Vì vậy nó được chia thành chuỗi Sprint Goal nhỏ hơn, mỗi cái tạo ra một Increment có giá trị, dùng được, và tiến gần hơn tới đích.
3. Tính kiểm chứng theo kinh nghiệm (empiricism). Sau mỗi Sprint, đội thanh tra (inspect) xem Sprint Goal có giúp tiến gần Product Goal không, rồi điều chỉnh (adapt) các Sprint Goal tiếp theo. Product Goal là điểm tham chiếu để đo lường tiến độ thực sự, không phải số task đã đóng.
Một cách diễn đạt ngắn gọn để nhớ cho kỳ thi: Product Goal cho biết "đi đâu", Sprint Goal cho biết "Sprint này đi được tới đâu".
Tình huống thực tế
Ví dụ 1: Tiki và Product Goal "tăng tỉ lệ thanh toán thành công"
Giả sử đội sản phẩm Checkout của một sàn thương mại điện tử lớn như Tiki đặt Product Goal: "Nâng tỉ lệ thanh toán thành công (checkout success rate) từ 72% lên 85% trong vòng 4 tháng, để giảm tỉ lệ bỏ giỏ hàng."
Product Goal này quá lớn cho một Sprint hai tuần. PO chia nó thành chuỗi Sprint Goal:
- Sprint 1 — Sprint Goal: "Cho phép khách hàng thanh toán mà không cần đăng nhập (guest checkout), để giảm rào cản ở bước cuối."
- Sprint 2 — Sprint Goal: "Tích hợp ví MoMo và ZaloPay vào luồng thanh toán, để khách có thêm lựa chọn quen thuộc."
- Sprint 3 — Sprint Goal: "Giảm thời gian tải trang xác nhận đơn xuống dưới 2 giây trên 3G, để khách ở tỉnh không bị rớt giao dịch."
Bài học rút ra: Khi Sprint Goal được viết như một mục đích, Developers có tự do điều chỉnh scope. Ví dụ ở Sprint 2, nếu tích hợp ZaloPay phức tạp hơn dự kiến, đội có thể quyết định chỉ ship MoMo trong Sprint này mà vẫn đạt Sprint Goal "cho khách thêm lựa chọn ví quen thuộc" — vì MoMo đã đủ chứng minh giá trị. Flexibility nằm ở scope, còn Sprint Goal vẫn nguyên vẹn.
Ví dụ 2: Một startup fintech tại TP.HCM mất phương hướng vì thiếu Sprint Goal
Một startup fintech khoảng 20 người ở Quận 1 từng gặp vấn đề điển hình. Họ chạy Scrum, có Sprint Backlog đầy đủ, nhưng mỗi Sprint Planning chỉ làm đúng một việc: kéo 12–15 PBI từ đầu Product Backlog vào Sprint. Họ không viết Sprint Goal — hoặc viết kiểu chiếu lệ: "Hoàn thành các item trong Sprint."
Hệ quả: Daily Scrum biến thành buổi báo cáo trạng thái cá nhân ("hôm qua tôi làm task A, hôm nay làm task B"). Khi một PBI gặp khó, không ai biết nó có thực sự quan trọng không, vì chẳng có mục tiêu chung để soi vào. Developers làm việc song song mà không thực sự cùng nhau. Sau Sprint, Sprint Review chỉ là demo lẻ tẻ vài tính năng rời rạc, stakeholder gật gù rồi quên ngay.
PO mới về đã thay đổi một điều duy nhất: trước mỗi Sprint Planning, anh chuẩn bị một đề xuất Sprint Goal gắn với Product Goal hiện tại ("đưa sản phẩm đạt chuẩn để xin giấy phép trung gian thanh toán"). Sprint Goal đầu tiên trở thành: "Hoàn tất luồng KYC định danh khách hàng đạt chuẩn để qua được vòng thẩm định của đối tác ngân hàng."
Diễn giải: Ngay lập tức, các cuộc trò chuyện thay đổi. Daily Scrum chuyển từ "tôi làm gì" sang "chúng ta có còn đúng hướng tới Sprint Goal không". Khi một task KYC bị chậm, cả đội xúm vào vì họ hiểu nó đe dọa Sprint Goal. Những PBI không phục vụ Goal bị đẩy ra ngoài Sprint mà không ai tiếc.
Bài học rút ra: Sprint Goal không phải thủ tục hành chính. Nó là công cụ tạo focus và coherence. Một đội không có Sprint Goal đúng nghĩa thì chỉ đang "làm Scrum trên giấy".
Ví dụ 3: Khi Sprint Goal và Product Goal lệch nhau
Một đội phát triển app giao đồ ăn (tạm gọi là FoodFast, bối cảnh Đông Nam Á) có Product Goal: "Đạt thời gian giao trung bình dưới 25 phút tại nội thành để cạnh tranh với đối thủ."
Nhưng trong một Sprint, do sếp marketing gây áp lực, PO chốt Sprint Goal: "Ra mắt tính năng chia sẻ món ăn lên mạng xã hội để tăng nhận diện thương hiệu."
Tính năng social-share có thể hữu ích, nhưng nó không đóng góp gì cho Product Goal về tốc độ giao hàng. Sprint kết thúc, đội ship được tính năng, nhưng thời gian giao vẫn 32 phút. Họ đã tiêu một Sprint mà không tiến gần đích đến đã cam kết.
Diễn giải: Đây là một anti-pattern kinh điển: Sprint Goal bị "lái" bởi áp lực bên ngoài thay vì bám vào Product Goal. Nếu social-share thực sự quan trọng đến mức đáng đánh đổi, thì điều cần làm là xem xét lại Product Goal một cách minh bạch — chứ không phải lén lút nhét một Sprint Goal lạc hướng.
Bài học rút ra: PO phải là người gác cổng alignment. Mỗi khi đề xuất Sprint Goal, hãy tự hỏi: "Sprint Goal này đưa chúng ta gần hơn bao nhiêu tới Product Goal?" Nếu câu trả lời là "không", thì hoặc Sprint Goal sai, hoặc Product Goal cần được xem lại — nhưng không bao giờ được phép âm thầm để hai cái lệch nhau.
Hướng dẫn từng bước
Dưới đây là quy trình thực hành để tạo một Sprint Goal tốt, gắn chặt với Product Goal:
Bước 1 — Bắt đầu từ Product Goal. Trước Sprint Planning, mở Product Goal hiện tại ra và tự hỏi: "Chúng ta còn cách đích bao xa? Bước hợp lý tiếp theo là gì?" Mọi Sprint Goal phải bắt nguồn từ câu hỏi này.
Bước 2 — Nhìn vào đầu Product Backlog đã được sắp xếp. Các PBI ở trên cùng (đã được ordered và refined) thường gợi ý chủ đề cho Sprint Goal. Tìm một chủ đề chung xuyên suốt vài PBI quan trọng nhất, thay vì chọn ngẫu nhiên.
Bước 3 — Soạn một đề xuất Sprint Goal dưới dạng "mục đích". Viết theo công thức: "[Đạt được điều gì] để [tạo ra giá trị / kết quả gì]." Ví dụ: "Cho phép thanh toán bằng ví điện tử để khách hàng có thêm lựa chọn quen thuộc." Tránh viết kiểu liệt kê task.
Bước 4 — Thương lượng với Developers tại Sprint Planning. Trình bày đề xuất Sprint Goal, để Developers đánh giá tính khả thi. Họ sẽ chọn các PBI cần thiết và dự báo (forecast) khối lượng. Sprint Goal có thể được tinh chỉnh cho vừa với năng lực thực tế.
Bước 5 — Kiểm tra tiêu chí một Sprint Goal tốt. Trước khi chốt, đối chiếu: Có đúng một Goal không? Nó có hướng về outcome/giá trị, không phải liệt kê output? Nó có gắn với Product Goal không? Nó có đủ rộng để cho phép Developers linh hoạt về scope không? Nó có đo lường được "thành công" không?
Bước 6 — Dùng Sprint Goal làm la bàn suốt Sprint. Ở Daily Scrum, đội kiểm tra tiến độ so với Sprint Goal, không phải so với số task. Nếu giữa Sprint phát hiện scope cần đổi, thương lượng lại PBI — nhưng giữ Sprint Goal cố định.
Bước 7 — Đánh giá tại Sprint Review. Hỏi: "Chúng ta có đạt Sprint Goal không? Nó đã đẩy Product Goal tiến bao xa?" Câu trả lời định hình Sprint Goal kế tiếp. Đây chính là vòng inspect-and-adapt theo empiricism.
Lỗi thường gặp & mẹo
Lỗi 1: Coi Sprint Goal là danh sách PBI. Đây là lỗi số một. "Sprint Goal của chúng ta là hoàn thành 10 user story" — sai. Sprint Goal là một mục đích, các PBI chỉ là phương tiện. Mẹo: nếu Sprint Goal của bạn có thể viết lại thành một câu duy nhất bắt đầu bằng "Để..." thì bạn đang đi đúng hướng.
Lỗi 2: Tạo nhiều Sprint Goal. Một Sprint có nhiều Sprint Goal là dấu hiệu thiếu focus. Nếu thực sự có hai mục tiêu không liên quan, hãy hỏi: cái nào quan trọng hơn cho Product Goal? Chọn một, đẩy cái kia sang Sprint sau.
Lỗi 3: Sprint Goal không liên quan tới Product Goal. Như ví dụ FoodFast — Sprint bận rộn mà không tiến về đích. Mẹo: mỗi Sprint Goal phải vượt qua "bài kiểm tra alignment" — nó đóng góp gì cụ thể cho Product Goal?
Lỗi 4: Nghĩ Sprint Goal là bất biến về scope. Nhiều người hiểu nhầm rằng "cam kết Sprint Goal" nghĩa là không được đổi gì. Ngược lại: scope linh hoạt, Goal cố định. Developers có thể thương lượng lại PBI với PO miễn không làm hỏng Sprint Goal.
Lỗi 5: PO áp đặt Sprint Goal một mình. Sprint Goal là kết quả hợp tác của cả Scrum Team tại Sprint Planning. PO định hướng giá trị, nhưng không độc đoán.
Lỗi 6: Bỏ qua Sprint Goal khi đề thi PSPO I hỏi. Trong đề thi, nếu một phương án nói "Sprint không nhất thiết cần Sprint Goal" hoặc "mỗi Sprint có thể có nhiều Sprint Goal" — gần như chắc chắn đó là đáp án sai. Hãy nhớ: một Sprint, một Sprint Goal, và nó là commitment.
Mẹo ghi nhớ cho kỳ thi: Liên kết ba commitment với ba artifact. Khi đề hỏi "commitment của Sprint Backlog là gì?", trả lời ngay: Sprint Goal. Khi hỏi "Sprint Goal được tạo khi nào?", trả lời: tại Sprint Planning, bởi cả Scrum Team.
Bài tập thực hành
Bài 1 — Phân biệt đúng/sai. Đọc các Sprint Goal sau và đánh giá cái nào là Sprint Goal tốt, cái nào chỉ là danh sách task trá hình:
a) "Hoàn thành các story PROJ-101, PROJ-102, PROJ-103." b) "Cho phép người dùng đăng nhập bằng số điện thoại để giảm rào cản tạo tài khoản." c) "Làm xong tính năng tìm kiếm, sửa 5 bug, và cập nhật tài liệu." d) "Rút ngắn quy trình hoàn tiền xuống dưới 24 giờ để tăng độ tin cậy của khách hàng."
(Gợi ý đáp án: b và d là Sprint Goal tốt; a và c chỉ là tổng hợp công việc.)
Bài 2 — Chuỗi alignment. Chọn một sản phẩm bạn quen thuộc (app ngân hàng, sàn TMĐT, công cụ nội bộ công ty bạn). Viết ra:
- Một Product Goal (dài hạn, có con số nếu được).
- Ba Sprint Goal liên tiếp, mỗi cái là một bước đệm tiến về Product Goal đó.
Bài 3 — Sửa Sprint Goal lệch hướng. Cho Product Goal: "Giảm tỉ lệ khách rời bỏ (churn) hàng tháng từ 8% xuống 5%." Một đội đề xuất Sprint Goal: "Đổi toàn bộ màu sắc giao diện sang bộ nhận diện thương hiệu mới." Hãy chỉ ra vì sao Sprint Goal này có vấn đề, và viết lại một Sprint Goal phù hợp hơn với Product Goal.
Bài 4 — Tình huống thương lượng scope. Sprint Goal của đội là: "Cho phép khách đặt lịch hẹn trực tuyến để giảm tải tổng đài." Giữa Sprint, Developers nhận ra tính năng gửi email xác nhận tự động phức tạp hơn dự kiến. Theo bạn, đội nên làm gì? Họ có được phép bỏ tính năng email mà vẫn đạt Sprint Goal không? Hãy lập luận dựa trên đặc tính "flexibility" của Sprint Goal.
Tóm tắt
- Sprint Goal là commitment của Sprint Backlog — mục tiêu duy nhất mà cả Sprint hướng tới. Đây là một trong ba commitment của Scrum (cùng với Product Goal cho Product Backlog và Definition of Done cho Increment).
- Mỗi Sprint có đúng một Sprint Goal. Nó tạo coherence (gắn kết) khiến Developers làm việc cùng nhau, và tạo flexibility (linh hoạt) cho phép thương lượng lại scope mà không đổi Goal.
- Sprint Goal được tạo tại Sprint Planning bởi cả Scrum Team — PO định hướng giá trị, Developers định hình tính khả thi.
- Sprint Goal không phải danh sách PBI. Nó là một mục đích, viết theo dạng "đạt được X để tạo ra giá trị Y".
- Mối quan hệ với Product Goal: Product Goal là đích đến dài hạn; mỗi Sprint Goal là một bước đệm tiến về đích đó. PO chịu trách nhiệm đảm bảo mọi Sprint Goal đều aligned với Product Goal — đây là cốt lõi của việc tối đa hóa giá trị.
- Empiricism: Sau mỗi Sprint, đội inspect tiến độ so với Product Goal và adapt các Sprint Goal kế tiếp.
- Mẹo thi PSPO I: Một Sprint, một Sprint Goal; nó là commitment; tạo tại Sprint Planning; scope linh hoạt nhưng Goal cố định. Cảnh giác với các phương án nói Sprint Goal là tùy chọn hoặc có nhiều Goal mỗi Sprint.