Bài 7 — Trợ lý PO trong một sprint thực tế: tình huống đầu-cuối

Vấn đề

Lý thuyết là một chuyện, dùng được trong nhịp sprint là chuyện khác. Bài này đi qua một sprint 2 tuần điển hình và chỉ ra chính xác lúc nào gọi trợ lý PO, prompt gì, và khi nào phải tự tay làm. Mục tiêu: bạn có một kịch bản áp dụng được ngay tuần sau.

Kịch bản sprint 2 tuần với Trợ lý PO

Trước sprint (chuẩn bị backlog):

• Trợ lý quét backlog, báo story chưa sẵn sàng (Bài 5).
• PO viết story mới với AI (Bài 2), tách epic mới (Bài 3).

• Trợ lý soạn tóm tắt các story ứng viên + câu hỏi mở.
• PO quyết định sprint scope — KHÔNG giao cho agent.

• Trợ lý báo ticket đứng yên, story thiếu thông tin.
• Khi dev hỏi, PO dùng AI viết nhanh AC bổ sung, dry-run cập nhật Jira (Bài 4).

• Trợ lý soạn agenda và câu hỏi cần chốt.

• Trợ lý tóm tắt tiến độ cho stakeholder.

Prompt mẫu: tóm tắt tiến độ sprint cho stakeholder

[Dùng hiến pháp Trợ lý PO]
Dữ liệu sprint (tôi dán từ Jira): <danh sách ticket + trạng thái>.
Viết bản tóm tắt tiến độ cho stakeholder không rành kỹ thuật, gồm:
1) Kết quả đã giao (giá trị người dùng, không liệt kê mã ticket)
2) Đang làm dở và lý do
3) Rủi ro/blocker cần hỗ trợ
4) Dự kiến sprint tới (1-2 dòng)
Giọng tích cực nhưng trung thực, không thổi phồng, không bịa con số ngoài dữ liệu tôi đưa.

Prompt mẫu: xử lý thay đổi giữa sprint

[Dùng hiến pháp Trợ lý PO]
Stakeholder yêu cầu thêm yêu cầu X vào giữa sprint đang chạy.
Giúp tôi: (1) diễn giải X thành story + AC nháp; (2) phân tích tác động lên sprint hiện tại;
(3) đề xuất 2 phương án (đưa vào sprint sau / đánh đổi story nào).
Đừng tự quyết đưa vào sprint — đó là việc của tôi.

Các bước áp dụng cho sprint tới

• Đặt lịch trợ lý quét backlog vào sáng trước ngày planning.
• Chuẩn bị sẵn hiến pháp Trợ lý PO (Bài 6) để mọi prompt nhất quán.
• Ở planning, dùng tóm tắt của trợ lý làm đầu vào, tự quyết scope.
• Trong sprint, mọi cập nhật Jira của agent đều qua dry-run.
• Trước refinement, để trợ lý soạn agenda; bạn rà lại 5 phút.
• Cuối sprint, dùng prompt tóm tắt để viết báo cáo stakeholder, kiểm số liệu trước khi gửi.

Checklist: Nhịp dùng Trợ lý PO trong sprint

[ ] Trước planning: quét backlog + báo story chưa sẵn sàng
[ ] Planning: trợ lý tóm tắt, PO quyết scope
[ ] Hằng ngày: báo ticket đứng yên / thiếu thông tin
[ ] Giữa sprint: phân tích tác động thay đổi, PO quyết
[ ] Trước refinement: soạn agenda + câu hỏi chốt
[ ] Cuối sprint: tóm tắt stakeholder (đã kiểm số liệu)
[ ] Mọi cập nhật Jira: qua dry-run

Sai lầm thường gặp

• Để agent quyết sprint scope: Ép story vào sprint là quyết định đánh đổi kinh doanh, không phải việc của agent. Trợ lý cung cấp thông tin, PO quyết.
• Ảo giác trong báo cáo stakeholder: Nguy hiểm nhất — AI "làm đẹp" con số hoặc bịa velocity. Luôn kiểm mọi số liệu với Jira trước khi gửi cấp trên.
• Rò rỉ dữ liệu ra ngoài: Báo cáo stakeholder có thể chứa tên tính năng chưa công bố, thông tin đối thủ. Cân nhắc ai nhận và kênh gửi.
• Phụ thuộc quá mức khi có thay đổi gấp: Lúc áp lực, dễ để agent "tự lo". Đây chính là lúc cần con người nhất — thay đổi giữa sprint là quyết định đánh đổi.
• Giọng điệu thổi phồng: AI hay lạc quan quá. Buộc trợ lý "trung thực, không thổi phồng", nếu không stakeholder mất niềm tin khi thực tế khác báo cáo.

Chốt bài

Bạn đã có kịch bản dùng Trợ lý PO xuyên suốt một sprint, với ranh giới rõ ở mỗi bước. Bài 8 sẽ khép lại: vận hành lâu dài, đo hiệu quả, và quản trị rủi ro cho trợ lý của bạn.