Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn là Product Owner (PO) của một đội phát triển ứng dụng giao đồ ăn tại TP.HCM. Mỗi hai tuần, đội của bạn cam kết hoàn thành một lượng công việc nhất định, rồi cuối kỳ ngồi lại trình diễn kết quả cho các bên liên quan. Nếu hai cuộc họp bản lề này — Sprint Planning (lập kế hoạch sprint) và Sprint Review (đánh giá sprint) — được làm hời hợt, cả sprint sẽ trôi đi trong mơ hồ: đội không biết mình đang chạy về đâu, còn lãnh đạo thì bất ngờ vì sản phẩm không giống kỳ vọng.
Đây chính là lý do bài học này quan trọng với bạn. Trong Scrum, PO không phải người viết code, nhưng là người định hướng giá trị. Hai sự kiện Sprint Planning và Sprint Review là nơi PO thể hiện rõ nhất vai trò "cầu nối giữa nhu cầu kinh doanh và đội kỹ thuật". Làm tốt hai sự kiện này, bạn biến một nhóm lập trình viên thành một đội tạo ra giá trị có chủ đích. Làm dở, bạn biến họ thành một "nhà máy code" chạy không phanh mà chẳng ai biết để làm gì.
Bài học này tập trung vào ba nhiệm vụ cốt lõi của PO: thiết lập Sprint Goal (mục tiêu sprint), lựa chọn và đưa story vào sprint, và dẫn dắt buổi Sprint Review để thu thập phản hồi giá trị. Chúng ta sẽ đi từ khái niệm, qua tình huống thực tế, đến quy trình từng bước bạn có thể áp dụng ngay vào tuần làm việc tới.
Khái niệm cốt lõi
Sprint Planning là gì và PO đóng vai trò gì
Sprint Planning là sự kiện mở đầu mỗi sprint, nơi cả Scrum Team (PO, Scrum Master, Developers) cùng trả lời ba câu hỏi: Tại sao sprint này có giá trị? Có thể hoàn thành được gì? Làm như thế nào?
Trong ba câu đó, PO chịu trách nhiệm chính ở câu đầu tiên và đồng trách nhiệm ở câu thứ hai. PO mang đến buổi họp một Product Backlog đã được sắp xếp ưu tiên (đã được "refine" — tinh chỉnh trước đó), giải thích bối cảnh kinh doanh, và đề xuất một Sprint Goal. Theo Scrum Guide, một Sprint Planning cho sprint hai tuần thường giới hạn tối đa khoảng 4 giờ (timebox). PO không áp đặt khối lượng công việc; chính Developers mới là người quyết định họ "kéo" được bao nhiêu vào sprint dựa trên năng lực (capacity) thực tế.
Sprint Goal — la bàn của cả sprint
Sprint Goal là một câu mô tả ngắn gọn về mục tiêu chung mà sprint hướng tới — một lý do duy nhất để cả đội cùng hành quân về một hướng. Nó không phải danh sách các story, mà là kết quả mong muốn.
Ví dụ, thay vì nói "làm 8 story về giỏ hàng", một Sprint Goal tốt sẽ là: "Cho phép khách hàng đặt và thanh toán một đơn hàng hoàn chỉnh qua VNPay." Sprint Goal tốt có vài đặc điểm: tập trung vào giá trị cho người dùng/kinh doanh, đủ cụ thể để biết khi nào đạt được, và đủ linh hoạt để đội có thể điều chỉnh cách làm trong sprint mà không phá vỡ mục tiêu. Khi giữa sprint có một story bị vướng, Sprint Goal giúp đội quyết định: cái gì thực sự cần để đạt mục tiêu, cái gì có thể bỏ lại.
Lựa chọn story đưa vào sprint
Đây là phần PO và Developers cộng tác chặt chẽ nhất. PO trình bày các Product Backlog Item (PBI) theo thứ tự ưu tiên. Với mỗi item ở đầu danh sách, đội thảo luận:
- Story đã đủ rõ chưa? Áp dụng tiêu chí "Definition of Ready" (định nghĩa thế nào là sẵn sàng): có mô tả rõ ràng, có tiêu chí chấp nhận (acceptance criteria), đã được ước lượng, không còn phụ thuộc lớn chưa giải quyết.
- Story có phục vụ Sprint Goal không? Nếu không liên quan, cân nhắc để lại.
- Đội có đủ capacity không? Dựa trên velocity (vận tốc — số điểm trung bình hoàn thành mỗi sprint) và lịch nghỉ phép, lễ tết.
Sprint Review — nơi giá trị được kiểm chứng
Sprint Review diễn ra cuối sprint. Đây không phải buổi nghiệm thu để "duyệt hay không duyệt", và càng không phải buổi báo cáo tiến độ khô khan. Đây là một buổi làm việc cộng tác (working session) nơi đội trình diễn phần Increment (phần sản phẩm đã hoàn thành), rồi cùng các bên liên quan thảo luận: thị trường đã thay đổi gì? người dùng phản hồi ra sao? backlog nên điều chỉnh thế nào?
PO dẫn dắt buổi này: mời đúng người (stakeholder thật sự quan tâm), khung lại bối cảnh, thu thập phản hồi và biến nó thành đầu vào cho việc điều chỉnh Product Backlog. Với sprint hai tuần, Sprint Review thường gói trong tối đa 2 giờ.
Tình huống thực tế
Tình huống 1: Tiki và một Sprint Goal cứu cả sprint
Một đội thuộc mảng thanh toán của một sàn thương mại điện tử lớn (tạm gọi theo bối cảnh Tiki) chuẩn bị sprint hai tuần với 10 story đủ loại: thêm phương thức ví điện tử, sửa lỗi giao diện, tối ưu tốc độ trang, và cập nhật báo cáo nội bộ. PO ban đầu chỉ kéo cả 10 story vào sprint mà không đặt mục tiêu chung.
Đến ngày thứ năm, một story ví điện tử bị vướng vì đối tác cổng thanh toán đổi API. Đội hoang mang: nên dồn người cứu story này, hay tiếp tục làm các story nhỏ khác cho "đủ số"? Vì không có Sprint Goal, mỗi người ưu tiên một kiểu, kết quả cuối sprint là 7 story xong nhưng tính năng ví điện tử — thứ Giám đốc sản phẩm trông đợi nhất — lại dang dở.
Sang sprint sau, PO đổi cách làm. Anh đặt Sprint Goal: "Khách hàng có thể thanh toán đơn hàng bằng ít nhất một ví điện tử (MoMo) ngay trong app." Mọi story được chọn đều phải phục vụ mục tiêu này; các việc lặt vặt được để lại backlog. Khi lại gặp trục trặc kỹ thuật giữa sprint, đội biết ngay phải dồn lực vào đâu. Cuối sprint, MoMo hoạt động trơn tru — đúng thứ quan trọng nhất.
Bài học: Số lượng story hoàn thành không bằng giá trị đạt được. Một Sprint Goal rõ ràng giúp đội ra quyết định đánh đổi đúng đắn khi có biến cố — và luôn có biến cố.
Tình huống 2: Startup fintech và bài học "kéo quá tay"
Một startup fintech ở Singapore với đội 5 developer có velocity ổn định khoảng 30 điểm/sprint. Trong một Sprint Planning, vì áp lực ra mắt tính năng vay tiêu dùng kịp chiến dịch marketing, PO thuyết phục đội cam kết 45 điểm — cao hơn 50% so với bình thường — với lý lẽ "lần này cố gắng hơn chút".
Hệ quả: đội làm vội, bỏ qua viết test, gộp tính năng ẩu để kịp. Cuối sprint chỉ "xong" 28 điểm trên giấy, nhưng hai tuần sau phát sinh hàng loạt lỗi sản xuất (production bug) phải sửa lại, tiêu tốn gần trọn sprint kế tiếp. Tính tổng, việc ép tiến độ khiến họ chậm hơn so với nếu đi đúng nhịp.
PO rút kinh nghiệm: trong Sprint Planning, anh để Developers tự quyết khối lượng dựa trên capacity thật (trừ ngày nghỉ, họp, hỗ trợ vận hành), còn mình tập trung làm rõ giá trị và ưu tiên. Khi cần ra mắt nhanh, thay vì ép đội làm nhiều hơn, anh thu hẹp phạm vi (scope) tính năng xuống một phiên bản tối thiểu chạy được, rồi bổ sung dần ở các sprint sau.
Bài học: PO định hướng cái gì và tại sao; Developers quyết định bao nhiêu và như thế nào. Ép cam kết vượt năng lực là cách nhanh nhất phá hỏng chất lượng và lòng tin.
Tình huống 3: Sprint Review biến thành "buổi báo cáo" vô hồn — và cách sửa
Một công ty SaaS B2B tại Hà Nội tổ chức Sprint Review đều đặn, nhưng buổi nào cũng giống nhau: PO chiếu slide liệt kê story đã xong, đọc to từng dòng, các sếp gật gù rồi tan họp. Không ai dùng thử sản phẩm, không ai phản hồi gì sâu sắc. Sau vài tháng, đội ngạc nhiên khi một tính năng quản lý hợp đồng — họ tự hào đã làm xong — gần như không ai dùng, vì nó giải quyết sai vấn đề của khách hàng.
PO thay đổi cách tổ chức Sprint Review. Thay vì slide, đội demo trực tiếp trên sản phẩm thật với dữ liệu thật. PO mời thêm hai khách hàng chủ chốt và một bạn sales tham gia. Đầu buổi, PO khung lại bối cảnh: "Sprint này chúng ta hướng tới giúp kế toán duyệt hợp đồng nhanh hơn — hãy xem thử và cho biết nó có thật sự nhanh hơn không." Khách hàng dùng thử ngay tại chỗ, chỉ ra rằng họ cần duyệt hàng loạt chứ không phải từng cái. Phản hồi đó lập tức trở thành story ưu tiên cao cho sprint sau.
Bài học: Sprint Review không phải để "khoe đã làm gì", mà để học xem nên làm gì tiếp theo. Demo trên sản phẩm thật và mời đúng người là khác biệt giữa một buổi họp lãng phí và một cơ hội điều chỉnh hướng đi kịp thời.
Hướng dẫn từng bước
Phần A — Chuẩn bị và dẫn dắt Sprint Planning
- Tinh chỉnh backlog trước buổi họp (Backlog Refinement). Đừng để Sprint Planning là lần đầu đội nhìn thấy story. Vài ngày trước, tổ chức buổi refinement để làm rõ mô tả, viết acceptance criteria, và ước lượng các item ở đầu backlog. Mục tiêu: các story top đầu đạt "Definition of Ready".
- Tính capacity thực tế của sprint. Cùng Scrum Master xác định số ngày làm việc thật: trừ ngày lễ (đặc biệt lưu ý Tết, giỗ Tổ, lễ 30/4–1/9), nghỉ phép đã biết, thời gian hỗ trợ vận hành. Tham chiếu velocity các sprint gần nhất.
- Đề xuất Sprint Goal. Mở đầu buổi họp bằng việc trình bày bối cảnh kinh doanh và đề xuất một mục tiêu sprint. Diễn đạt theo hướng giá trị: "Cuối sprint này, người dùng sẽ có thể...". Thảo luận để cả đội đồng thuận và đôi khi tinh chỉnh lại câu chữ.
- Trình bày story theo ưu tiên và để đội kéo việc. Đi từ trên xuống. Với mỗi story, làm rõ giá trị và trả lời thắc mắc kỹ thuật. Để Developers tự quyết khi nào "đủ" dựa trên capacity. Tuyệt đối không ép số.
- Chốt Sprint Backlog. Kết thúc khi đội có: Sprint Goal rõ ràng + tập story đã chọn + kế hoạch sơ bộ để bắt đầu. Đọc lại Sprint Goal một lần cuối để mọi người cùng cam kết.
Phần B — Tổ chức Sprint Review hiệu quả
- Mời đúng người. Không chỉ nội bộ đội. Mời stakeholder thật sự quan tâm tới kết quả: lãnh đạo sản phẩm, sales, chăm sóc khách hàng, và nếu được, cả khách hàng/người dùng thật.
- Khung lại bối cảnh đầu buổi. Nhắc lại Sprint Goal và bối cảnh thị trường. Cho người tham dự biết bạn muốn nghe phản hồi về điều gì.
- Demo trên sản phẩm thật, không phải slide. Trình diễn Increment đã hoàn thành (đạt "Definition of Done") trên môi trường thật với dữ liệu thật. Cho stakeholder tự thao tác nếu có thể.
- Thu thập và ghi nhận phản hồi. Đặt câu hỏi mở: "Điều này có giải quyết đúng vấn đề của bạn không? Còn thiếu gì?" Ghi lại mọi insight ngay tại chỗ.
- Điều chỉnh Product Backlog. Sau buổi review, cập nhật backlog: thêm story mới từ phản hồi, sắp xếp lại ưu tiên. Đây mới là kết quả thật sự của Sprint Review — một backlog phản ánh đúng thực tế mới nhất.
Lỗi thường gặp & mẹo
- Coi Sprint Planning chỉ là chia việc. Nếu buổi họp chỉ xoay quanh "ai làm story nào" mà không có Sprint Goal, đội sẽ mất phương hướng khi gặp biến cố. Mẹo: luôn chốt Sprint Goal trước khi bàn chi tiết.
- PO ép khối lượng công việc. Đây là lỗi phá vỡ niềm tin nhanh nhất. Mẹo: tách bạch vai trò — bạn lo giá trị và ưu tiên, đội lo dung lượng. Khi gấp, hãy cắt phạm vi chứ đừng ép giờ.
- Đưa story chưa rõ vào sprint. Story thiếu acceptance criteria sẽ khiến đội mất nửa sprint chỉ để làm rõ yêu cầu. Mẹo: áp dụng nghiêm "Definition of Ready"; story chưa sẵn sàng thì để lại.
- Sprint Goal là danh sách story trá hình. "Hoàn thành story A, B, C" không phải mục tiêu. Mẹo: viết Sprint Goal dưới dạng kết quả cho người dùng, kiểm tra bằng câu hỏi "nếu bỏ một story, mục tiêu còn đạt được không?".
- Sprint Review thành buổi đọc slide. Mất hoàn toàn giá trị học hỏi. Mẹo: cấm slide liệt kê, bắt buộc demo sản phẩm thật và mời người dùng thật.
- Demo cả thứ chưa "Done". Trình diễn tính năng còn dang dở gây hiểu lầm về tiến độ. Mẹo: chỉ demo phần đạt Definition of Done.
- Không hành động sau review. Thu thập phản hồi rồi để đó là lãng phí. Mẹo: dành 15 phút ngay sau buổi để cập nhật backlog khi insight còn nóng hổi.
Bài tập thực hành
- Viết Sprint Goal. Cho bối cảnh: đội bạn làm app đặt lịch khám bệnh, backlog có các story về đăng nhập OTP, chọn bác sĩ, đặt lịch, và nhắc lịch qua SMS. Hãy viết một Sprint Goal duy nhất tập trung vào giá trị cho người dùng, rồi chọn 3–4 story phục vụ mục tiêu đó và giải thích vì sao bạn để các story còn lại ra ngoài.
- Tính capacity. Đội có 4 developer, sprint dài 10 ngày làm việc. Trong sprint có 1 ngày lễ, một bạn nghỉ phép 2 ngày, và mỗi developer dành trung bình 10% thời gian hỗ trợ vận hành. Hãy ước tính số ngày-người khả dụng. Nếu velocity gần đây là 30 điểm, bạn sẽ tư vấn đội kéo bao nhiêu điểm vào sprint? Giải thích lập luận.
- Thiết kế kịch bản Sprint Review. Soạn một agenda 60 phút cho buổi Sprint Review của một tính năng giỏ hàng vừa hoàn thành: ai bạn sẽ mời, bạn khung lại bối cảnh thế nào, demo cái gì, và bạn dự định đặt những câu hỏi mở nào để thu thập phản hồi giá trị.
- Phân tích lỗi. Đọc lại Tình huống 2 (startup fintech kéo quá tay). Viết 3 hành động cụ thể bạn sẽ làm trong Sprint Planning tiếp theo để tránh lặp lại sai lầm này.
Tóm tắt
Sprint Planning và Sprint Review là hai sự kiện bản lề nơi Product Owner thể hiện rõ nhất vai trò định hướng giá trị trong Scrum. Ở Sprint Planning, nhiệm vụ cốt lõi của PO là mang đến một backlog đã được tinh chỉnh, đề xuất một Sprint Goal rõ ràng hướng tới giá trị, và cùng đội lựa chọn story phù hợp — trong khi tôn trọng quyền quyết định khối lượng công việc của Developers dựa trên capacity thật. Một Sprint Goal tốt là la bàn giúp đội ra quyết định đúng khi có biến cố giữa sprint.
Ở Sprint Review, PO biến buổi họp từ một màn "báo cáo đã làm gì" thành một cơ hội học hỏi: demo sản phẩm thật, mời đúng người, thu thập phản hồi và biến nó thành điều chỉnh cụ thể cho Product Backlog. Ba tình huống thực tế cho thấy cùng một sự khác biệt: thành công không đến từ việc làm nhiều hơn, mà từ việc làm đúng thứ tạo giá trị và liên tục học hỏi để điều chỉnh hướng đi. Nắm vững hai sự kiện này, bạn không chỉ "chạy Scrum đúng quy trình" mà thực sự dẫn dắt đội tạo ra sản phẩm mà người dùng cần.