Mở đầu — vì sao bài này quan trọng
Nếu bạn từng dự một buổi Sprint Planning kéo dài tới bốn tiếng mà cả team vẫn không chốt được sẽ làm gì trong hai tuần tới, thì bạn đã tận mắt chứng kiến cái giá của việc coi thường hai hoạt động: Backlog Refinement (làm mịn backlog) và Sprint Planning (lập kế hoạch sprint). Đây là cặp bài trùng quan trọng bậc nhất trong nhịp làm việc của một team Agile. Refinement là nơi bạn chuẩn bị nguyên liệu; Planning là nơi bạn nấu thành món ăn. Nếu nguyên liệu chưa sơ chế, bữa tiệc Planning chắc chắn thành thảm họa.
Với vai trò PM (hay Product Owner), đây chính là hai buổi họp mà bạn "cầm trịch" nhiều nhất. Boards, JQL, story points hay velocity — những thứ bạn học ở các bài khác — đều chỉ là công cụ. Nhưng chính trong Refinement và Planning, bạn mới thực sự biến một mớ ý tưởng mơ hồ thành một kế hoạch mà đội kỹ thuật tin tưởng và cam kết thực hiện. Làm tốt hai buổi này, team của bạn đi vào sprint với sự rõ ràng và tự tin. Làm dở, team sẽ loay hoay giữa chừng, story bị "carry over" liên miên, và niềm tin vào quy trình dần bào mòn.
Bài học này tập trung riêng vào cách vận hành hai hoạt động đó một cách bài bản: khi nào họp, họp bao lâu, đầu ra phải là gì, và làm thế nào để mỗi story bước vào sprint đã sẵn sàng để code, không phải sẵn sàng để... tranh cãi.
Khái niệm cốt lõi
Backlog Refinement — làm mịn để không phải "vá" giữa sprint
Backlog Refinement (trước đây hay gọi là grooming, nay Atlassian và Scrum Guide khuyến nghị dùng refinement) là hoạt động liên tục mà PM cùng team rà soát các hạng mục ở đầu backlog, làm cho chúng đủ rõ ràng và đủ nhỏ để có thể đưa vào sprint sắp tới.
Điểm mấu chốt cần nhớ:
- Nhịp độ (cadence): thường 1–2 lần mỗi sprint, mỗi buổi 60–90 phút. Với sprint 2 tuần, một buổi giữa tuần đầu và một buổi cuối tuần đầu là mô hình phổ biến. Refinement không phải sự kiện chính thức bắt buộc trong Scrum, nhưng thực tế team nào bỏ nó đều trả giá bằng những buổi Planning hỗn loạn.
- Đầu ra (output): một backlog đã được refine đủ cho 2–3 sprint phía trước. Nghĩa là bất kỳ lúc nào, luôn có sẵn 2–3 sprint "nguyên liệu" ở trạng thái sẵn sàng. Mỗi story đã refine cần có: mô tả rõ ràng, Acceptance Criteria (tiêu chí nghiệm thu), được estimate (ước lượng), đủ nhỏ để hoàn thành gọn trong một sprint, và không còn phụ thuộc chặn (blocker) chưa được giải quyết.
Định nghĩa "Ready" — cửa vào của Refinement
Song song với "Definition of Done" (mà bạn sẽ học kỹ ở Bài 15), team nên có một Definition of Ready (DoR) — bộ tiêu chí để một story được coi là "đủ chín" để đưa vào Planning. Một DoR điển hình gồm: có AC rõ ràng, đã được estimate, đủ nhỏ (thường ≤ nửa velocity của team để tránh story "khủng long"), dependency đã được nhận diện, và có thiết kế/mockup nếu là task giao diện. DoR là "cửa ra" của Refinement.
Sprint Planning — chuyển từ "có thể làm" sang "cam kết làm"
Sprint Planning là buổi họp đầu mỗi sprint, nơi team quyết định: Sprint Goal (mục tiêu sprint) là gì, và những story nào sẽ được kéo vào sprint để phục vụ mục tiêu đó. Scrum Guide gợi ý Planning kéo dài tối đa 8 tiếng cho sprint 4 tuần — quy đổi ra khoảng 2–4 tiếng cho sprint 2 tuần.
Planning trả lời ba câu hỏi kinh điển:
- Why — Vì sao sprint này đáng làm? Đây là Sprint Goal, thường do PM đề xuất.
- What — Có thể hoàn thành được những gì? Team chọn story từ đỉnh backlog dựa trên velocity và capacity.
- How — Sẽ làm như thế nào? Team chia story thành các task kỹ thuật, bàn cách tiếp cận.
Mối quan hệ giữa hai hoạt động
Hãy nhớ công thức đơn giản: Refinement chuẩn bị — Planning cam kết. Refinement là nơi bạn hỏi "story này nghĩa là gì, làm thế nào, bao lớn?". Planning là nơi bạn hỏi "sprint này ta cam kết làm bao nhiêu, để đạt mục tiêu gì?". Tách bạch hai vai trò này là dấu hiệu của một team trưởng thành.
Tình huống thực tế
Ví dụ 1: Team fintech ở TP.HCM và buổi Planning 4 tiếng ám ảnh
Một công ty fintech tại Quận 1, TP.HCM (tạm gọi là PayFast) có team 7 người làm ví điện tử. Trong ba sprint liên tiếp, buổi Sprint Planning của họ kéo dài trung bình 3.5–4 tiếng, ai nấy kiệt sức. Khi PM ngồi lại phân tích, chị nhận ra: 60% thời gian Planning bị tiêu vào việc lần đầu thảo luận nghiệp vụ của story — kiểu "à mà chức năng hoàn tiền này áp dụng cho giao dịch quá 30 ngày không nhỉ?". Đó là câu hỏi lẽ ra phải được trả lời từ tuần trước.
Nguyên nhân gốc: team hoàn toàn không có buổi Refinement. Backlog chỉ là danh sách tiêu đề, không AC, không estimate. Giải pháp chị áp dụng: đưa vào hai buổi Refinement mỗi sprint, mỗi buổi 75 phút, mời thêm 1 dev lead và 1 QA. Sau ba sprint, thời gian Planning giảm còn 90 phút. Con số carry-over (story dở dang chuyển sang sprint sau) giảm từ 4 story/sprint xuống còn 1.
Bài học: Planning dài lê thê hầu như luôn là triệu chứng của Refinement thiếu hoặc yếu. Đừng chữa triệu chứng bằng cách "họp Planning kỹ hơn"; hãy chữa gốc bằng Refinement đều đặn.
Ví dụ 2: Story "khủng long" ở một startup e-commerce Đông Nam Á
Một startup thương mại điện tử hoạt động ở Việt Nam và Indonesia có team 6 dev, velocity trung bình 30 điểm/sprint. Trong backlog xuất hiện một story: "Xây dựng hệ thống khuyến mãi" — được estimate... 40 điểm. Nghĩa là một story còn lớn hơn cả sức chứa của cả sprint. Đương nhiên nó không bao giờ hoàn thành gọn trong một sprint, kéo dài qua ba sprint và luôn ở trạng thái "đang làm".
Trong một buổi Refinement, PM cùng team quyết định "mổ xẻ" (split) story này theo lát cắt giá trị: (1) tạo mã giảm giá cố định, (2) giảm giá theo phần trăm, (3) giới hạn số lần dùng, (4) khuyến mãi theo nhóm sản phẩm, (5) trang quản trị cho marketing. Mỗi story con giờ chỉ 5–8 điểm, mỗi cái đều mang lại giá trị dùng được ngay. Sprint kế tiếp, team giao được hai story con hoàn chỉnh và demo được cho phía marketing.
Bài học: Một tiêu chí "Ready" quan trọng là story phải đủ nhỏ — theo kinh nghiệm, không nên vượt quá nửa velocity của team. Refinement chính là nơi để phát hiện và chẻ nhỏ những "con khủng long" trước khi chúng lọt vào sprint và làm hỏng cả nhịp làm việc.
Ví dụ 3: Sprint Goal mờ nhạt ở một team agency Hà Nội
Một agency phần mềm ở Hà Nội nhận outsource cho khách hàng Nhật. Team thường vào sprint với một danh sách 12 story rời rạc, không có mục tiêu chung. Kết quả: khi phải đánh đổi ưu tiên giữa sprint (một bug production nổ ra), không ai biết nên hy sinh story nào, vì mọi story "đều quan trọng như nhau". Sprint Review thì nhạt nhẽo vì chẳng có câu chuyện gì để kể với khách.
PM mới về áp dụng nguyên tắc: mỗi sprint phải có một Sprint Goal viết thành một câu. Ví dụ sprint đó: "Cho phép khách hàng đặt hàng và thanh toán COD hoàn chỉnh trên mobile". Mọi story được chọn phải phục vụ mục tiêu này; story không liên quan bị đẩy xuống. Khi bug production xuất hiện, quyết định đánh đổi trở nên rõ ràng: giữ những story phục vụ Goal, tạm gác phần còn lại. Buổi Review sau đó có một "câu chuyện" mạch lạc để trình bày, khách hàng Nhật hài lòng thấy rõ.
Bài học: Planning không chỉ là chọn story — nó là cam kết vào một Sprint Goal rõ ràng. Goal là la bàn giúp team ra quyết định khi có biến động giữa sprint.
Hướng dẫn từng bước
Phần A — Chạy một buổi Backlog Refinement
- Chuẩn bị trước buổi họp (PM làm một mình). Sắp xếp thứ tự ưu tiên backlog, kéo những hạng mục sắp tới lên đầu. Với mỗi story dự kiến refine, viết nháp mô tả và AC trước. Đừng bắt cả team ngồi chờ bạn gõ chữ.
- Mở đầu bằng ngữ cảnh sản phẩm. Nhắc ngắn về hướng đi sản phẩm để team hiểu vì sao những story này lại lên đầu. Refinement không nên tách rời khỏi bức tranh lớn.
- Đi qua từng story theo thứ tự ưu tiên. Với mỗi story: làm rõ nghiệp vụ, chốt AC, nhận diện dependency, và để team estimate (thường bằng Planning Poker — bạn sẽ học sâu về story points ở Bài 14).
- Split khi cần. Nếu một story quá lớn hoặc còn quá mơ hồ, chẻ nhỏ ngay tại chỗ theo lát cắt giá trị.
- Đánh dấu trạng thái "Ready". Trong Jira, nhiều team dùng một label như
ready-for-sprinthoặc một status riêng để đánh dấu story đã đạt Definition of Ready. - Dừng đúng giờ. Đặt timebox 60–90 phút. Mục tiêu là luôn có sẵn 2–3 sprint story đã refine, không phải refine sạch cả backlog trong một buổi.
Phần B — Chạy một buổi Sprint Planning
- Kiểm tra sức chứa (capacity). Trước buổi họp, tính velocity trung bình 3–4 sprint gần nhất và trừ đi ngày nghỉ, họp, hỗ trợ. Ví dụ velocity 30 điểm nhưng sprint này có người nghỉ 2 ngày thì capacity thực chỉ khoảng 25–26.
- Trình bày Sprint Goal. PM đề xuất mục tiêu sprint bằng một câu. Team thảo luận và đồng thuận.
- Kéo story từ đỉnh backlog. Chọn các story đã "Ready" phục vụ Goal, kéo lần lượt cho đến khi tổng điểm chạm capacity. Dừng lại khi đủ — đừng nhồi cho đầy.
- Bàn cách làm (How). Team chia story thành task kỹ thuật, thống nhất hướng tiếp cận, và phát hiện sớm rủi ro.
- Kiểm tra tính khả thi lần cuối. Hỏi cả team: "Chúng ta có thực sự tin sẽ hoàn thành được số này để đạt Goal không?". Nếu ai đó lăn tăn, đây là lúc điều chỉnh, không phải giữa sprint.
- Chốt cam kết. Sprint Backlog được khóa. Từ đây, thay đổi phạm vi cần được cân nhắc cẩn trọng.
Lỗi thường gặp & mẹo
- Bỏ qua Refinement rồi trách Planning quá dài. Đây là lỗi số một. Không có Refinement, Planning bắt buộc phải gánh cả việc làm mịn story — và luôn quá tải. Mẹo: coi Refinement là bất khả xâm phạm trên lịch, ngang hàng với Planning.
- Refinement quá sâu, quá xa. Một số PM refine tận 5–6 sprint phía trước, tô vẽ chi tiết cho những story mà ưu tiên có thể thay đổi hoàn toàn trước khi tới lượt. Đó là lãng phí. Mẹo: chỉ refine đủ 2–3 sprint; ưu tiên độ rõ cho những gì gần, chấp nhận mơ hồ cho những gì xa.
- Nhồi Sprint Backlog cho bằng đúng velocity. Nhồi 30 điểm vào velocity 30 điểm là công thức của burnout và carry-over. Mẹo: chừa 10–20% đệm cho việc phát sinh, bug, hỗ trợ.
- Không có Sprint Goal, hoặc Goal là "làm xong 12 story này". Đó không phải mục tiêu, đó là danh sách việc. Mẹo: viết Goal theo giá trị người dùng, một câu, bắt đầu bằng động từ.
- PM áp đặt estimate. Estimate là của người thực thi. PM áp con số của mình vào chỉ tạo ra những cam kết giả. Mẹo: bạn làm rõ nghiệp vụ, để dev/QA tự estimate.
- Không mời QA vào Refinement. QA thường là người phát hiện những "case biên" khiến AC còn thiếu. Thiếu họ, AC hay hở. Mẹo: luôn có ít nhất một QA trong buổi Refinement.
- Coi Sprint Backlog là bất biến tuyệt đối. Ngược lại với lỗi nhồi nhét — có PM cứng nhắc tới mức không cho điều chỉnh khi rõ ràng đã sai. Mẹo: Sprint Goal là cam kết; danh sách story là công cụ, có thể điều chỉnh trong sprint miễn vẫn phục vụ Goal.
Bài tập thực hành
- Thiết kế Definition of Ready cho team của bạn. Viết ra 5–7 tiêu chí mà một story phải đạt trước khi được đưa vào Planning. Đối chiếu với backlog hiện tại: bao nhiêu phần trăm story ở đỉnh backlog thực sự đạt tiêu chí?
- Refine thử một epic. Chọn một tính năng lớn bất kỳ (ví dụ "Đăng nhập bằng mạng xã hội"). Chẻ nó thành các story con, mỗi story ≤ 8 điểm, mỗi story mang giá trị dùng được độc lập. Viết AC cho ít nhất hai story con.
- Tính capacity thực. Giả sử team bạn có velocity trung bình 28 điểm/sprint (2 tuần). Sprint tới có một dev nghỉ 3 ngày và cả team mất nửa ngày cho một buổi training. Hãy ước lượng capacity điều chỉnh và giải thích cách bạn ra con số đó.
- Viết ba Sprint Goal. Với ba nhóm story giả định khác nhau, viết mỗi nhóm một Sprint Goal theo dạng một câu, hướng giá trị người dùng. Tự chấm: câu Goal của bạn có giúp ra quyết định đánh đổi giữa sprint không?
Tóm tắt
Backlog Refinement và Sprint Planning là cặp bài trùng quyết định chất lượng cả một sprint. Refinement diễn ra 1–2 lần mỗi sprint, mỗi buổi 60–90 phút, với đầu ra là backlog đủ mịn cho 2–3 sprint phía trước — mỗi story có AC rõ ràng, đã estimate, đủ nhỏ và không còn blocker. Planning diễn ra đầu sprint, 2–4 tiếng cho sprint hai tuần, trả lời ba câu hỏi Why–What–How, và chốt lại bằng một Sprint Goal rõ ràng cùng cam kết vừa sức.
Nguyên tắc vàng cần khắc cốt ghi tâm: Refinement chuẩn bị — Planning cam kết. Khi bạn đầu tư nghiêm túc vào Refinement, Planning trở nên nhẹ nhàng, ngắn gọn và đầy tự tin. Khi bạn bỏ Refinement, mọi gánh nặng dồn vào Planning và cả team phải trả giá bằng những buổi họp kiệt sức lẫn những story dở dang kéo dài. Ba tình huống ở trên — từ team fintech TP.HCM, startup e-commerce, đến agency Hà Nội — đều kể cùng một bài học: chuẩn bị tốt trước, thì cam kết sẽ dễ và bền.