Mở đầu — vì sao bài này quan trọng
Hãy thử tưởng tượng bạn là thuyền trưởng dẫn cả đội chèo thuyền vượt biển trong hai tuần. Nếu bạn chỉ ra lệnh "mỗi người cứ chèo hết sức nhé", thì sau hai tuần con thuyền có thể đi rất nhanh — nhưng đi vòng vòng, hoặc tệ hơn là trôi ngược ra khơi. Sprint Goal (Mục tiêu Sprint) chính là ngọn hải đăng để cả thuyền biết mình đang chèo về đâu, và quan trọng hơn là biết vì sao phải chèo về đó.
Trong các bài trước, bạn đã học Sprint Goal là gì (Bài 10), mối quan hệ của nó với Product Goal, và vai trò của nó trong Sprint Planning (Bài 17). Bài này không nhắc lại định nghĩa — bài này tập trung vào một thứ rất thực dụng mà kỳ thi PSPO I lẫn công việc thật đều đòi hỏi: làm thế nào để viết ra một Sprint Goal thật sự tốt. Đây là kỹ năng craft — kỹ năng "đẽo gọt câu chữ" — mà nhiều Product Owner xem nhẹ, để rồi mỗi Sprint trở thành một danh sách công việc rời rạc thay vì một mục tiêu chung có ý nghĩa.
Tại sao điều này đáng để bạn dành cả một bài học? Bởi vì Scrum Guide 2020 đã nâng Sprint Goal lên thành một trong ba commitment (cam kết) của Scrum, ngang hàng với Product Goal và Definition of Done. Một Sprint Goal được craft tốt sẽ giúp Scrum Team tập trung, tạo sự linh hoạt trong cách thực hiện, và là cơ sở để Product Owner đàm phán phạm vi với stakeholder mà không phá vỡ Sprint. Ngược lại, một Sprint Goal viết dở — hoặc không có — là dấu hiệu kinh điển của một đội Scrum "giả vờ Agile".
Khái niệm cốt lõi
Sprint Goal là một mục tiêu duy nhất cho Sprint. Nó trả lời câu hỏi: "Vì sao Sprint này đáng để chúng ta thực hiện?" Nhưng nói "một mục tiêu duy nhất" thì dễ, viết cho ra hồn mới khó. Một Sprint Goal được craft tốt thường hội tụ ba đặc tính dưới đây.
Specific — cụ thể, một hướng đi rõ ràng
Sprint Goal phải đủ cụ thể để mọi thành viên hiểu giống nhau khi đọc nó. "Cải thiện sản phẩm" không phải Sprint Goal — nó mơ hồ đến mức ai muốn hiểu sao cũng được. "Cho phép khách hàng thanh toán đơn hàng bằng ví MoMo" thì cụ thể hơn nhiều: ai đọc cũng biết Sprint này xoay quanh điều gì.
Tuy nhiên — và đây là điểm tinh tế — cụ thể không có nghĩa là liệt kê từng task. Sprint Goal không phải là "làm xong 12 user story trong backlog". Nó cụ thể về kết quả mong muốn, nhưng để mở về cách đạt được. Sự để mở này chính là không gian để Developers tự quản (self-managing), điều chỉnh khi gặp khó khăn kỹ thuật mà vẫn giữ được mục tiêu.
Outcome-oriented — hướng đến kết quả, không phải đầu việc
Đây là đặc tính phân biệt một PO non tay với một PO trưởng thành. Sprint Goal tốt mô tả một sự thay đổi mà người dùng hoặc doanh nghiệp sẽ cảm nhận được, chứ không phải một đống đầu ra (output).
So sánh hai cách viết cho cùng một Sprint:
- Kiểu output: "Hoàn thành màn hình đăng nhập, API xác thực, và tích hợp OTP."
- Kiểu outcome: "Người dùng mới có thể tự đăng ký và đăng nhập an toàn mà không cần hỗ trợ từ bộ phận chăm sóc khách hàng."
(Tư duy outcome-over-output này được đào sâu ở Bài 31; ở đây ta chỉ áp dụng nó vào riêng việc viết Sprint Goal.)
Single sentence — một câu, dễ nhớ, dễ nhắc lại
Một Sprint Goal tốt nên gói gọn trong một câu mà bất kỳ thành viên nào cũng đọc thuộc. Lý do rất thực tế: trong Daily Scrum, Developers phải dùng Sprint Goal làm thước đo để kiểm tra tiến độ. Nếu mục tiêu dài ba đoạn văn, không ai nhớ nổi, và nó sẽ chết yểu trong tài liệu.
Quy tắc kiểm chứng đơn giản: nếu bạn không thể đọc Sprint Goal cho một đồng nghiệp nghe trong vòng 10 giây và họ gật đầu hiểu ngay, thì nó chưa đủ gọn.
Một mẫu câu hữu ích
Để craft nhanh, bạn có thể dùng khung: "Để [đối tượng] có thể [làm được điều gì / nhận giá trị gì], nhằm [lý do kinh doanh]."
Ví dụ: "Để khách hàng đặt phòng có thể hủy đơn online trong vòng 1 phút, nhằm giảm 30% lượng cuộc gọi hủy phòng vào tổng đài."
Khung này tự nhiên ép bạn nêu đối tượng, kết quả và lý do — đúng ba thứ làm nên một Sprint Goal tốt.
Tình huống thực tế
Ví dụ 1 — Tiki và Sprint Goal "danh sách task trá hình"
Một đội phát triển tính năng giỏ hàng tại một sàn thương mại điện tử lớn (giả định lấy bối cảnh kiểu Tiki) bước vào Sprint Planning. Product Owner viết Sprint Goal như sau: "Hoàn thành 8 story về giỏ hàng: thêm sản phẩm, xóa sản phẩm, cập nhật số lượng, áp mã giảm giá, tính phí ship, lưu giỏ hàng, đồng bộ giỏ hàng đa thiết bị, và refactor module thanh toán."
Đến giữa Sprint, một story (đồng bộ đa thiết bị) hóa ra phức tạp hơn dự tính rất nhiều vì hệ thống cache cũ. Developers hỏi: "Có nên bỏ story này không?" Nhưng vì Sprint Goal chính là danh sách 8 story, bỏ bất kỳ story nào cũng có nghĩa là "không đạt Sprint Goal". Cả đội rơi vào thế tiến thoái lưỡng nan, cố nhồi nhét cho đủ 8 món, làm ẩu, và cuối Sprint Review không có gì dùng được trọn vẹn.
Bài học rút ra: khi Sprint Goal chỉ là danh sách task, đội mất hoàn toàn khả năng linh hoạt. Lẽ ra PO nên viết: "Khách hàng có thể quản lý giỏ hàng của mình trên một thiết bị một cách trơn tru và áp được khuyến mãi." Với mục tiêu này, story đồng bộ đa thiết bị có thể được hoãn sang Sprint sau mà Sprint Goal vẫn đạt — vì giá trị cốt lõi (quản lý giỏ hàng + khuyến mãi) đã được giao.
Ví dụ 2 — Startup fintech và Sprint Goal hướng outcome
Một startup ví điện tử ở TP.HCM (gọi là PayViet, giả định) có chỉ số đáng lo: tỷ lệ người dùng bỏ cuộc ở bước xác minh danh tính (eKYC) lên tới 45%. Thay vì viết Sprint Goal kiểu "tích hợp SDK nhận diện khuôn mặt và OCR giấy tờ", PO craft theo hướng outcome:
"Người dùng mới hoàn tất xác minh danh tính ngay trong lần đầu mà không bỏ cuộc, hướng tới giảm tỷ lệ rớt eKYC từ 45% xuống dưới 30%."
Sự khác biệt thể hiện rõ ngay trong Sprint. Khi Developers thử nghiệm và phát hiện SDK nhận diện khuôn mặt làm chậm máy đời cũ, họ không bị mắc kẹt vào việc "phải tích hợp SDK đó". Họ trao đổi với PO và chuyển sang một luồng nhẹ hơn cho máy yếu. Vì mục tiêu là giảm tỷ lệ rớt, chứ không phải tích hợp một SDK cụ thể, đội có toàn quyền chọn giải pháp tốt nhất. Cuối Sprint, tỷ lệ rớt giảm còn 28% — vượt mục tiêu — dù cách làm khác hẳn kế hoạch ban đầu.
Bài học rút ra: Sprint Goal hướng outcome biến Developers từ "người thực thi yêu cầu" thành "người giải quyết vấn đề". Nó cũng cho PO một thước đo thật để báo cáo với ban lãnh đạo: không phải "chúng tôi đã code xong", mà "chúng tôi đã giảm được tỷ lệ rớt".
Ví dụ 3 — Đội nội bộ ngân hàng và Sprint Goal đa mục tiêu
Một đội làm hệ thống nội bộ tại một ngân hàng ở Hà Nội thường xuyên có Sprint Goal dạng: "Nâng cấp bảo mật module A, đồng thời ra mắt báo cáo mới cho phòng kế toán, và sửa 15 bug tồn đọng." Ba mục tiêu trong một câu, dùng từ "đồng thời".
Vấn đề lộ ra trong Daily Scrum: khi Developers hỏi "hôm nay nên ưu tiên việc nào", không ai trả lời được, vì cả ba việc đều "trong Sprint Goal". Khi một thành viên xin nghỉ ốm và năng lực đội giảm, không có cơ sở nào để quyết định hy sinh mục tiêu nào. Sprint Goal mất chức năng quan trọng nhất của nó: làm điểm tựa để ra quyết định khi mọi thứ không như kế hoạch.
Scrum Master gợi ý PO chọn một mục tiêu chính: "Phòng kế toán có thể tự tạo báo cáo cuối tháng mà không cần nhờ đội IT." Các bug và việc nâng cấp bảo mật vẫn nằm trong Sprint Backlog, nhưng không phải là Sprint Goal — chúng là việc cần làm, không phải lý do tồn tại của Sprint. Ngay lập tức, Daily Scrum có định hướng rõ ràng: việc nào cản trở báo cáo cuối tháng thì ưu tiên trước.
Bài học rút ra: "single" trong single-sentence không chỉ là vấn đề độ dài câu — nó là vấn đề một sự tập trung duy nhất. Sprint Backlog có thể chứa nhiều việc, nhưng Sprint Goal phải hội tụ về một hướng. Nhồi nhiều mục tiêu ngang hàng vào một Sprint Goal là cách chắc chắn để vô hiệu hóa nó.
Hướng dẫn từng bước
Đây là quy trình craft Sprint Goal mà bạn có thể áp dụng ngay trong Sprint Planning. Lưu ý: Sprint Goal được tạo ra trong Sprint Planning bởi cả Scrum Team, không phải PO viết sẵn rồi áp đặt — nhưng PO là người dẫn dắt và chịu trách nhiệm cuối cùng cho hướng đi này.
- Bắt đầu từ Product Goal. Trước khi viết Sprint Goal, hãy nhìn lại Product Goal hiện tại. Sprint Goal phải là một bước tiến cụ thể về phía Product Goal. Tự hỏi: "Sprint này đưa chúng ta tiến gần Product Goal ở khía cạnh nào?"
- Xác định một thay đổi giá trị nhất. Nhìn vào phần đầu Product Backlog đã được sắp xếp (ordered) và hỏi: "Nếu Sprint này chỉ giao được một điều có ý nghĩa, thì điều đó là gì?" Câu trả lời là hạt nhân của Sprint Goal.
- Viết theo hướng outcome. Diễn đạt điều đó dưới dạng kết quả/sự thay đổi cho người dùng hoặc doanh nghiệp, dùng khung "Để [ai] có thể [gì], nhằm [lý do]." Tránh động từ kỹ thuật như "tích hợp", "refactor", "deploy" trong câu mục tiêu chính.
- Rút gọn về một câu. Cắt hết tính từ thừa và liên từ "và", "đồng thời". Nếu phải dùng "và" để nối hai ý độc lập, rất có thể bạn đang có hai Sprint Goal — hãy chọn một.
- Kiểm tra với cả đội. Đọc to Sprint Goal cho Developers. Hỏi hai câu: "Mọi người hiểu giống nhau không?" và "Mục tiêu này có khả thi trong Sprint không?" Nếu Developers thấy không khả thi, điều chỉnh phạm vi của mục tiêu, đừng điều chỉnh độ dài câu.
- Kiểm tra tính linh hoạt. Hỏi: "Nếu giữa Sprint một story phát sinh khó, ta có thể bỏ nó mà vẫn đạt Sprint Goal không?" Nếu câu trả lời là "không, vì mọi story đều bắt buộc", thì Sprint Goal của bạn vẫn đang là danh sách task trá hình — quay lại bước 2.
- Hiển thị nó ở nơi ai cũng thấy. Viết Sprint Goal lên đầu bảng Sprint, ghim trên kênh chat, nhắc lại đầu mỗi Daily Scrum. Một Sprint Goal không được nhìn thấy hằng ngày sẽ nhanh chóng bị lãng quên.
Lỗi thường gặp & mẹo
Lỗi 1 — Sprint Goal là tổng các story. Đây là lỗi phổ biến nhất. Dấu hiệu: Sprint Goal có dạng "Hoàn thành các story sau...". Mẹo: nếu xóa hết tên story đi mà câu mục tiêu chẳng còn ý nghĩa gì, bạn chưa có Sprint Goal thật.
Lỗi 2 — Quá nhiều mục tiêu. Dùng "và", "đồng thời", "cũng như" để nối nhiều mục tiêu. Mẹo: một Sprint, một sự tập trung. Việc khác vẫn làm được, nhưng chỉ một thứ là lý do của Sprint.
Lỗi 3 — Quá mơ hồ. "Cải thiện trải nghiệm người dùng" nghe hay nhưng không kiểm chứng được. Mẹo: thêm yếu tố đo được hoặc đối tượng cụ thể để biết khi nào thì coi là đạt.
Lỗi 4 — Viết Sprint Goal sau khi đã chọn xong story. Nhiều đội chọn story trước rồi mới "chế" một Sprint Goal cho khớp. Mẹo: làm ngược lại — để mục tiêu dẫn dắt việc chọn story, không phải để story định nghĩa mục tiêu.
Lỗi 5 — Coi Sprint Goal là cam kết cứng phải giao đủ scope. Sprint Goal là cam kết về hướng đi và giá trị, không phải lời hứa giao đúng từng story. (Phân biệt forecast và commitment đã học ở Bài 34.) Mẹo: nhấn mạnh với stakeholder rằng đội cam kết theo đuổi mục tiêu, và phạm vi cụ thể có thể co giãn quanh mục tiêu đó.
Mẹo về kỳ thi PSPO I: Đề thi rất hay đặt câu hỏi kiểu "Khi nào Sprint Goal được tạo ra?" (đáp án: trong Sprint Planning), "Ai sở hữu Sprint Goal?" (cả Scrum Team theo đuổi nó; PO chịu trách nhiệm về hướng giá trị), và "Có thể thay đổi Sprint Goal giữa Sprint không?" (Sprint Goal không thay đổi; nếu nó trở nên lỗi thời thì đó là tín hiệu để cân nhắc hủy Sprint — quyền của PO). Nắm chắc rằng phạm vi có thể đàm phán lại nhưng Sprint Goal thì giữ ổn định suốt Sprint.
Bài tập thực hành
- Sửa Sprint Goal dở. Lấy ba câu Sprint Goal kém dưới đây và viết lại cho tốt theo khung outcome:
- Craft từ bối cảnh thật. Giả sử bạn là PO của một ứng dụng giao đồ ăn ở Đông Nam Á. Dữ liệu cho thấy 20% khách hàng bỏ giỏ hàng vì không rõ phí giao hàng cho đến bước cuối. Hãy viết một Sprint Goal duy nhất, hướng outcome, có yếu tố đo được, gói trong một câu.
- Kiểm tra tính linh hoạt. Lấy Sprint Goal bạn vừa viết ở bài 2. Liệt kê 4–5 story có thể thuộc Sprint này. Sau đó chọn ra story khó nhất và tự hỏi: "Nếu bỏ story này, Sprint Goal có còn đạt được không?" Nếu câu trả lời là không cho mọi story, hãy craft lại mục tiêu cho rộng hơn.
- Bài tập 10 giây. Đọc Sprint Goal hiện tại của đội bạn (hoặc một Sprint Goal bạn tự nghĩ ra) cho một người không làm trong ngành nghe. Nếu sau 10 giây họ không nói lại được "Sprint này nhằm làm gì cho ai", hãy rút gọn thêm.
Tóm tắt
Sprint Goal là ngọn hải đăng của Sprint, và craft nó là một kỹ năng thực dụng mà mọi Product Owner giỏi đều rèn luyện. Một Sprint Goal tốt hội tụ ba đặc tính: Specific (cụ thể về kết quả, nhưng để mở về cách làm), Outcome-oriented (mô tả sự thay đổi cho người dùng/doanh nghiệp, không phải danh sách đầu việc), và Single sentence (một câu, một sự tập trung duy nhất, dễ nhớ để dùng làm điểm tựa trong Daily Scrum).
Ba sai lầm chí mạng cần tránh là: biến Sprint Goal thành danh sách task, nhồi nhiều mục tiêu ngang hàng, và viết quá mơ hồ đến mức không kiểm chứng được. Hãy nhớ rằng Sprint Goal được tạo ra trong Sprint Planning bởi cả Scrum Team, giữ ổn định suốt Sprint, và là cam kết về hướng giá trị — không phải lời hứa giao đủ từng story. Khi craft tốt, Sprint Goal cho Developers không gian tự quản để giải quyết vấn đề một cách linh hoạt, cho PO cơ sở để đàm phán phạm vi với stakeholder, và cho cả đội một lý do chung đáng để cùng nhau chèo về một hướng.