Tiếng Việt: Agentic Planning

9 giờ tối thứ Năm, deadline quý mới còn 3 ngày. Bạn đang nhìn vào một file Google Doc tên "Q3 Roadmap — FINAL v4" mà bạn biết chắc sẽ phải đổi tên thành "v5" ngay sau buổi review sáng mai, vì hai insight mới từ discovery interview tuần này chưa kịp đưa vào. Bên cạnh đó là một backlog Jira với 47 items chưa được refine, phần lớn chỉ có title một dòng, không có acceptance criteria, không có story point. Sprint planning là thứ Hai. Bạn biết team sẽ ngồi cả buổi sáng để "làm rõ" từng ticket — một nghi thức quen thuộc mà ai cũng ghét nhưng không ai tìm được cách thoát.

Đây chính là khoảng trống mà agentic planning được sinh ra để lấp: dùng AI agent để tự động chuyển hoá các cơ hội đã được ưu tiên hoá từ giai đoạn discovery (topic 02) thành cập nhật roadmap, rồi từ roadmap theme thành backlog sprint-ready — nhưng không bao giờ để AI tự ý commit nguồn lực engineering mà không qua một cổng phê duyệt (approval gate) của con người. Đây là giai đoạn "Define/Plan" trong vòng lặp Agentic PM Loop (Discover → Define/Plan → Deliver → Measure), và nó nguy hiểm hơn giai đoạn discovery ở một điểm mấu chốt: mọi quyết định ở đây đều trực tiếp cam kết capacity của team kỹ thuật. Một roadmap sai, một backlog thiếu acceptance criteria rõ ràng, một priority không update kịp — chi phí không dừng ở việc mất thời gian đọc lại, mà là hàng tuần sprint bị lãng phí. Bài này sẽ đi sâu vào bốn năng lực cốt lõi: chain hoá cơ hội discovery thành roadmap, sinh backlog sprint-ready từ roadmap theme, thiết lập cổng review/approval trước khi commit, và điều chỉnh kế hoạch real-time khi bối cảnh thay đổi.

Cách Chain Hoá Các Cơ Hội Đã Ưu Tiên Thành Cập Nhật Roadmap Bằng AI

Ở topic 02, bạn đã có một danh sách các cơ hội (opportunities) được AI hỗ trợ phân tích, gom cụm theo theme và xếp hạng theo RICE hoặc ICE score. Vấn đề của phần lớn PM không nằm ở việc thiếu dữ liệu ưu tiên — nó nằm ở khoảng cách giữa "tôi có một danh sách opportunity đã ranked" và "roadmap quý sau của tôi đã được cập nhật, đúng format, đúng ngôn ngữ cho stakeholder, và không mâu thuẫn với những gì đã cam kết trước đó". Đây chính là chỗ prompt chaining (chuỗi prompt nối tiếp, đầu ra của bước này là đầu vào của bước sau) phát huy giá trị: bạn không hỏi AI một câu duy nhất "hãy làm roadmap cho tôi", mà xây một pipeline gồm nhiều bước nhỏ, mỗi bước có input/output rõ ràng, có thể review độc lập.

Về bản chất, agent orchestration (điều phối nhiều agent/bước xử lý) cho roadmap update gồm 4 bước nối tiếp: (1) đối chiếu opportunity mới với roadmap hiện tại để tìm chồng lấn hoặc mâu thuẫn, (2) đề xuất vị trí mỗi opportunity nên nằm ở quý nào dựa trên effort/impact và dependency, (3) soạn draft update roadmap theo đúng format công ty (theme, outcome, không phải feature list), (4) sinh bản tóm tắt thay đổi (changelog) để bạn present cho stakeholder. Việc chia nhỏ như vậy giúp bạn kiểm tra được lỗi logic ở từng bước thay vì phải soi một bản roadmap hoàn chỉnh do AI tự "bịa" toàn bộ.

Các Bước Thực Hành

1. Tập hợp input: Export danh sách opportunity đã ranked từ topic 02 (dạng bảng: tên opportunity, RICE score, effort ước lượng, theme liên quan) và export roadmap hiện tại từ Aha! hoặc Productboard (dạng: theme, initiative, quý dự kiến, trạng thái).
2. Bước 1 — Đối chiếu: Đưa cả hai file vào Claude hoặc ChatGPT, yêu cầu liệt kê opportunity nào đã có initiative tương ứng trên roadmap (tránh trùng lặp), opportunity nào hoàn toàn mới, và opportunity nào mâu thuẫn trực tiếp với initiative đang chạy (ví dụ: một feature đang phát triển nhưng discovery mới cho thấy user không cần nữa).
3. Bước 2 — Đề xuất vị trí quý: Với danh sách opportunity mới/chưa xếp, yêu cầu AI đề xuất quý phù hợp dựa trên: effort ước lượng so với capacity còn lại của quý đó, dependency kỹ thuật (nếu bạn cung cấp), và mức độ khẩn cấp theo RICE score.
4. Bước 3 — Soạn draft roadmap: Yêu cầu AI viết lại theo đúng template roadmap công ty bạn (copy 1 initiative mẫu cũ vào prompt làm ví dụ format), đảm bảo mỗi initiative có: tên theo outcome (không phải tên feature), 1 câu "vì sao" nối lại với opportunity gốc, quý dự kiến, mức độ tin cậy (confidence: High/Medium/Low).
5. Bước 4 — Sinh changelog: Yêu cầu AI tóm tắt "cái gì thay đổi so với version trước" thành 5-7 bullet points, dùng ngôn ngữ dành cho stakeholder không kỹ thuật, kèm lý do dựa trên dữ liệu discovery.
6. Đóng pipeline bằng n8n/Zapier nếu cần lặp lại hàng tuần: Nếu team bạn review roadmap hàng tuần hoặc hàng sprint, có thể tự động hoá 4 bước trên bằng n8n hoặc Make — trigger khi có opportunity mới trong Productboard, chain qua API của Claude/ChatGPT để chạy 4 bước, output ra draft trong Notion AI hoặc Confluence chờ bạn review. Nhưng luôn dừng ở bước "draft chờ duyệt" — không bao giờ để workflow tự động publish thẳng lên roadmap live.

Ví Dụ Prompt

Bạn là trợ lý Product Manager giúp tôi cập nhật roadmap quý.

INPUT 1 - Danh sách opportunity đã ưu tiên (từ discovery):
[dán bảng: tên opportunity | RICE score | effort ước lượng (S/M/L) | theme liên quan | insight nguồn]

INPUT 2 - Roadmap hiện tại:
[dán bảng: theme | initiative | quý | trạng thái (đang chạy/đã lên kế hoạch/chưa bắt đầu)]

Nhiệm vụ (làm từng bước, KHÔNG gộp lại):
Bước 1: Với mỗi opportunity ở Input 1, xác định:
- Đã có initiative tương ứng trên roadmap chưa? Nếu có, ghi rõ initiative nào.
- Có mâu thuẫn với initiative đang chạy không? Giải thích cụ thể mâu thuẫn là gì.
- Là cơ hội hoàn toàn mới, chưa có trên roadmap?

Chỉ trả lời Bước 1 trước, đợi tôi xác nhận rồi mới sang Bước 2.
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 kết quả Bước 1 đã xác nhận, hãy thực hiện Bước 2:

Với các opportunity mới (chưa có trên roadmap), đề xuất quý phù hợp (Q3, Q4, hoặc "Chưa xếp lịch") dựa trên:
- Effort ước lượng: [dán capacity còn lại mỗi quý, ví dụ Q3 còn 2 team-sprint, Q4 còn 6 team-sprint]
- Mức độ khẩn cấp theo RICE score (score càng cao, ưu tiên xếp sớm)
- Dependency kỹ thuật nếu có: [liệt kê nếu có, ví dụ "cần xong migration X trước"]

Với mỗi đề xuất, giải thích lý do trong 1 câu và nêu rõ mức độ tự tin (confidence: High/Medium/Low).
Trả lời bằng tiếng Việt, giữ nguyên thuật ngữ kỹ thuật tiếng Anh.

Mẹo: Đừng bao giờ để AI chain cả 4 bước trong một prompt duy nhất rồi copy-paste thẳng ra roadmap live. Luôn approve từng bước — đặc biệt là Bước 1 (đối chiếu mâu thuẫn), vì đây là chỗ AI dễ bỏ sót nhất một initiative đang chạy dở mà bạn quên đưa vào input.

Cách AI Sinh Backlog Sprint-Ready Từ Roadmap Theme

Có một khoảng cách kinh điển giữa roadmap và backlog: roadmap nói "Quý này chúng ta tập trung vào giảm friction ở bước onboarding", còn backlog cần "Là một user mới, tôi muốn thấy checklist 3 bước để hoàn tất setup tài khoản, để tôi biết mình đã sẵn sàng dùng sản phẩm chưa". Việc "dịch" từ theme trừu tượng sang epic, rồi từ epic sang user story có acceptance criteria cụ thể, đo lường được, là công việc tốn nhiều giờ refinement nhất trong lịch một PM. Đây chính là nơi AI tạo giá trị rõ ràng nhất trong toàn bộ vòng lặp agentic planning: nó không thay thế tư duy phân rã của bạn, nhưng nó rút ngắn thời gian từ "tôi có ý tưởng theme" xuống "tôi có một backlog nháp để review" từ vài giờ xuống vài chục phút.

Cấu trúc phân rã chuẩn là: Theme (roadmap) → Epic (mục tiêu lớn, kéo dài nhiều sprint) → User Story (đơn vị công việc có thể hoàn thành trong 1 sprint) → Acceptance Criteria (điều kiện để coi story đó là "done"). AI làm tốt việc sinh ra khung phân rã này khi bạn cho nó đủ ngữ cảnh: ai là user, họ đang gặp pain gì (lấy từ insight discovery), và constraint kỹ thuật nào cần tôn trọng. Nhưng AI dễ sai ở chỗ: acceptance criteria mơ hồ ("hệ thống phải nhanh và dễ dùng") hoặc story quá to để nhét vừa 1 sprint (thường AI có xu hướng viết epic-sized story mà gắn nhãn "story"). Vai trò của bạn là kiểm tra kỹ hai điểm này trước khi đưa vào Jira hoặc Linear.

Các Bước Thực Hành

1. Chuẩn bị context cho AI: Với mỗi theme roadmap, tập hợp: 2-3 insight discovery gốc liên quan (trích dẫn nguyên văn từ user interview nếu có), mọi constraint kỹ thuật đã biết (API giới hạn, hệ thống legacy cần tương thích), và định nghĩa "Definition of Ready" của team bạn.
2. Yêu cầu AI phân rã Theme → Epic: Cho AI 1 theme, yêu cầu đề xuất 2-4 epic khả thi, mỗi epic có outcome đo lường được (không phải chỉ tên tính năng).
3. Yêu cầu AI phân rã Epic → User Story: Với mỗi epic được chọn, yêu cầu AI viết 5-8 user story theo format chuẩn "Là [persona], tôi muốn [hành động], để [giá trị]", ước lượng kích cỡ tương đối (S/M/L) cho mỗi story.
4. Yêu cầu AI viết Acceptance Criteria: Với mỗi story, yêu cầu 3-5 acceptance criteria dạng Given/When/Then hoặc checklist, đảm bảo có ít nhất 1 tiêu chí đo lường được bằng số (thời gian phản hồi, tỷ lệ %, số bước thao tác).
5. Review và cắt gọt trước khi đẩy vào Jira/Linear: Đọc lại toàn bộ, gạch bỏ story nào quá to (cần tách thêm) hoặc acceptance criteria nào mơ hồ. Sau đó dùng tính năng import CSV/API của Jira hoặc Linear để đẩy hàng loạt, tiết kiệm thao tác nhập tay.
6. Đối chiếu ngược với capacity: Cộng tổng story point ước lượng, so với velocity trung bình 3 sprint gần nhất của team — nếu backlog AI sinh vượt quá capacity 1 sprint, yêu cầu AI đề xuất cắt giảm scope theo nguyên tắc MoSCoW (Must/Should/Could/Won't).

Ví Dụ Prompt

Bạn là Business Analyst giúp tôi phân rã roadmap theme thành backlog sprint-ready.

THEME: "Giảm friction onboarding cho user mới"

Bối cảnh (từ discovery):
- Insight 1: "Tôi không biết mình đã setup xong chưa, cứ phải hỏi lại đồng nghiệp" (7/12 user phỏng vấn nhắc đến)
- Insight 2: Tỷ lệ drop-off ở bước xác thực email là 34%
Constraint kỹ thuật: Hệ thống auth hiện dùng Auth0, không đổi trong quý này.
Persona chính: "Người mới dùng lần đầu, không rành công nghệ"

Nhiệm vụ:
1. Đề xuất 2-3 epic khả thi cho theme này, mỗi epic có outcome đo lường được.
2. Với epic được tôi chọn (tôi sẽ xác nhận sau bước 1), viết 5-8 user story theo format "Là [persona], tôi muốn [hành động], để [giá trị]", kèm ước lượng size (S/M/L).

Chỉ làm bước 1 trước, đợi tôi chọn epic rồi mới làm bước 2.
Trả lời bằng tiếng Việt, giữ nguyên thuật ngữ kỹ thuật tiếng Anh.

Với user story sau: "Là user mới, tôi muốn thấy checklist 3 bước để hoàn tất setup tài khoản, để tôi biết mình đã sẵn sàng dùng sản phẩm chưa"

Hãy viết 3-5 acceptance criteria theo format Given/When/Then. Yêu cầu bắt buộc:
- Ít nhất 1 tiêu chí đo lường được bằng số cụ thể (thời gian, %, số bước)
- Không dùng từ mơ hồ như "nhanh", "dễ dùng", "thân thiện" mà không kèm định nghĩa số liệu
- Xét cả trường hợp lỗi (edge case): user bỏ dở giữa chừng, mất kết nối mạng

Trả lời bằng tiếng Việt, giữ nguyên thuật ngữ kỹ thuật tiếng Anh.

Mẹo: Luôn yêu cầu AI ước lượng size trước khi bạn convert story thành ticket thật trong Jira/Linear — nếu tổng story point vượt capacity sprint, tốt hơn nên cắt scope ngay từ bước backlog nháp, thay vì để cả team phát hiện ra giữa sprint đang chạy.

Cách Review Và Phê Duyệt Kế Hoạch AI Sinh Ra Trước Khi Commit Vào Delivery

Đây là phần quan trọng nhất của toàn bộ topic này, và cũng là ranh giới rõ ràng nhất giữa "dùng AI để tăng tốc" và "dùng AI một cách liều lĩnh". Khác với giai đoạn discovery — nơi một insight sai chỉ khiến bạn lãng phí thời gian đọc lại — ở giai đoạn planning, một roadmap sai hoặc một backlog thiếu chính xác sẽ trực tiếp commit capacity engineering thật, tiền lương thật, và cơ hội thật (nếu team làm sai thứ, họ không có thời gian làm đúng thứ). Vì vậy, human-in-the-loop (con người tham gia vào vòng lặp quyết định) không phải là bước tuỳ chọn — nó là go/no-go checkpoint (điểm chốt quyết định đi tiếp hay dừng) bắt buộc trước khi bất kỳ output nào của AI được đưa vào sprint commit.

Một sai lầm phổ biến là coi review của con người chỉ là "đọc lướt qua rồi bấm approve". Để review thật sự có giá trị, bạn cần một checklist go/no-go rõ ràng, áp dụng nhất quán, không phụ thuộc vào tâm trạng ngày hôm đó của PM. Checklist này nên được lưu trong Confluence hoặc Notion AI như một template dùng lại được cho mỗi chu kỳ planning.

Các Bước Thực Hành

1. Không bao giờ tự động publish: Cấu hình mọi workflow tự động hoá (n8n, Zapier, Make) để output luôn dừng ở trạng thái "Draft" hoặc "Pending Review" trong Jira/Aha!/Productboard — không bao giờ set trạng thái "Committed" hoặc "In Sprint" tự động.
2. Chạy checklist go/no-go trước cuộc họp planning: Dùng bảng checklist ở trên, tự bạn (PM) đánh giá trước, đánh dấu rõ mục nào "Go", mục nào "Cần làm rõ thêm".
3. Yêu cầu AI tự nêu rủi ro của chính nó: Sau khi AI sinh roadmap/backlog, hỏi ngược lại AI: "Trong bản đề xuất này, phần nào bạn ít tự tin nhất, và vì sao?" — kỹ thuật này (self-critique prompt) thường lộ ra chỗ AI đang suy diễn thiếu căn cứ.
4. Đưa cho stakeholder liên quan review song song: Gửi bản draft cho Tech Lead, Design Lead, và (nếu cần) Sales/CS để mỗi bên xác nhận phần thuộc trách nhiệm của họ trong checklist, không chỉ để PM tự quyết một mình.
5. Tổ chức buổi go/no-go ngắn: 30 phút, chỉ để đi qua các mục "Cần làm rõ" còn lại, quyết định: Go (đưa vào sprint), No-go (trả về cho AI + con người điều chỉnh lại), hoặc Parking lot (chưa đủ thông tin, để quý sau).
6. Ghi lại quyết định và lý do: Lưu biên bản go/no-go vào Confluence, gắn link tới bản draft AI gốc — đây là tài sản quan trọng để audit lại sau này nếu roadmap phải thay đổi giữa chừng.

Ví Dụ Prompt

Đây là bản roadmap update và backlog draft tôi vừa nhờ bạn sinh ra ở các bước trước.

Bây giờ hãy đóng vai một reviewer khó tính. Với từng initiative/story, hãy tự đánh giá:
1. Phần nào trong đề xuất này bạn dựa trên dữ liệu discovery thực tế, và phần nào bạn tự suy diễn/giả định?
2. Có initiative/story nào bạn không chắc chắn về effort ước lượng không? Vì sao?
3. Nếu phải chọn 1 điều rủi ro nhất trong toàn bộ bản đề xuất này để con người kiểm tra kỹ trước khi duyệt, đó là gì?

Trả lời thẳng thắn, không tô hồng, liệt kê theo mức độ rủi ro giảm dần.
Trả lời bằng tiếng Việt, giữ nguyên thuật ngữ kỹ thuật tiếng Anh.

Tôi sẽ dán checklist go/no-go của team. Hãy đối chiếu bản roadmap/backlog draft ở trên với từng mục checklist, đánh dấu PASS/FAIL/CẦN LÀM RÕ cho từng mục, và giải thích ngắn gọn lý do:

[dán checklist: nguồn gốc dữ liệu, tính khả thi kỹ thuật, xung đột roadmap, acceptance criteria, capacity, rủi ro pháp lý/bảo mật]

Trả lời bằng tiếng Việt, giữ nguyên thuật ngữ kỹ thuật tiếng Anh.

Mẹo: Yêu cầu AI tự phê bình đề xuất của chính nó (self-critique) trước khi bạn review — đây là cách rẻ nhất để lộ ra chỗ AI đang "tự tin quá mức" vào một giả định không có dữ liệu, giúp buổi go/no-go của team đi thẳng vào trọng tâm thay vì rà soát lại từ đầu.

Cách Điều Chỉnh Kế Hoạch Real-Time Khi Bối Cảnh Thay Đổi Bằng AI

Roadmap và backlog không bao giờ đứng yên. Một dependency bị block giữa sprint (API bên thứ ba đổi điều khoản, team platform trễ tiến độ), một insight mới xuất hiện từ một cuộc phỏng vấn khách hàng tuần này, hoặc một chỉ đạo ưu tiên đột ngột từ leadership — tất cả đều buộc bạn phải re-plan giữa chừng. Vấn đề không phải là "có nên thay đổi hay không" (luôn luôn có), mà là "làm sao thay đổi mà không mất kiểm soát" — không để một thay đổi nhỏ kéo theo domino effect làm sập toàn bộ cam kết quý mà không ai kịp nhận ra.

AI tạo giá trị lớn nhất ở đây trong việc trả lời nhanh câu hỏi "nếu thay đổi X, những gì khác bị ảnh hưởng?" — thứ mà làm thủ công thường mất nửa ngày lục lại Jira, Confluence, Slack. Nhưng đây cũng là chỗ dễ vấp nhất: real-time không có nghĩa là "AI tự động sửa roadmap live". Nó có nghĩa là AI rút ngắn thời gian phân tích tác động (impact analysis) từ hàng giờ xuống vài phút, để con người ra quyết định nhanh hơn — quyết định vẫn luôn là của con người, và vẫn đi qua một go/no-go checkpoint, chỉ là checkpoint đó giờ diễn ra trong ngày thay vì chờ tới buổi retro cuối sprint.

Các Bước Thực Hành

1. Định nghĩa "trigger" cần re-plan: Thống nhất trước với team những loại sự kiện nào bắt buộc chạy lại phân tích tác động: dependency bị block quá X ngày, insight mới làm thay đổi RICE score của một initiative đang chạy trên 20%, hoặc chỉ đạo ưu tiên mới từ leadership.
2. Thu thập nhanh bối cảnh thay đổi: Khi trigger xảy ra, ghi lại ngắn gọn: điều gì vừa thay đổi, ai/nguồn nào xác nhận, mức độ chắc chắn của thông tin này.
3. Chạy phân tích tác động bằng AI: Đưa roadmap/backlog hiện tại cùng với thay đổi mới vào Claude/ChatGPT, yêu cầu liệt kê mọi initiative/story bị ảnh hưởng trực tiếp và gián tiếp, kèm mức độ nghiêm trọng.
4. Yêu cầu AI đề xuất phương án xử lý: Ít nhất 2 phương án (ví dụ: "trì hoãn initiative A sang Q4" hoặc "giữ nguyên timeline nhưng giảm scope"), mỗi phương án nêu rõ đánh đổi (trade-off).
5. Đưa qua go/no-go nhanh (async nếu cần gấp): Với thay đổi nhỏ, không cần họp — gửi phân tích tác động + đề xuất của AI qua Slack/Confluence cho Tech Lead và stakeholder liên quan, xin xác nhận trong vài giờ. Với thay đổi lớn (ảnh hưởng >1 sprint hoặc >2 team), vẫn cần họp go/no-go trực tiếp.
6. Cập nhật roadmap/backlog và ghi log thay đổi: Sau khi quyết định, cập nhật lại Aha!/Productboard/Jira, và ghi rõ lý do thay đổi vào changelog — để 2 tháng sau không ai phải hỏi "sao ticket này lại bị đẩy lùi vậy?".

Ví Dụ Prompt

Bối cảnh vừa thay đổi: Team platform thông báo API xác thực mới sẽ trễ 3 tuần so với kế hoạch (dự kiến xong tuần 6 thay vì tuần 3 của quý).

Đây là roadmap và backlog hiện tại của tôi:
[dán roadmap + backlog]

Nhiệm vụ:
1. Liệt kê mọi initiative/story phụ thuộc trực tiếp hoặc gián tiếp vào API xác thực này.
2. Với mỗi initiative bị ảnh hưởng, đánh giá mức độ nghiêm trọng (Cao/Trung bình/Thấp) và giải thích vì sao.
3. Đề xuất ít nhất 2 phương án xử lý (ví dụ: dời timeline, đổi thứ tự ưu tiên, tìm giải pháp tạm/workaround), nêu rõ đánh đổi của mỗi phương án.

Trả lời bằng tiếng Việt, giữ nguyên thuật ngữ kỹ thuật tiếng Anh.

Leadership vừa yêu cầu ưu tiên gấp một tính năng mới: "Tích hợp SSO cho khách hàng doanh nghiệp", cần xong trong 4 tuần.

Đây là backlog sprint hiện tại (đã commit): [dán backlog]
Capacity còn lại quý này: [số liệu]

Hãy phân tích:
1. Nếu chèn tính năng này vào, story/initiative nào hiện tại phải bị đẩy lùi hoặc cắt bớt để đủ capacity?
2. Ưu tiên nên đẩy lùi cái nào trước, dựa trên RICE score hiện có của từng item (tôi sẽ cung cấp)?
3. Rủi ro nếu không đẩy lùi gì mà vẫn cố nhét thêm việc vào là gì?

Trả lời bằng tiếng Việt, giữ nguyên thuật ngữ kỹ thuật tiếng Anh.

Mẹo: Đặt sẵn một "ngưỡng trigger" rõ ràng cho việc re-plan (ví dụ: dependency block quá 5 ngày, hoặc RICE score đổi trên 20%) — nếu không, team sẽ hoặc là re-plan liên tục vì mọi thay đổi nhỏ (gây mệt mỏi, mất ổn định), hoặc ngược lại phớt lờ thay đổi thật sự quan trọng vì "để sau tính".

Những Điểm Chính Cần Nhớ

• Chain hoá, đừng gộp một prompt: Chuyển opportunity đã ưu tiên thành roadmap update nên qua 4 bước tách biệt (đối chiếu → xếp quý → soạn draft → tóm tắt changelog), mỗi bước review được độc lập thay vì tin một output "tất cả trong một" của AI.
• AI rút ngắn thời gian phân rã, không thay tư duy phân rã: Từ roadmap theme xuống epic, story, acceptance criteria — AI giúp bạn có bản nháp trong vài chục phút thay vì vài giờ, nhưng bạn vẫn phải kiểm tra story có vừa 1 sprint và acceptance criteria có đo lường được hay không.
• Go/no-go checkpoint là bắt buộc, không phải tuỳ chọn: Vì quyết định planning trực tiếp commit capacity engineering thật, mọi output AI phải qua checklist go/no-go rõ ràng (nguồn gốc dữ liệu, khả thi kỹ thuật, xung đột roadmap, acceptance criteria, capacity, rủi ro pháp lý) trước khi vào sprint.
• Yêu cầu AI tự phê bình chính nó: Prompt self-critique ("phần nào bạn ít tự tin nhất?") là cách rẻ và nhanh nhất để lộ ra giả định thiếu căn cứ trước khi con người phải tự mò ra.
• Real-time re-plan vẫn cần con người quyết định: AI rút ngắn impact analysis từ hàng giờ xuống vài phút, nhưng quyết định thay đổi roadmap/backlog vẫn luôn qua go/no-go — chỉ nhanh hơn, không phải tự động hoá hoàn toàn.
• Không bao giờ để workflow tự động publish thẳng lên roadmap/backlog live: Mọi pipeline tự động hoá (n8n, Zapier, Make) nên dừng ở trạng thái Draft/Pending Review, chờ con người bấm approve.