9 giờ sáng thứ Hai, cả team ngồi trong phòng họp (hoặc trên Zoom) để làm sprint planning. Product Owner mở Jira, kéo xuống backlog 60 story chưa refine hết, Scrum Master hỏi "velocity trung bình 3 sprint gần nhất là bao nhiêu nhỉ", còn Tech Lead thì đang cố nhớ xem story nào phụ thuộc vào API mà team Platform vẫn chưa merge xong. Hai giờ đồng hồ trôi qua trong việc dò tìm thông tin, thay vì thực sự bàn về việc nên cam kết làm gì trong hai tuần tới. Đây là thực trạng của phần lớn các buổi sprint planning — không phải vì team thiếu năng lực, mà vì công việc chuẩn bị dữ liệu trước khi ra quyết định luôn ngốn quá nhiều thời gian thủ công. AI không thay bạn quyết định sprint goal là gì, nhưng nó có thể rút ngắn phần chuẩn bị — đọc story, quét dependency, đối chiếu velocity — từ hàng giờ xuống còn vài phút, để cả team dành thời gian quý giá cho phần duy nhất máy không làm thay được: đàm phán, cam kết, và ra quyết định có trách nhiệm.
Bài viết này đi từ việc dùng AI để phân tích độ sẵn sàng của backlog trước khi vào phòng họp, đến cách AI hỗ trợ đề xuất sprint goal, tính toán scope hợp lý theo capacity, và cuối cùng là rà soát rủi ro trước khi team chốt cam kết. Đây là bộ kỹ năng nền tảng mà mọi BA/PM/PO làm việc trong môi trường agentic (có AI hỗ trợ tác vụ) cần thành thạo, vì sprint planning là ceremony (nghi thức Agile định kỳ) đầu tiên quyết định chất lượng của cả hai tuần tiếp theo.
Phân Tích Tiền Kế Hoạch: Đánh Giá Độ Sẵn Sàng Của Story, Quét Dependency, Và Gắn Cờ Độ Phức Tạp
Trước khi bước vào phòng planning, bạn cần biết chắc backlog nào thực sự "ready" (đủ điều kiện đưa vào sprint) và backlog nào chỉ trông có vẻ ready. Đây là bước dễ bị bỏ qua nhất trong quy trình Agile truyền thống, vì nó đòi hỏi đọc lại từng story một cách có hệ thống — công việc nhàm chán, tốn thời gian, và rất dễ bị làm qua loa khi deadline dí sát.
Vì Sao Bước Này Quyết Định Chất Lượng Cả Sprint
Một sprint thất bại thường không bắt đầu từ ngày thực thi, mà bắt đầu từ chính buổi planning — khi team cam kết làm những story chưa đủ rõ ràng, có dependency (phụ thuộc) chưa được giải quyết, hoặc bị đánh giá thấp độ phức tạp. Nếu bạn phát hiện vấn đề này ở ngày 7 của sprint, chi phí sửa chữa (re-plan, xin thêm thời gian, báo cáo stakeholder) cao hơn rất nhiều so với phát hiện ở ngày 0.
AI đặc biệt hữu ích ở đây vì nó có thể đọc toàn bộ backlog ứng viên cho sprint tới trong vài phút, áp dụng nhất quán một bộ tiêu chí Definition of Ready (điều kiện để một story được coi là sẵn sàng), và chỉ ra chính xác story nào thiếu gì — thay vì để PO tự nhớ hoặc lướt qua bằng cảm tính.
Các Bước Thực Hành
- Tập hợp danh sách story ứng viên. Export hoặc copy toàn bộ story trong backlog đã được đánh dấu "candidate for next sprint" từ Jira/Linear, bao gồm title, mô tả, acceptance criteria, và các comment gần nhất.
- Chuẩn bị Definition of Ready của team. Nếu team chưa có DoR bằng văn bản, hãy viết ra càng cụ thể càng tốt (ví dụ: có acceptance criteria rõ ràng, đã ước lượng story point, không còn câu hỏi mở, dependency đã xác định).
- Đưa cả hai vào AI (ChatGPT, Claude, hoặc trợ lý tích hợp sẵn trong Jira) và yêu cầu chấm điểm từng story theo DoR.
- Quét dependency chéo. Yêu cầu AI đọc mô tả và comment của từng story để tìm các cụm từ ám chỉ phụ thuộc ("chờ API", "cần team X hoàn tất", "phụ thuộc vào migration Y").
- Gắn cờ độ phức tạp bất thường. So sánh mô tả story với story point đã gán — story nào có mô tả phức tạp (nhiều điều kiện, nhiều actor, tích hợp nhiều hệ thống) nhưng lại được estimate thấp là dấu hiệu cần refine lại trước khi đưa vào sprint.
- Tổng hợp thành một bảng readiness để PO/Scrum Master mang vào phòng planning, thay vì phải nhớ hoặc lật lại từng story riêng lẻ.
Ví Dụ Prompt
Bạn là một Product Owner giàu kinh nghiệm, chuyên chuẩn bị backlog cho
sprint planning.
Dưới đây là Definition of Ready của team:
[PASTE DEFINITION OF READY]
Dưới đây là danh sách story ứng viên cho sprint tới (title, mô tả,
acceptance criteria, story point hiện tại):
[PASTE DANH SÁCH STORY]
Hãy đánh giá từng story theo các bước:
1. Chấm điểm Ready (Đạt/Chưa đạt) theo từng tiêu chí trong Definition
of Ready, chỉ rõ tiêu chí nào chưa đạt và vì sao.
2. Quét toàn bộ mô tả và comment để tìm dấu hiệu dependency (phụ thuộc
vào team khác, API chưa sẵn sàng, cần dữ liệu/thiết kế chưa có).
3. Gắn cờ "Cần Refine Thêm" cho story có mô tả phức tạp nhưng story
point hiện tại có vẻ thấp bất thường so với độ phức tạp mô tả.
4. Xuất kết quả dưới dạng bảng: Story | Ready? | Tiêu chí thiếu |
Dependency phát hiện | Cần refine thêm? | Ghi chú.
Trả lời bằng tiếng Việt, giữ nguyên thuật ngữ kỹ thuật tiếng Anh.
Dựa trên bảng đánh giá readiness ở trên, hãy tạo một email/message ngắn
gọn (dưới 200 từ) để gửi cho Tech Lead và các bên liên quan trước buổi
sprint planning, nêu rõ:
1. Danh sách story CHƯA sẵn sàng và câu hỏi cụ thể cần được trả lời
trước khi planning (không phải trong lúc planning).
2. Dependency nào cần được xác nhận trước với team khác.
Viết theo giọng chuyên nghiệp, súc tích, phù hợp gửi qua Slack.
Mẹo: Chạy bước phân tích readiness này ít nhất 1-2 ngày trước buổi planning, không phải sáng hôm đó. Việc này cho bạn đủ thời gian để đi hỏi lại PO/dev về các câu hỏi mở mà AI phát hiện ra, thay vì phải giải quyết ngay tại chỗ và làm chậm cả buổi họp.
Tạo Đề Xuất Sprint Goal Dựa Trên Roadmap, Capacity, Và Dependency
Sprint goal (mục tiêu sprint) tốt là câu trả lời cho câu hỏi "vì sao chúng ta làm những story này, chứ không phải story khác". Nhiều team bỏ qua bước này và chỉ đơn giản kéo story theo thứ tự ưu tiên trong backlog vào sprint — kết quả là một sprint không có "câu chuyện", khó demo, khó giải thích cho stakeholder, và khó tạo động lực gắn kết cho team.
Vì Sao Sprint Goal Thường Bị Làm Qua Loa
Viết sprint goal tốt đòi hỏi nhìn đồng thời ba thứ: roadmap dài hạn (câu chuyện lớn công ty đang kể), capacity thực tế của team (bao nhiêu việc có thể làm), và các dependency đang chờ xử lý. Đây là việc tốn công tổng hợp thủ công, nên trong thực tế nhiều PO viết sprint goal kiểu chung chung ("Hoàn thành các story ưu tiên cao") — vô nghĩa và không giúp ích gì cho việc ra quyết định trong sprint.
AI có lợi thế ở đây vì nó có thể đọc đồng thời roadmap, backlog đã refine, và dữ liệu capacity, rồi đề xuất một vài phương án sprint goal khác nhau kèm lý do — biến việc "brainstorm sprint goal" từ việc một người ngồi nghĩ ra thành việc có sẵn 2-3 phương án để cả team thảo luận và chọn.
Các Bước Thực Hành
- Tập hợp context roadmap. Lấy đoạn roadmap quý hiện tại hoặc OKR (Objectives and Key Results) liên quan đến team.
- Tập hợp backlog đã refine, sẵn sàng cho sprint tới (kết quả từ bước Pre-Planning Analysis ở trên).
- Đưa cả hai vào AI, yêu cầu đề xuất 2-3 phương án sprint goal, mỗi phương án gắn với một tập story cụ thể.
- Yêu cầu AI giải thích trade-off giữa các phương án — phương án nào đóng góp trực tiếp cho OKR quý, phương án nào giảm risk kỹ thuật, phương án nào tạo giá trị demo rõ ràng nhất cho stakeholder.
- Mang các phương án vào phòng planning như điểm khởi đầu thảo luận, không phải quyết định cuối cùng — team vẫn cần thảo luận và điều chỉnh.
- Chốt sprint goal cuối cùng và yêu cầu AI viết lại thành một câu ngắn gọn, dễ nhớ, có thể dán lên đầu sprint board.
Ví Dụ Prompt
Bạn là một Product Manager đang chuẩn bị đề xuất sprint goal cho sprint
tới.
Roadmap/OKR quý hiện tại:
[PASTE ROADMAP HOẶC OKR]
Backlog đã refine, sẵn sàng cho sprint (kèm story point):
[PASTE DANH SÁCH STORY ĐÃ REFINE]
Capacity team sprint tới: [SỐ NGƯỜI] người, [SỐ NGÀY] ngày làm việc,
velocity trung bình 3 sprint gần nhất: [SỐ STORY POINT].
Hãy đề xuất 3 phương án sprint goal khác nhau, mỗi phương án gồm:
1. Câu sprint goal ngắn gọn (dưới 20 từ), viết theo văn phong outcome
(kết quả), không phải văn phong task list.
2. Danh sách story cụ thể thuộc phương án này, tổng story point.
3. Lý do phương án này đáng cân nhắc (đóng góp OKR nào, giảm risk gì,
giá trị demo cho stakeholder ra sao).
4. Rủi ro chính của phương án (nếu có).
Trả lời bằng tiếng Việt, giữ thuật ngữ kỹ thuật tiếng Anh.
Mẹo: Đừng để AI tự chọn phương án cuối cùng. Vai trò của AI là "mở rộng không gian lựa chọn" — cho bạn 3 góc nhìn khác nhau về cùng một backlog. Quyết định cuối cùng luôn thuộc về PO, dựa trên bối cảnh chính trị nội bộ, ưu tiên stakeholder, và trực giác nghề nghiệp mà AI không có.
Dùng AI Để Đề Xuất Sprint Scope Tối Ưu Dựa Trên Velocity Và Capacity Của Team
Sau khi có sprint goal, câu hỏi tiếp theo là: đưa bao nhiêu story vào sprint là vừa đủ? Đây là bài toán cân bằng kinh điển — cam kết quá nhiều dẫn đến sprint thất bại liên tục, làm giảm niềm tin của stakeholder; cam kết quá ít khiến team không được thử thách và roadmap chậm tiến độ.
Velocity Không Phải Là Một Con Số Cố Định
Nhiều team mắc sai lầm coi velocity (tốc độ hoàn thành công việc, đo bằng story point mỗi sprint) như một hằng số cố định, trong khi thực tế nó dao động theo nhiều yếu tố: số ngày nghỉ lễ trong sprint, thành viên mới join team, một dev đang nghỉ phép, hoặc sprint trước có story bị carry-over (chuyển tiếp sang sprint sau).
AI giúp bạn tính velocity điều chỉnh (adjusted velocity) một cách nhất quán, thay vì chỉ lấy trung bình cộng thô của 3 sprint gần nhất — vốn có thể sai lệch đáng kể nếu một trong ba sprint đó có bất thường.
Các Bước Thực Hành
- Tập hợp dữ liệu velocity 5-6 sprint gần nhất, kèm ghi chú bất thường của từng sprint (nghỉ lễ, member vắng mặt, sprint bị gián đoạn).
- Tập hợp capacity thực tế của sprint tới — số ngày làm việc, số người, tỷ lệ % thời gian dành cho việc khác ngoài sprint (họp, support, on-call).
- Đưa dữ liệu vào AI, yêu cầu tính velocity điều chỉnh và đề xuất scope tối đa nên cam kết.
- Đối chiếu với danh sách story đã sắp theo sprint goal đã chọn ở bước trước, để AI đề xuất chính xác nên dừng ở story nào trong backlog.
- Yêu cầu AI đề xuất một khoảng buffer (dự phòng) hợp lý — không nên cam kết 100% capacity tính toán được, vì luôn có việc phát sinh giữa sprint.
- Trình bày con số này cho team như một điểm tham chiếu, để team tự quyết định cam kết cuối cùng dựa trên cảm nhận thực tế của họ về độ khó từng story.
Ví Dụ Prompt
Bạn là một Scrum Master đang hỗ trợ tính toán sprint scope hợp lý.
Dữ liệu velocity 6 sprint gần nhất (story point hoàn thành, ghi chú bất
thường nếu có):
[PASTE DỮ LIỆU VELOCITY, ví dụ:
Sprint 20: 42 điểm (bình thường)
Sprint 21: 28 điểm (2 người nghỉ phép 1 tuần)
Sprint 22: 45 điểm (bình thường)
Sprint 23: 38 điểm (nghỉ lễ 2 ngày)
Sprint 24: 44 điểm (bình thường)
Sprint 25: 30 điểm (thành viên mới onboard, chưa quen codebase)]
Capacity sprint tới: 5 người, 10 ngày làm việc, không có nghỉ lễ,
không có thành viên mới.
Hãy:
1. Tính velocity điều chỉnh (loại bỏ ảnh hưởng của các sprint bất
thường, hoặc điều chỉnh theo tỷ lệ), giải thích cách tính.
2. Đề xuất khoảng scope nên cam kết cho sprint tới (story point min-max).
3. Đề xuất % buffer hợp lý nên chừa lại cho việc phát sinh.
4. Với danh sách story sau đây, đã sắp theo ưu tiên và story point,
hãy chỉ ra nên dừng cam kết ở story thứ mấy:
[PASTE DANH SÁCH STORY ĐÃ SẮP ƯU TIÊN VÀ STORY POINT]
Trả lời bằng tiếng Việt, trình bày dạng bảng nếu phù hợp.
Mẹo: Luôn hỏi AI giải thích cách nó loại trừ hoặc điều chỉnh các sprint bất thường, đừng chỉ lấy con số cuối cùng. Nếu logic điều chỉnh không hợp lý với bối cảnh team bạn (ví dụ AI loại bỏ một sprint mà bạn cho là vẫn đại diện được), hãy yêu cầu tính lại với giả định khác.
Dùng AI Để Nhận Diện Risk Và Blocker Cho Các Cam Kết Sprint Đề Xuất
Bước cuối cùng trước khi chốt sprint là rà soát xem cam kết đề xuất có blocker (điểm nghẽn) hay risk (rủi ro) tiềm ẩn nào chưa được xử lý hay không. Đây là bước "kiểm tra thực tế" cuối cùng trước khi cả team ký cam kết trước stakeholder.
Loại Risk Cần Rà Soát Trước Khi Chốt Sprint
Có ba nhóm risk phổ biến nhất ở giai đoạn này: (1) dependency bên ngoài chưa xác nhận (team khác, bên thứ ba), (2) nhiều story cùng chạm vào một module có lịch sử bug cao, gây rủi ro conflict hoặc regression, và (3) phân bổ công việc không đều — dồn quá nhiều story point vào một cá nhân trong khi người khác có capacity trống.
Các Bước Thực Hành
- Tổng hợp danh sách story đã đề xuất đưa vào sprint (kết quả bước Sprint Scope ở trên).
- Đưa vào AI cùng với thông tin về dependency đã biết, lịch sử defect của các module liên quan, và bảng phân công dự kiến theo từng thành viên.
- Yêu cầu AI rà soát ba nhóm risk đã nêu, liệt kê cụ thể theo từng story.
- Với mỗi risk/blocker phát hiện, yêu cầu đề xuất hành động giảm thiểu cụ thể (mitigation) — ai cần làm gì, trước khi nào.
- Trình bày danh sách này ngay trong buổi planning, để team quyết định có cần điều chỉnh scope hoặc phân công lại trước khi chốt cam kết cuối cùng.
- Ghi lại risk chấp nhận được (accepted risk) vào sprint notes để tránh việc "quên" và bị bất ngờ giữa sprint.
Ví Dụ Prompt
Bạn là một Scrum Master/Tech Lead đang rà soát rủi ro trước khi chốt
sprint commitment.
Danh sách story đề xuất đưa vào sprint (kèm module liên quan, người
được phân công dự kiến, story point):
[PASTE DANH SÁCH STORY + PHÂN CÔNG DỰ KIẾN]
Dependency đã biết (nếu có):
[PASTE DEPENDENCY, ví dụ: "Story A phụ thuộc API của team Platform,
dự kiến ready ngày X"]
Lịch sử defect các module liên quan trong 3 sprint gần nhất:
[PASTE LỊCH SỬ DEFECT NẾU CÓ]
Hãy rà soát và trả lời:
1. Dependency nào chưa có xác nhận rõ ràng về thời điểm sẵn sàng —
đây là blocker tiềm ẩn cần escalate trước khi sprint bắt đầu.
2. Có story nào cùng chạm vào một module rủi ro cao (nhiều bug lịch
sử) chạy song song không — nếu có, đề xuất cách giảm rủi ro conflict
(ví dụ: phân công cùng một người, hoặc tách thời điểm code).
3. Phân công có bị dồn quá tải cho một cá nhân không (so tổng story
point từng người với capacity trung bình)?
4. Với mỗi risk/blocker phát hiện, đề xuất một hành động giảm thiểu cụ
thể, có deadline rõ ràng.
Xuất kết quả dạng bảng: Risk/Blocker | Story liên quan | Mức độ nghiêm
trọng | Hành động giảm thiểu | Người phụ trách đề xuất.
Mẹo: Đưa danh sách risk này vào ngay slide/tài liệu cam kết sprint mà team ký nhận, đừng để nó chỉ nằm trong đầu Scrum Master. Việc risk được viết ra tường minh giúp cả team có trách nhiệm chung theo dõi nó, thay vì đổ lỗi cho một cá nhân khi risk xảy ra thật giữa sprint.
Những Điểm Chính Cần Nhớ
- Sprint planning tốn phần lớn thời gian vào việc chuẩn bị dữ liệu — đọc backlog, tính velocity, rà dependency — chứ không phải vào việc ra quyết định thực sự. AI rút ngắn phần chuẩn bị này để team dành thời gian cho phần cần con người: đàm phán và cam kết.
- Luôn chạy phân tích readiness của backlog trước buổi planning ít nhất 1-2 ngày, không phải ngay tại chỗ, để có thời gian xử lý câu hỏi mở.
- Sprint goal nên được đề xuất dưới dạng nhiều phương án để team thảo luận, không phải một quyết định đơn lẻ do AI hay PO áp đặt.
- Velocity là con số dao động, cần điều chỉnh theo bối cảnh từng sprint (nghỉ lễ, nhân sự thay đổi), không nên dùng trung bình cộng thô.
- Rà soát risk và blocker là bước bắt buộc trước khi chốt cam kết — dependency chưa xác nhận, module rủi ro cao bị chạm đồng thời, và phân công không đều là ba nhóm risk phổ biến nhất cần kiểm tra.
- AI luôn đóng vai trò hỗ trợ phân tích và đề xuất; quyết định cuối cùng về sprint goal, scope, và risk chấp nhận được luôn thuộc về con người trong team.