Năm bài học trước đã tách riêng từng ceremony (nghi thức Agile định kỳ) — sprint planning, backlog refinement, standup, sprint review, retrospective — để bạn hiểu sâu từng kỹ thuật dùng AI riêng lẻ. Nhưng thực tế công việc của một BA/PM/PO không diễn ra theo từng mảnh rời rạc, mà là một dòng chảy liên tục xuyên suốt hai tuần: quyết định ở sprint planning ảnh hưởng đến nội dung standup, tiến độ theo dõi ở standup quyết định câu chuyện kể ở sprint review, và phản hồi ở sprint review lại trở thành nguyên liệu cho retro. Bài thực hành này ghép toàn bộ các kỹ thuật đã học thành một chu kỳ sprint đầy đủ, theo sát một ví dụ xuyên suốt để bạn thấy rõ dữ liệu và ngữ cảnh được tái sử dụng qua từng giai đoạn như thế nào, thay vì phải bắt đầu lại từ đầu ở mỗi ceremony.
Tình huống thực hành: team "Sao Kim" gồm 5 người (1 PO, 1 Tech Lead, 3 dev) đang phát triển ứng dụng fintech "PayNow". Sprint 24 (10 ngày làm việc) có sprint goal xoay quanh tính năng "Liên Kết Ví Điện Tử Với Tài Khoản Ngân Hàng". Bạn sẽ đi qua bốn giai đoạn — lập kế hoạch, theo dõi tiến độ, chuẩn bị review/demo, và điều phối retro — với chuỗi prompt đầy đủ và ví dụ thực hành cụ thể ở mỗi bước, để có thể áp dụng ngay khuôn mẫu này vào sprint thật của team bạn.
Giai Đoạn 1: Lên Kế Hoạch Sprint — Goal, Scope, Và Phân Tích Rủi Ro
Giai đoạn lập kế hoạch là nơi toàn bộ chu kỳ sprint bắt đầu, và cũng là nơi mọi sai lệch ban đầu sẽ khuếch đại thành vấn đề lớn hơn nếu không được xử lý ngay từ đầu. Với team Sao Kim, đầu vào của giai đoạn này gồm: backlog ứng viên 14 story, roadmap quý 3 nhấn mạnh mục tiêu "tăng tỷ lệ nạp tiền qua ví điện tử lên 30%", và dữ liệu velocity 6 sprint gần nhất.
Chuỗi Prompt Lập Kế Hoạch Đầy Đủ Kèm Ví Dụ Thực Hành
Bước đầu tiên là đánh giá độ sẵn sàng của 14 story ứng viên. PO của team Sao Kim đưa toàn bộ backlog vào AI cùng Definition of Ready của team:
Bạn là Product Owner đang chuẩn bị backlog cho sprint planning của
team Sao Kim (ứng dụng fintech PayNow).
Definition of Ready của team:
- Có acceptance criteria rõ ràng, không mơ hồ.
- Story point đã được ước lượng ở buổi refine trước đó.
- Không còn câu hỏi mở về nghiệp vụ.
- Dependency (nếu có) đã được xác nhận thời điểm sẵn sàng.
Danh sách 14 story ứng viên (title, mô tả, acceptance criteria, story
point hiện tại):
[PASTE 14 STORY, bao gồm: "Liên kết tài khoản ngân hàng qua Open
Banking API" (8đ), "Xác thực OTP khi liên kết lần đầu" (5đ), "Hiển thị
số dư ví điện tử trên trang chủ" (3đ), "Rút tiền từ ví về tài khoản
ngân hàng đã liên kết" (8đ), và 10 story khác thuộc các module khác
nhau]
Hãy đánh giá từng story theo 4 tiêu chí DoR, quét dependency trong mô
tả/comment, và gắn cờ "Cần Refine Thêm" cho story có độ phức tạp mô tả
không tương xứng với story point hiện tại. Xuất bảng: Story | Ready? |
Tiêu chí thiếu | Dependency | Cần refine? | Ghi chú.
Trả lời bằng tiếng Việt, giữ nguyên thuật ngữ kỹ thuật tiếng Anh.
Kết quả AI trả về chỉ ra rằng story "Rút tiền từ ví về tài khoản ngân hàng đã liên kết" bị gắn cờ "Cần Refine Thêm" vì mô tả có nhắc đến "giới hạn rút tiền theo hạn mức KYC" nhưng acceptance criteria chưa định nghĩa rõ các mức hạn mức cụ thể — một câu hỏi mở quan trọng cần PO xác nhận với đội compliance trước khi đưa vào sprint.
Bước tiếp theo, với 12 story đã sẵn sàng, PO đưa roadmap và dữ liệu capacity vào AI để đề xuất sprint goal:
Bạn là Product Manager đang đề xuất sprint goal cho sprint 24 của team
Sao Kim.
Roadmap quý 3: Tăng tỷ lệ nạp tiền qua ví điện tử lên 30% (hiện tại
18%), thông qua việc đơn giản hóa hành trình liên kết ngân hàng và
tăng độ tin cậy của quy trình xác thực.
Backlog đã refine sẵn sàng (12 story, kèm story point):
[PASTE 12 STORY ĐÃ READY]
Capacity: 5 người, 10 ngày làm việc, velocity trung bình 6 sprint gần
nhất: 38 điểm/sprint (dao động 30-45, sprint 21 có 2 người nghỉ phép
1 tuần nên chỉ đạt 30 điểm).
Hãy đề xuất 3 phương án sprint goal, mỗi phương án gồm: câu sprint
goal ngắn gọn theo văn phong outcome, danh sách story cụ thể, tổng
story point, lý do đóng góp cho roadmap quý 3, và rủi ro chính.
Trả lời bằng tiếng Việt.
Team Sao Kim chọn phương án AI đề xuất tập trung vào toàn bộ luồng "Liên Kết Ví Điện Tử Với Tài Khoản Ngân Hàng" (4 story cốt lõi, 24 điểm) thay vì phương án dàn trải nhiều tính năng nhỏ lẻ — vì phương án này tạo ra một luồng demo hoàn chỉnh, dễ đo lường tác động đến tỷ lệ nạp tiền theo đúng roadmap.
Cuối cùng, trước khi chốt cam kết, Tech Lead đưa danh sách story đã chọn vào AI để rà soát risk và blocker:
Bạn là Tech Lead đang rà soát rủi ro trước khi chốt sprint commitment.
Story đề xuất đưa vào sprint 24 (kèm module, người phụ trách dự kiến,
story point):
- Liên kết tài khoản ngân hàng qua Open Banking API (8đ) — Dev A
- Xác thực OTP khi liên kết lần đầu (5đ) — Dev B
- Hiển thị số dư ví điện tử trên trang chủ (3đ) — Dev C
- Rút tiền từ ví về tài khoản ngân hàng đã liên kết (8đ) — Dev A
Dependency đã biết: API Open Banking phụ thuộc vào đối tác ngân hàng
XYZ, dự kiến sandbox sẵn sàng ngày thứ 2 của sprint.
Lịch sử defect: module "Xác thực/OTP" có 6 bug trong 3 sprint gần
nhất, severity trung bình Cao.
Hãy rà soát dependency chưa xác nhận, story cùng chạm module rủi ro
cao chạy song song, và phân bổ công việc không đều. Đề xuất hành động
giảm thiểu cụ thể cho từng risk.
AI chỉ ra hai điểm quan trọng: Dev A đang gánh 16/24 điểm (67% tổng scope) — rủi ro quá tải cá nhân rõ rệt; và module OTP có lịch sử bug cao nên cần thêm thời gian test thủ công dự phòng thay vì chỉ dựa vào automation hiện có. Team điều chỉnh lại bằng cách chuyển bớt một phần công việc phụ của story "Rút tiền" sang Dev C để cân bằng tải.
Các Bước Thực Hành
- Chạy đánh giá độ sẵn sàng backlog ít nhất 1-2 ngày trước buổi planning chính thức, không phải ngay tại chỗ.
- Xử lý các câu hỏi mở với các bên liên quan (ở ví dụ trên là đội compliance) trước khi story được đưa vào phương án sprint goal.
- Đề xuất 3 phương án sprint goal và mang vào phòng họp làm điểm khởi đầu thảo luận, không phải quyết định áp đặt sẵn.
- Rà soát risk/blocker cho phương án đã chọn trước khi cả team ký cam kết cuối cùng.
- Ghi lại toàn bộ: sprint goal đã chốt, danh sách story, phân công đã điều chỉnh, và risk đã chấp nhận — đây chính là dữ liệu nền cho Giai Đoạn 2.
- Lưu lại các prompt và kết quả của giai đoạn này ở một nơi truy cập được (Confluence/Notion) để tái sử dụng ngữ cảnh ở các giai đoạn sau, tránh phải giải thích lại từ đầu cho AI mỗi lần.
Mẹo: Luôn lưu lại bản ghi đầy đủ của Giai Đoạn 1 (sprint goal, story, phân công, risk đã biết) thành một "hồ sơ sprint" duy nhất. Đây chính là ngữ cảnh nền bạn sẽ dán lại vào đầu mỗi prompt ở các giai đoạn tiếp theo — tiết kiệm thời gian giải thích lại và giúp AI đưa ra phân tích nhất quán xuyên suốt cả sprint.
Giai Đoạn 2: Theo Dõi Tiến Độ Và Tạo Tóm Tắt Hằng Ngày Xuyên Suốt Sprint
Sau khi sprint 24 bắt đầu, trọng tâm chuyển từ lập kế hoạch sang theo dõi thực thi hằng ngày. Ở giai đoạn này, team Sao Kim dùng lại đúng "hồ sơ sprint" đã tạo ở Giai Đoạn 1 làm ngữ cảnh nền, kết hợp với dữ liệu Jira cập nhật mỗi ngày.
Mẫu Prompt Tóm Tắt Hằng Ngày Cho Từng Giai Đoạn Sprint
Ngày 2 của sprint, đúng như dự đoán ở Giai Đoạn 1, sandbox Open Banking API từ đối tác XYZ bị trễ. Scrum Master đưa dữ liệu Jira vào AI:
Bạn là Scrum Master đang tổng hợp tiến độ ngày 2 của sprint 24, team
Sao Kim.
Sprint goal: Liên Kết Ví Điện Tử Với Tài Khoản Ngân Hàng.
Story đang chạy: [PASTE 4 STORY + PHÂN CÔNG ĐÃ CHỐT Ở GIAI ĐOẠN 1]
Export Jira hôm nay (trạng thái, comment mới nhất):
- "Liên kết tài khoản qua Open Banking API": In Progress, comment Dev A
"Sandbox từ đối tác XYZ chưa sẵn sàng như dự kiến, đang chờ xác nhận
lại thời điểm."
- "Xác thực OTP khi liên kết lần đầu": In Progress, comment Dev B "Đã
xong luồng happy path, đang viết test case cho OTP hết hạn."
- "Hiển thị số dư ví điện tử": To Do.
- "Rút tiền từ ví về ngân hàng": To Do.
Hãy phân loại theo 3 nhóm (đúng tiến độ/có rủi ro/cần chú ý), trích
comment cảnh báo, và đối chiếu với dependency đã biết từ Giai Đoạn 1
(sandbox dự kiến sẵn sàng ngày thứ 2) để đánh giá đây có phải blocker
mới hay đã nằm trong rủi ro dự đoán trước.
Trả lời bằng tiếng Việt.
AI xác nhận đây chính là risk đã được rà soát và chấp nhận ở Giai Đoạn 1 (không phải blocker bất ngờ), nhưng đề xuất cần escalate ngay hôm nay thay vì chờ thêm, vì mỗi ngày trễ đều trực tiếp ăn vào buffer đã tính trước. Nội dung này trở thành talking point chính cho standup sáng hôm đó, được AI viết lại thành nhóm "Cần quyết định ngay" kèm câu hỏi gợi ý: "Có nên bắt đầu song song một luồng test bằng mock data trong lúc chờ sandbox thật, để không chặn toàn bộ tiến độ của Dev A?"
Đến ngày 6, Scrum Master chạy phân tích xu hướng bằng cách gộp dữ liệu 6 ngày liên tiếp:
Dưới đây là tóm tắt tiến độ từ ngày 1 đến ngày 6 của sprint 24 (đã lưu
mỗi ngày từ các buổi standup):
[PASTE CHUỖI 6 NGÀY TÓM TẮT]
Kế hoạch burndown lý tưởng: 10% story point mỗi ngày trong 10 ngày.
Hãy phân tích scope creep, sụt giảm velocity so với đường lý tưởng, và
mẫu hình blocker lặp lại. Đối chiếu với risk đã biết từ đầu sprint
(sandbox trễ, module OTP có lịch sử bug cao) để phân biệt rủi ro đã
dự đoán với rủi ro mới phát sinh.
Kết quả cho thấy sprint đang chậm khoảng 12% so với burndown lý tưởng — chủ yếu do 2 ngày trễ sandbox ở đầu sprint — nhưng tốc độ những ngày gần đây đã bắt kịp trở lại sau khi Dev A chuyển sang test với mock data. AI đề xuất không cần cắt giảm scope, chỉ cần theo dõi thêm 1-2 ngày nữa.
Các Bước Thực Hành
- Mỗi sáng, đưa export Jira/Linear kèm "hồ sơ sprint" từ Giai Đoạn 1 vào AI để tóm tắt và tạo talking points cho standup.
- Luôn đối chiếu blocker mới phát hiện với risk đã được rà soát trước đó — phân biệt rõ "rủi ro đã dự đoán, đang diễn ra đúng kịch bản" với "rủi ro hoàn toàn mới, chưa từng lường trước".
- Lưu lại bản tóm tắt mỗi ngày thành chuỗi dữ liệu liên tục, không xóa sau khi standup kết thúc.
- Định kỳ 3-4 ngày một lần, gộp chuỗi dữ liệu để phân tích xu hướng scope creep, velocity, và mẫu blocker.
- Với mọi phát hiện rủi ro nghiêm trọng, trao đổi trực tiếp với PO/Tech Lead ngay trong ngày, không đợi đến standup hôm sau.
- Chuẩn bị sẵn bản báo cáo rút gọn cho stakeholder không tham gia standup hằng ngày, cập nhật 2-3 lần mỗi tuần.
Mẹo: Khi một blocker đã được dự đoán trước ở Giai Đoạn 1 thực sự xảy ra, đừng coi đó là "chuyện bình thường, đã lường trước rồi nên không cần lo". Việc risk xảy ra đúng như dự đoán vẫn cần hành động ngay lập tức để giảm tác động — dự đoán đúng risk chỉ có giá trị nếu nó dẫn tới hành động kịp thời, không phải chỉ để "biết trước cho vui".
Giai Đoạn 3: Chuẩn Bị Tài Liệu Sprint Review Và Demo Với AI
Đến ngày 9 của sprint, cả 4 story đều đã chuyển sang trạng thái Done sau khi team xử lý xong độ trễ ban đầu bằng buffer đã chừa sẵn. Giờ là lúc chuyển trọng tâm sang chuẩn bị kể câu chuyện sprint cho stakeholder.
Quy Trình Đầy Đủ Chuẩn Bị Review Và Demo Prep
PO tổng hợp toàn bộ dữ liệu — sprint goal ban đầu, 4 story đã hoàn thành, và cả câu chuyện về độ trễ sandbox đã được xử lý — để xây dựng câu chuyện review:
Bạn là Product Manager chuẩn bị câu chuyện cho sprint review sprint 24
của team Sao Kim.
Sprint goal ban đầu: Liên Kết Ví Điện Tử Với Tài Khoản Ngân Hàng, đóng
góp mục tiêu quý 3 tăng tỷ lệ nạp tiền qua ví điện tử từ 18% lên 30%.
Story đã hoàn thành: Liên kết tài khoản qua Open Banking API, Xác thực
OTP khi liên kết lần đầu, Hiển thị số dư ví điện tử trên trang chủ,
Rút tiền từ ví về tài khoản ngân hàng đã liên kết.
Bối cảnh thực thi: sprint có độ trễ 2 ngày do sandbox đối tác ngân
hàng XYZ chậm hơn dự kiến, team xử lý bằng cách test song song với
mock data, cuối cùng bắt kịp tiến độ và hoàn thành đúng cam kết.
Hãy viết đoạn mở đầu đối chiếu goal với kết quả, nhóm 4 story theo chủ
đề giá trị "hành trình liên kết ví điện tử liền mạch", và một đoạn kết
nối tới sprint tiếp theo (dự kiến mở rộng thêm đối tác ngân hàng thứ 2).
Trả lời bằng tiếng Việt, giọng văn tự tin nhưng trung thực.
Tiếp theo, PO đưa acceptance criteria của luồng "Liên kết ví điện tử" vào AI để soạn kịch bản demo theo hành trình người dùng — từ màn hình chọn ngân hàng, nhập OTP xác thực, đến màn hình số dư cập nhật và thử rút tiền về tài khoản đã liên kết, kèm câu hỏi dự đoán từ ban lãnh đạo như "Nếu ngân hàng đối tác gặp sự cố thì trải nghiệm người dùng sẽ ra sao?" — một câu hỏi AI dự đoán được chính từ bối cảnh trễ sandbox đã xảy ra trong sprint.
Cuối cùng, PO tạo 3 phiên bản release notes (khách hàng cuối, team support, ban lãnh đạo) cho tính năng vừa hoàn thành, đưa cho team support ít nhất nửa ngày trước khi công bố chính thức để họ kịp chuẩn bị trả lời câu hỏi khách hàng về hạn mức rút tiền và các ngân hàng được hỗ trợ.
Các Bước Thực Hành
- Tổng hợp toàn bộ dữ liệu từ Giai Đoạn 1 và 2 (goal, story hoàn thành, bối cảnh thực thi kể cả khó khăn đã vượt qua) làm input cho câu chuyện review.
- Đừng che giấu khó khăn đã gặp — kể cả câu chuyện xử lý độ trễ sandbox, vì nó thể hiện năng lực thích ứng của team, không chỉ là kết quả cuối cùng.
- Soạn kịch bản demo theo hành trình người dùng thực tế, diễn tập ít nhất một lần trước buổi review chính thức.
- Chuẩn bị trước câu trả lời cho câu hỏi có khả năng được hỏi, dựa trên chính những rủi ro đã biết trong sprint.
- Soạn và gửi release notes cho team support trước khi công bố ra bên ngoài.
- Chuẩn bị sẵn phương án dự phòng (screenshot/video quay sẵn) nếu demo trực tiếp gặp sự cố kỹ thuật.
Mẹo: Dùng chính câu chuyện "vượt qua khó khăn" (độ trễ sandbox) làm điểm nhấn tích cực trong sprint review, thay vì chỉ nhắc tới khi bị hỏi. Stakeholder tin tưởng một team biết xử lý vấn đề tốt hơn nhiều so với một team chỉ báo cáo mọi thứ đều suôn sẻ tuyệt đối — vì thực tế không ai tin sprint nào cũng hoàn hảo 100%.
Giai Đoạn 4: Điều Phối Retrospective Và Tạo Action Cải Tiến
Sprint 24 kết thúc thành công, nhưng câu chuyện chưa dừng lại ở đó. Retro là nơi team Sao Kim nhìn lại không chỉ kết quả, mà cả quy trình đã dẫn đến kết quả đó — đặc biệt là bài học từ việc phụ thuộc vào sandbox đối tác bên ngoài.
Hướng Dẫn Điều Phối Retro Và Tạo Action Item
Scrum Master đưa bối cảnh sprint vào AI để chọn định dạng retro phù hợp:
Bạn là Agile Coach facilitate retro sprint 24 của team Sao Kim.
Bối cảnh: Sprint đạt goal, nhưng có độ trễ 2 ngày do phụ thuộc sandbox
đối tác ngân hàng ngoài tầm kiểm soát team. Team xử lý tốt bằng cách
chuyển sang test với mock data. Không có sự cố production. Không khí
team tích cực sau khi hoàn thành đúng cam kết.
Lịch sử: đây là sprint thứ 2 liên tiếp có story phụ thuộc đối tác bên
ngoài bị trễ tiến độ (sprint 22 cũng từng bị trễ vì đối tác SMS OTP).
Hãy đề xuất định dạng retro phù hợp, soạn 5-6 câu hỏi gợi mở tập trung
vào chủ đề "làm việc với dependency bên ngoài không kiểm soát được",
và hướng dẫn điều phối 60 phút.
AI đề xuất định dạng 4Ls (Liked/Learned/Lacked/Longed for) kết hợp một phần đào sâu riêng cho chủ đề dependency lặp lại, với câu hỏi trọng tâm như "Nếu biết trước sandbox sẽ trễ, team có thể chuẩn bị phương án dự phòng sớm hơn ở bước nào của sprint planning?".
Sau buổi retro, các đề xuất được ghi lại nguyên văn và đưa vào AI để chuyển hóa thành action item SMART:
Bạn là Scrum Master chuyển đề xuất retro thành action item.
Đề xuất nguyên văn từ retro:
- "Nên có phương án dự phòng (mock data) chuẩn bị sẵn ngay từ đầu
sprint cho mọi story phụ thuộc đối tác bên ngoài, không đợi đến khi
bị trễ mới nghĩ ra."
- "Cần một danh sách theo dõi tất cả dependency bên ngoài của cả team,
không chỉ nhớ trong đầu từng người."
Đây là lần thứ 2 liên tiếp team gặp vấn đề dependency bên ngoài (sprint
22 và 24). Hãy chuyển thành action item SMART, gợi ý người phụ trách,
thời hạn, và một chỉ số đo lường để theo dõi hiệu quả action item này
qua các sprint tiếp theo.
AI đề xuất action item cụ thể: Tech Lead xây dựng "Bảng Theo Dõi Dependency Bên Ngoài" trên Confluence trước sprint 25, cập nhật bắt buộc ở mỗi buổi refine, kèm chỉ số đo lường "số ngày trễ do dependency bên ngoài mỗi sprint" để đối chiếu xu hướng cải thiện trong các quý tiếp theo — chính là chỉ số sẽ được đưa vào phân tích xu hướng cải tiến định kỳ như đã học ở bài trước.
Các Bước Thực Hành
- Đưa bối cảnh sprint (bao gồm cả tín hiệu lặp lại từ các sprint trước, nếu có) vào AI để chọn định dạng và câu hỏi retro phù hợp.
- Dành thời gian riêng cho chủ đề đã lặp lại nhiều lần (ở đây là dependency bên ngoài), không để nó chìm lẫn trong phần thảo luận chung.
- Ghi lại nguyên văn đề xuất trong buổi họp, chuyển hóa thành action item SMART ngay sau đó.
- Gán chỉ số đo lường cụ thể cho action item để có thể đối chiếu hiệu quả ở các quý tiếp theo.
- Đưa action item vào Jira/Confluence với người phụ trách và deadline rõ ràng, không để nó chỉ tồn tại trong ghi chú Miro.
- Mở đầu retro sprint 25 bằng việc review lại action item này, khép kín vòng lặp cải tiến liên tục.
Mẹo: Khi một vấn đề tái diễn lần thứ hai (như dependency bên ngoài ở sprint 22 và 24), đó là tín hiệu đủ mạnh để đầu tư một action item mang tính hệ thống (một bảng theo dõi dùng chung), thay vì tiếp tục xử lý từng lần bằng phản ứng tình huống riêng lẻ. Đây chính là khoảnh khắc retro tạo ra giá trị vượt xa một sprint đơn lẻ.
Những Điểm Chính Cần Nhớ
- Một chu kỳ sprint đầy đủ là dòng chảy liên tục, không phải các ceremony rời rạc — dữ liệu và ngữ cảnh từ Giai Đoạn 1 (sprint goal, risk đã biết) nên được tái sử dụng xuyên suốt các giai đoạn sau.
- Lưu lại "hồ sơ sprint" ngay sau khi lập kế hoạch giúp AI đưa ra phân tích nhất quán và tiết kiệm thời gian giải thích lại ngữ cảnh ở mỗi giai đoạn tiếp theo.
- Rủi ro đã dự đoán trước vẫn cần hành động ngay khi nó xảy ra thật — dự đoán đúng chỉ có giá trị nếu dẫn đến hành động kịp thời trong lúc theo dõi tiến độ.
- Câu chuyện sprint review nên bao gồm cả khó khăn đã vượt qua, không chỉ kết quả cuối cùng — điều này xây dựng niềm tin với stakeholder tốt hơn một báo cáo hoàn hảo giả tạo.
- Vấn đề lặp lại qua nhiều sprint (như dependency bên ngoài) là tín hiệu cần action item mang tính hệ thống ở retro, không chỉ xử lý tình huống đơn lẻ mỗi lần nó xảy ra.
- Xuyên suốt cả bốn giai đoạn, AI đảm nhận phần chuẩn bị, tổng hợp, và phân tích tốn thời gian; con người trong team luôn giữ vai trò quyết định cuối cùng, xác nhận domain knowledge, và chịu trách nhiệm với cam kết đã đưa ra.