Mở đầu — vì sao bài này quan trọng
Hãy thử một bài kiểm tra nhỏ. Bạn bước vào phòng team Sprint Planning, hỏi từng người: "Sprint này chúng ta đang cố đạt được điều gì?" Nếu câu trả lời của năm người là năm phiên bản khác nhau — người nói "làm xong mười cái ticket", người nói "ra mắt tính năng thanh toán", người nói "không biết, tôi chỉ làm task được giao" — thì team của bạn đang không có Sprint Goal thực sự. Họ có một danh sách công việc, và họ đang nhầm nó với một mục tiêu.
Đây là một trong những căn bệnh âm thầm nhất của các team Scrum. Theo Scrum Guide 2020, Sprint Goal là một trong ba cam kết (commitments) bắt buộc, đứng ngang hàng với Product Goal và Definition of Done. Nó là "lý do tại sao" của cả Sprint. Vậy mà trong thực tế, rất nhiều team viết Sprint Goal như một việc làm cho có — một dòng chữ điền vội vào ô trống của Jira sau khi đã chọn xong backlog items, kiểu "Hoàn thành các item trong Sprint 23". Đó không phải mục tiêu. Đó là mô tả lại danh sách công việc bằng một câu.
Sprint Goal Workshop là một buổi làm việc có chủ đích, được facilitate cẩn thận, để team cùng nhau đúc ra một Sprint Goal thực sự có sức nặng — một mục tiêu mạch lạc (coherent), hướng kết quả (outcome) chứ không hướng sản lượng (output), và đủ rõ để định hướng mọi quyết định trong Sprint. Là Scrum Master, đây là một trong những công cụ facilitation tạo ra đòn bẩy lớn nhất mà bạn có. Một Sprint Goal tốt biến một nhóm người làm task rời rạc thành một team có chung một trận đánh. Bài này sẽ chỉ cho bạn cách thiết kế và dẫn dắt buổi workshop đó.
Khái niệm cốt lõi
Sprint Goal là gì — và không là gì
Sprint Goal là một mục tiêu duy nhất, được diễn đạt cô đọng, mô tả giá trị mà team cam kết tạo ra trong Sprint. Nó trả lời câu hỏi: "Nếu Sprint này thành công, thế giới sẽ khác đi như thế nào?"
Hãy phân biệt rõ ba khái niệm thường bị nhập nhằng:
- Sprint Backlog là cái (the what): danh sách các Product Backlog Item và task team sẽ làm.
- Sprint Goal là tại sao (the why): lý do team chọn những item đó, giá trị chúng cùng hướng tới.
- Definition of Done là chất lượng (the how-good): tiêu chuẩn để một item được coi là hoàn thành.
Hai nguyên tắc làm nên một workshop tốt
Nguyên tắc 1 — Coherence (sự mạch lạc) quan trọng hơn checklist. Một Sprint Goal tốt khiến các item trong backlog "dính" vào nhau bằng một sợi chỉ chung. Khi Product Owner mang vào mười item rời rạc — ba cái về thanh toán, hai cái về thông báo, năm cái vá lỗi linh tinh — buổi workshop chính là nơi đặt câu hỏi: "Trong tất cả những thứ này, đâu là một kết quả mà chúng ta thực sự muốn đạt được Sprint này?" Câu hỏi đó ép team chọn lựa và sắp xếp, thay vì gom hết vào một cái rổ.
Nguyên tắc 2 — Outcome (kết quả) quan trọng hơn output (sản lượng). Output là thứ team sản xuất ra: số dòng code, số màn hình, số ticket đóng. Outcome là sự thay đổi mà output đó tạo ra cho người dùng hoặc cho doanh nghiệp. So sánh:
- Output-driven: "Xây dựng API đăng nhập bằng Google."
- Outcome-driven: "Giúp người dùng mới hoàn tất đăng ký trong dưới 30 giây, để giảm tỷ lệ bỏ cuộc ở bước tạo tài khoản."
Cấu trúc "Wh" của một Sprint Goal
Ghi chú gốc của bài này nhắc đến "Wh", và đây là khung rất hữu ích để dẫn workshop. Một Sprint Goal mạch lạc thường trả lời được ba câu hỏi Wh:
- Why — Tại sao Sprint này quan trọng? Giá trị kinh doanh hoặc giá trị cho người dùng là gì?
- What — Kết quả cụ thể nào chứng tỏ ta đã đạt Goal? (Không phải liệt kê task, mà là trạng thái mong muốn.)
- Who — Ai được hưởng lợi? Người dùng cuối, bộ phận vận hành, hay chính team?
> "Sprint này, chúng ta giúp [Who] có thể [What/kết quả], nhằm [Why/giá trị]."
Ví dụ: "Sprint này, chúng ta giúp khách hàng mua hàng lần đầu có thể thanh toán qua ví MoMo mà không cần rời ứng dụng, nhằm giảm tỷ lệ rớt đơn ở bước thanh toán."
Tình huống thực tế
Tình huống 1 — Sàn TMĐT và "danh sách giả làm mục tiêu"
Tại một công ty thương mại điện tử quy mô vừa ở TP.HCM (tạm gọi ShopViet), team Checkout gồm sáu kỹ sư trước đây luôn viết Sprint Goal theo kiểu: "Hoàn thành 8 story trong Sprint." Mỗi cuối Sprint, Sprint Review trở thành buổi đọc lại từng ticket, và khi có một story bị chậm, cả team coi như "trượt Sprint", tinh thần đi xuống.
Scrum Master mới về tổ chức một Sprint Goal Workshop 45 phút trước buổi Planning. Cô bắt đầu bằng việc xếp tám story candidate lên bảng, rồi hỏi: "Nếu sếp chỉ cho chúng ta ba ngày thay vì hai tuần, thì một thứ duy nhất chúng ta phải bảo vệ là gì?" Sau mười phút tranh luận, team nhận ra năm trong tám story đều xoay quanh việc khách hàng bỏ giỏ hàng ở bước nhập địa chỉ. Goal được viết lại: "Giảm số bước nhập địa chỉ giao hàng từ 5 xuống 2, để khách hoàn tất đặt hàng nhanh hơn."
Kết quả: ba story còn lại (vá lỗi giao diện admin) được PO đồng ý đẩy sang Sprint sau vì không phục vụ Goal. Sprint trở nên tập trung hơn hẳn. Quan trọng hơn, khi giữa Sprint phát sinh một bug ảnh hưởng tới luồng địa chỉ, team không do dự ưu tiên xử lý vì nó nằm thẳng trên đường tới Goal.
Bài học: Khi Goal hướng kết quả, danh sách backlog tự nhiên được lọc và sắp xếp. Goal trở thành la bàn ra quyết định giữa Sprint, không chỉ là một dòng chữ trang trí.
Tình huống 2 — Fintech và cái bẫy "nhồi hai mục tiêu vào một"
Một startup fintech ở Singapore phục vụ thị trường Đông Nam Á có team Payments gặp vấn đề ngược lại: họ đã biết viết Goal hướng outcome, nhưng mỗi Sprint lại nhét hai, ba mục tiêu lớn vào cùng một câu nối bằng chữ "và". Ví dụ: "Ra mắt thanh toán định kỳ và nâng cấp hệ thống chống gian lận và dọn nợ kỹ thuật ở module ví."
Hậu quả là không có Goal nào thực sự dẫn dắt được. Khi áp lực dồn đến cuối Sprint, mỗi kỹ sư tự chọn ưu tiên theo ý mình, và cả ba mục tiêu đều dở dang.
Trong Sprint Goal Workshop, Scrum Master áp dụng kỹ thuật "dot voting": mỗi thành viên có hai điểm để dán vào mục tiêu mình tin là tạo giá trị lớn nhất Sprint này. "Thanh toán định kỳ" thắng áp đảo. Team đồng thuận đặt nó làm Goal duy nhất, còn hai việc kia được phân loại lại: chống gian lận trở thành một item trong backlog phục vụ Goal (vì thanh toán định kỳ cần kiểm soát rủi ro), và dọn nợ kỹ thuật được tách hẳn ra, thương lượng đưa vào Sprint sau.
Bài học: Một Sprint, một Goal. Chữ "và" trong Sprint Goal là tín hiệu cảnh báo. Nếu bạn phải nối hai kết quả bằng "và", nhiều khả năng bạn đang có hai Sprint Goal đội lốt một, và team sẽ bị xé lực.
Tình huống 3 — Agency phần mềm và Sprint "không có gì để mục tiêu hóa"
Một agency phần mềm ở Đà Nẵng nhận lý lẽ phản đối quen thuộc từ team: "Sprint của bọn em toàn việc lặt vặt từ nhiều khách hàng khác nhau, làm gì có mục tiêu chung mà đặt." Đây là tình huống thật mà nhiều team outsourcing gặp phải.
Scrum Master không ép một Goal giả tạo. Thay vào đó, trong workshop, anh đặt lại câu hỏi ở tầng cao hơn: "Nếu không có mục tiêu về tính năng, thì có mục tiêu nào về cách chúng ta làm việc không?" Team phát hiện họ đang khổ sở vì thời gian build và deploy quá lâu, ảnh hưởng tới mọi khách hàng. Sprint Goal được đặt là: "Rút thời gian từ commit đến deploy staging từ 25 phút xuống dưới 8 phút, để mọi luồng công việc trong Sprint chạy mượt hơn." Các task lặt vặt vẫn được làm, nhưng giờ có một sợi chỉ đỏ — cải thiện pipeline — để cả team cùng hướng tới.
Bài học: Khi không có Goal hướng tính năng, hãy tìm Goal hướng năng lực (capability) hoặc hướng cách làm việc. Một Sprint hoàn toàn không có Goal là dấu hiệu cần xem lại cách lập kế hoạch sản phẩm, chứ hiếm khi là điều bất khả kháng.
Hướng dẫn từng bước
Dưới đây là kịch bản một Sprint Goal Workshop kéo dài 30–45 phút, thường đặt ngay đầu Sprint Planning hoặc cuối buổi refinement trước đó.
Bước 0 — Chuẩn bị (trước buổi, 10 phút). Scrum Master phối hợp với Product Owner để PO mang vào bối cảnh: tình hình sản phẩm, phản hồi từ Sprint Review vừa rồi, ưu tiên kinh doanh hiện tại. PO không cần mang sẵn Goal — đó là việc của cả team — nhưng phải mang đủ thông tin để team có thể suy luận.
Bước 1 — Mở bằng "vì sao" (5 phút). PO trình bày ngắn gọn bức tranh lớn: chúng ta đang ở đâu trong Product Goal, điều gì là cấp thiết nhất lúc này. Mục tiêu của bước này là nạp đủ ngữ cảnh để cả team cùng đứng trên một nền nhận thức.
Bước 2 — Phân kỳ: thu thập ứng viên Goal (10 phút). Cho mỗi người viết im lặng (silent writing) lên sticky note câu trả lời cho câu hỏi: "Nếu Sprint này chỉ được phép thành công ở một điều, điều đó nên là gì?" Viết im lặng tránh việc người nói to lấn át, và thường lộ ra những góc nhìn bất ngờ từ các kỹ sư ít phát biểu.
Bước 3 — Gom nhóm và bàn luận (10 phút). Dán tất cả note lên bảng, gom các ý tương tự, đặt tên cụm. Thường sẽ có hai đến ba cụm nổi lên. Dùng dot voting nếu cần thu hẹp.
Bước 4 — Đúc câu (5–10 phút). Lấy cụm thắng cuộc và đổ vào mẫu câu Why–What–Who. Cùng nhau mài giũa câu chữ cho tới khi nó cô đọng, hướng kết quả, và không có chữ "và" nối hai mục tiêu. Viết Goal lên nơi ai cũng thấy.
Bước 5 — Kiểm tra ngược với backlog (5 phút). Với Goal vừa đặt, rà lại các candidate item: "Item này có giúp đạt Goal không? Nếu bỏ, Goal có còn đạt được không?" Bước này gắn Goal vào Sprint Backlog và thường giúp lọc bớt item thừa.
Bước 6 — Bài kiểm tra "thước đo". Hỏi cả team: "Cuối Sprint, làm sao chúng ta biết đã đạt Goal?" Nếu không ai trả lời được bằng một dấu hiệu quan sát được, Goal vẫn còn mơ hồ — quay lại Bước 4 để làm rõ.
Lỗi thường gặp & mẹo
Lỗi 1 — Coi Sprint Goal là phần phụ làm sau khi đã chọn backlog. Đây là lỗi phổ biến nhất. Khi Goal được nặn ra sau khi chốt danh sách công việc, nó chỉ là bản tóm tắt của danh sách đó. Mẹo: đặt phần thảo luận Goal lên trước hoặc song song với việc chọn item, để Goal dẫn dắt việc chọn item chứ không ngược lại.
Lỗi 2 — Goal là mô tả output. Dấu hiệu nhận biết: Goal bắt đầu bằng động từ kỹ thuật như "Xây dựng", "Tích hợp", "Refactor". Mẹo: thêm vế "để..." vào cuối. Nếu vế "để" nghe hiển nhiên hoặc không viết nổi, Goal của bạn đang là output. "Tích hợp cổng VNPAY" trở thành "...để khách hàng có thêm lựa chọn thanh toán nội địa, giảm phụ thuộc vào thẻ quốc tế."
Lỗi 3 — Goal chứa chữ "và" nối nhiều mục tiêu. Như tình huống fintech ở trên. Mẹo: ép team chọn một. Nếu thật sự có hai việc tách biệt, đó là tín hiệu Sprint đang gánh quá nhiều, hãy nói chuyện với PO.
Lỗi 4 — Goal quá mơ hồ, không thể kiểm chứng. "Cải thiện trải nghiệm người dùng" là khẩu hiệu, không phải Sprint Goal. Mẹo: dùng bài kiểm tra thước đo ở Bước 6 — luôn hỏi "làm sao biết đã đạt?".
Lỗi 5 — Scrum Master tự viết Goal thay cho team. Goal do một người áp đặt sẽ không tạo cam kết. Mẹo: vai trò của bạn là facilitate quá trình đúc Goal, không phải đọc Goal có sẵn. Hãy dùng câu hỏi, không dùng câu trả lời.
Mẹo bổ sung — giữ Goal sống suốt Sprint. Một Sprint Goal viết xong rồi quên là vô dụng. Hãy dán nó ở đầu board, nhắc lại nó ở mỗi Daily Scrum bằng câu hỏi: "Hôm nay chúng ta tiến gần Goal hơn ở điểm nào?" Goal chỉ thực sự có giá trị khi nó được dùng để ra quyết định mỗi ngày.
Bài tập thực hành
Bài tập 1 — Chẩn đoán Goal cũ. Lấy ba Sprint Goal gần nhất của team bạn (hoặc tự bịa ba cái nếu bạn chưa có team). Với mỗi cái, phân loại: nó là output hay outcome? Có chứa chữ "và" nối nhiều mục tiêu không? Có trả lời được câu "làm sao biết đã đạt?" không? Viết lại ít nhất một cái theo mẫu Why–What–Who.
Bài tập 2 — Viết lại từ một backlog hỗn độn. Cho danh sách bảy item sau, hãy đúc ra một Sprint Goal hướng outcome và xác định item nào có thể bỏ: (1) Thêm nút "Mua lại" ở lịch sử đơn hàng; (2) Sửa lỗi font ở trang giỏ hàng; (3) Hiển thị gợi ý sản phẩm tương tự ở trang giỏ hàng; (4) Tối ưu tốc độ tải trang giỏ hàng; (5) Cập nhật thư viện logging; (6) Thêm thanh tiến trình thanh toán; (7) Đổi màu nút admin. Gợi ý: bốn trong bảy item xoay quanh một chủ đề — hãy tìm sợi chỉ đỏ đó.
Bài tập 3 — Dẫn thử một mini-workshop. Trong Sprint Planning kế tiếp, hãy chạy đúng Bước 2 và Bước 3 (viết im lặng + gom nhóm) trong 15 phút. Quan sát: có góc nhìn nào bất ngờ lộ ra không? Team có hội tụ nhanh hơn so với cách thảo luận tự do thông thường không? Ghi lại ba điều bạn học được để cải tiến buổi sau.
Tóm tắt
Sprint Goal Workshop là buổi facilitation biến một mục tiêu-cho-có thành một mục tiêu thực sự dẫn dắt Sprint. Hãy nhớ ba điều cốt lõi. Thứ nhất, mạch lạc hơn danh sách: Goal là sợi chỉ đỏ buộc các backlog item lại với nhau, không phải bản tóm tắt của chúng. Thứ hai, kết quả hơn sản lượng: luôn thêm vế "để..." và hỏi "ai được lợi", để Goal mô tả sự thay đổi cho người dùng chứ không phải thứ team sản xuất. Thứ ba, một Sprint, một Goal: cảnh giác với chữ "và", và luôn kiểm chứng bằng câu hỏi "làm sao biết đã đạt?".
Vai trò của bạn — Scrum Master — không phải là người viết Goal, mà là người thiết kế không gian để team cùng đúc ra Goal: mở bằng "vì sao", phân kỳ bằng viết im lặng, hội tụ bằng dot voting, đúc câu bằng mẫu Why–What–Who, rồi gắn nó vào backlog. Và quan trọng nhất, hãy giữ Goal sống suốt Sprint — nhắc nó mỗi ngày, dùng nó để ra quyết định. Một Sprint Goal tốt không nằm trong Jira. Nó nằm trong đầu mọi người khi họ chọn việc để làm hôm nay.