Mở đầu — vì sao bài này quan trọng
Bạn có bao giờ tham gia một buổi retrospective (retro) mà sau khi tan họp, mọi người ra về với cảm giác "ờ buổi đó vui đấy", rồi… không có gì thay đổi? Sprint sau lỗi cũ lại lặp lại, cùng một người than phiền về cùng một vấn đề, và team dần dần coi retro là một buổi họp hình thức để "cho có". Đây là một trong những nỗi đau phổ biến nhất của các team Agile tại Việt Nam, và nó thường không phải do team lười cải tiến — mà do không có nơi lưu giữ và theo dõi những gì đã nói trong retro.
Đây chính là lý do bài học này tồn tại. Với vai trò BA (Business Analyst), bạn không chỉ là người viết tài liệu nghiệp vụ — bạn còn thường xuyên là người giữ trí nhớ cho team, người biến những cuộc trò chuyện rời rạc thành tài liệu có cấu trúc, có thể tra cứu và đối chiếu được. Confluence là công cụ lý tưởng để làm điều đó cho sprint retrospective: nó biến một buổi họp "nói rồi quên" thành một vòng lặp cải tiến liên tục có bằng chứng.
Trong bài này, chúng ta sẽ học cách thiết kế, vận hành và duy trì một quy trình retrospective hoàn chỉnh ngay trên Confluence — từ việc tạo trang retro có cấu trúc, thu thập ý kiến của cả team, đến cách theo dõi các action item qua nhiều sprint để retro thực sự tạo ra thay đổi. Lưu ý: bài này tập trung riêng vào retrospective — phần ghi nhận, theo dõi cải tiến cuối sprint. Việc lập kế hoạch sprint, refinement backlog hay tạo board sẽ được học ở các bài khác.
Khái niệm cốt lõi
Retrospective là gì và tại sao nó là "trái tim" của Agile
Sprint retrospective là buổi họp cuối mỗi sprint, nơi cả team dừng lại để nhìn lại cách mình đã làm việc (chứ không phải sản phẩm đã làm ra — cái đó thuộc về sprint review). Câu hỏi cốt lõi của retro chỉ xoay quanh ba trục:
- Điều gì đã làm tốt? (What went well) — để giữ lại và phát huy.
- Điều gì chưa ổn? (What didn't go well) — để nhận diện vấn đề.
- Lần tới ta thử gì? (What to try next) — để biến nhận thức thành hành động.
Vì sao dùng Confluence chứ không phải sticky note hay file chat
Nhiều team Việt Nam vẫn làm retro bằng giấy nhớ dán tường, hoặc gõ vào nhóm chat Slack/Teams. Cách này có hai điểm yếu chí mạng:
- Không có lịch sử tra cứu. Sticky note bị gỡ đi sau buổi họp. Tin nhắn chat bị trôi sau vài ngày. Sang sprint sau, chẳng ai nhớ kỳ trước team đã cam kết gì.
- Không gắn được trách nhiệm. Một ý tưởng cải tiến không có người phụ trách (owner) và hạn chót (due date) thì gần như chắc chắn sẽ chết.
Cấu trúc một trang retrospective trên Confluence
Confluence có sẵn một template tên là Retrospective (vào nút Create > Templates > Retrospective), nhưng bạn cũng có thể tự dựng. Một trang retro tốt thường gồm các thành phần:
- Phần metadata: tên sprint, ngày diễn ra, người tham gia (dùng macro @mention để gắn thẻ thành viên), thời lượng sprint.
- Ba cột cảm nhận: thường trình bày bằng một bảng (table) ba cột — Went Well / Didn't Go Well / To Improve. Một số team thích biến thể "Mad / Sad / Glad" hoặc "Start / Stop / Continue" — cách đặt tên không quan trọng bằng việc giữ đúng tinh thần ba trục.
- Action items: phần quan trọng nhất. Confluence có macro Action Item (gõ
/actionhoặc dùng phím tắt[]) tạo ra một checkbox có thể gán cho người phụ trách qua@. Đây là "đầu ra" thực sự của retro. - Liên kết tới retro kỳ trước: để đối chiếu xem các cam kết cũ đã hoàn thành chưa.
Action item — nơi retro tạo ra giá trị thật
Hãy ghi nhớ một câu thần chú: "Retro không kết thúc bằng cảm xúc, mà kết thúc bằng action item." Một action item tốt phải có đủ ba yếu tố: mô tả cụ thể, người phụ trách (owner), và thời hạn. Ví dụ thay vì viết "Cần cải thiện giao tiếp với team QA", hãy viết: "Tổ chức buổi sync 15 phút giữa Dev và QA mỗi sáng thứ Hai — @Hùng phụ trách — bắt đầu từ sprint 13."
Macro Action Item của Confluence còn có một lợi ích ngầm: tất cả action item bạn được gán sẽ tự động xuất hiện trong mục Tasks cá nhân của bạn trên Confluence (góc trên cùng, biểu tượng người dùng). Nghĩa là không ai có thể nói "tôi quên mất việc đó được giao cho tôi".
Tình huống thực tế
Tình huống 1: Tiki — khi action item "bốc hơi" qua từng sprint
Một team phát triển tính năng thanh toán tại một công ty thương mại điện tử lớn ở TP.HCM (tạm gọi theo mô hình Tiki) làm retro đều đặn mỗi hai tuần. Họ dùng công cụ Miro với sticky note ảo, buổi nào cũng sôi nổi, dán đầy bảng. Nhưng sau sáu sprint, Scrum Master nhận ra một điều đáng buồn: cùng một vấn đề "môi trường staging hay sập lúc demo" đã được nêu ở bốn sprint liên tiếp mà chưa lần nào được giải quyết. Lý do? Mỗi buổi Miro xong là board bị archive, không ai mở lại, action item không có owner.
Họ chuyển toàn bộ retro sang Confluence, tạo một space riêng tên "Team Payment — Retrospectives", mỗi sprint một trang con. Quan trọng nhất, họ thêm quy ước: mỗi action item phải có owner gán bằng macro Action Item, và mỗi buổi retro mới phải mở lại trang retro kỳ trước để review các action item cũ trước khi bàn cái mới. Chỉ sau ba sprint, vấn đề staging được giải quyết dứt điểm vì lần đầu tiên nó có một người tên cụ thể chịu trách nhiệm và một deadline rõ ràng.
Bài học: Công cụ trực quan đẹp mắt không thay thế được khả năng lưu trữ và truy vết. Giá trị của Confluence nằm ở chỗ nó ép team phải đối diện với những lời hứa chưa hoàn thành.
Tình huống 2: Một fintech ở Singapore — retro cho team phân tán hai múi giờ
Một startup fintech có team kỹ thuật chia làm hai: một nửa ở Singapore, một nửa ở Hà Nội. Vì lệch lịch và đôi khi không họp được cùng lúc, họ không thể làm retro "real-time" kiểu truyền thống. BA của team (đồng thời kiêm vai trò điều phối) đã thiết kế một quy trình retro bất đồng bộ (async) hoàn toàn trên Confluence:
- Hai ngày trước buổi họp chung, BA tạo sẵn trang retro với bảng ba cột để trống.
- Mọi thành viên tự vào điền cảm nhận của mình, ghi tên trong dấu ngoặc để biết ai viết gì, dùng tính năng inline comment để phản hồi ý kiến của nhau.
- Đến buổi họp 30 phút (rút ngắn còn một nửa vì phần thu thập đã xong), team chỉ tập trung thảo luận và chốt action item.
Bài học: Confluence không chỉ là nơi ghi lại retro mà có thể là nơi diễn ra retro. Với team phân tán hoặc đa văn hóa, mô hình async tận dụng đúng thế mạnh tài liệu của Confluence.
Tình huống 3: Team nội bộ VNG — biến retro thành dữ liệu để báo cáo lên quản lý
Một team sản phẩm tại một công ty công nghệ lớn ở Việt Nam (mô hình VNG) gặp vấn đề: quản lý cấp trên luôn hỏi "team các bạn có đang cải thiện không?" nhưng họ không có bằng chứng định lượng. BA của team nảy ra ý tưởng: ở cuối mỗi trang retro, thêm một dòng đánh giá "sprint mood" theo thang điểm 1–5 và một ô ghi số action item đã hoàn thành từ sprint trước.
Sau đó, dùng macro Page Properties trên mỗi trang retro và macro Page Properties Report ở trang tổng để Confluence tự tổng hợp thành một bảng: sprint nào mood bao nhiêu, hoàn thành bao nhiêu action item. Sau 10 sprint, BA có một biểu đồ xu hướng cho thấy mood team tăng từ 2.8 lên 4.1 và tỉ lệ hoàn thành action item từ 40% lên 85%. Đây là bằng chứng thuyết phục để bảo vệ ngân sách và chứng minh văn hóa cải tiến đang hoạt động.
Bài học: Dữ liệu retro tích lũy qua thời gian có thể trở thành công cụ quản trị mạnh mẽ. BA biết tận dụng cấu trúc Confluence sẽ tạo ra giá trị vượt xa một buổi họp.
Hướng dẫn từng bước
Dưới đây là quy trình dựng và vận hành retro trên Confluence từ con số không:
Bước 1 — Tạo không gian lưu trữ. Trong space của team, tạo một trang cha tên "Sprint Retrospectives". Tất cả retro của từng sprint sẽ là trang con của nó, đặt tên theo quy ước nhất quán như "Retro — Sprint 12 (10–24/06/2026)".
Bước 2 — Dựng template chuẩn. Tạo một trang mẫu (hoặc dùng template Retrospective có sẵn) gồm: phần metadata (sprint, ngày, người tham gia bằng @mention), bảng ba cột Went Well / Didn't Go Well / To Improve, mục Action Items, và một liên kết tới retro kỳ trước. Lưu lại làm template để mỗi sprint chỉ việc nhân bản.
Bước 3 — Chuẩn bị trước buổi họp. Một ngày trước, nhân bản template thành trang retro mới cho sprint hiện tại. Nếu làm async, gửi link cho cả team điền trước.
Bước 4 — Thu thập ý kiến. Cho cả team điền vào ba cột — hoặc trực tiếp gõ trong buổi họp, hoặc điền sẵn nếu async. Khuyến khích viết cụ thể, tránh chung chung.
Bước 5 — Review action item kỳ trước (cực kỳ quan trọng). Trước khi bàn cái mới, mở trang retro sprint trước, đi qua từng action item: cái nào xong, cái nào chưa, vì sao chưa. Bước này tạo ra trách nhiệm giải trình và là điểm khác biệt giữa team cải tiến thật và team họp cho vui.
Bước 6 — Chốt action item mới. Với mỗi vấn đề ưu tiên, tạo một action item dùng macro /action, gán owner bằng @tên và ghi rõ deadline. Giới hạn 2–3 action item mỗi sprint — nhiều quá sẽ không ai làm nổi.
Bước 7 — Liên kết và đóng trang. Thêm link hai chiều giữa trang retro này và trang kế tiếp/trước đó. Nếu một action item cần triển khai thành công việc kỹ thuật, có thể tạo issue tương ứng trong JIRA và dán link vào.
Bước 8 — Theo dõi giữa sprint. Owner của action item kiểm tra mục Tasks cá nhân trên Confluence để không quên. Đến retro sau, quay lại Bước 5.
Lỗi thường gặp & mẹo
Lỗi 1 — Retro không sinh ra action item, hoặc action item không có owner. Đây là lỗi giết chết retro phổ biến nhất. Mẹo: luôn dùng macro Action Item (không phải gạch đầu dòng thường), bắt buộc mỗi mục có một @người và một ngày. Không có owner = sẽ không xảy ra.
Lỗi 2 — Không bao giờ mở lại retro cũ. Nếu sprint nào cũng bắt đầu từ trang trắng, team sẽ liên tục lặp lại lỗi cũ. Mẹo: biến "review action item kỳ trước" thành nghi thức bắt buộc đầu mỗi buổi.
Lỗi 3 — Đặt tên trang lộn xộn. "Retro mới", "Retro tháng 6", "Retro (final)" khiến không ai tìm được gì sau ba tháng. Mẹo: thống nhất một quy ước đặt tên có số sprint và khoảng ngày, áp dụng triệt để.
Lỗi 4 — Biến retro thành buổi đổ lỗi. Khi tài liệu ghi lại "ai làm sai", người ta sẽ phòng thủ và không nói thật nữa. Mẹo: tập trung vào hệ thống và quy trình, không vào cá nhân. Confluence là nơi ghi vấn đề và giải pháp, không phải bảng phong thần.
Lỗi 5 — Quá nhiều action item. Chốt 10 việc cải tiến trong một sprint nghĩa là 0 việc được làm. Mẹo: chọn tối đa 2–3 việc quan trọng nhất, làm cho xong, rồi mới thêm.
Mẹo nâng cao: Dùng macro Page Properties + Page Properties Report để tự động hóa bảng tổng hợp xu hướng (mood, tỉ lệ hoàn thành action) như trong tình huống 3 — rất hữu ích khi báo cáo. Dùng labels (ví dụ gắn nhãn retrospective) cho mọi trang retro để dễ lọc và tìm kiếm về sau. Với team async, kết hợp inline comment để mọi người phản hồi ý kiến nhau trước buổi họp.
Bài tập thực hành
- Dựng cấu trúc. Trong một Confluence space (dùng bản free của Atlassian nếu chưa có), tạo trang cha "Sprint Retrospectives" và một template retro chuẩn gồm: metadata, bảng ba cột, mục action items, link tới kỳ trước. Lưu làm template.
- Chạy thử một retro giả định. Tạo trang "Retro — Sprint 1", tự nhập ít nhất 3 ý kiến cho mỗi cột (Went Well / Didn't Go Well / To Improve) như thể bạn là 3 thành viên khác nhau. Sau đó chốt đúng 2 action item, mỗi cái gán cho một người (dùng @mention với tài khoản của bạn hoặc đồng nghiệp) và một deadline cụ thể bằng macro Action Item.
- Tạo vòng lặp. Nhân bản template thành "Retro — Sprint 2". Ở đầu trang, thêm phần "Review action item Sprint 1" và đánh dấu trạng thái (xong/chưa xong) cho 2 action item bạn đã tạo ở bài 2. Thêm link hai chiều giữa hai trang.
- (Nâng cao) Tự động hóa báo cáo. Thêm macro Page Properties vào cả hai trang retro với hai trường: "Mood (1–5)" và "Action items hoàn thành". Tạo một trang "Retro Dashboard" dùng macro Page Properties Report để tổng hợp hai sprint thành một bảng. Quan sát cách Confluence tự gom dữ liệu.
- Suy ngẫm. Viết một đoạn ngắn (5–7 câu) trả lời: với team bạn đang/sẽ làm, mô hình retro đồng bộ hay async phù hợp hơn? Vì sao?
Tóm tắt
Sprint retrospective là động cơ của cải tiến liên tục trong Agile, nhưng nó chỉ thực sự tạo ra thay đổi khi có nơi lưu giữ, theo dõi và truy vết — và đó chính là vai trò của Confluence. Chúng ta đã học cách dựng một trang retro có cấu trúc quanh ba trục Went Well / Didn't Go Well / To Improve, và quan trọng hơn cả, cách biến cảm nhận thành action item có owner và deadline bằng macro Action Item.
Điểm cốt lõi cần khắc ghi: retro thất bại không phải vì thiếu ý tưởng, mà vì những ý tưởng đó không được lưu lại và không ai chịu trách nhiệm. Nghi thức "review action item kỳ trước" mỗi đầu buổi là ranh giới giữa một team thực sự tiến bộ và một team họp cho có. Qua ba tình huống — từ team thanh toán giải quyết được lỗi staging tồn đọng, đến team phân tán hai múi giờ làm retro async, đến team biến dữ liệu retro thành báo cáo cho quản lý — bạn đã thấy Confluence không chỉ ghi lại retro mà có thể là nơi retro diễn ra và là nguồn dữ liệu quản trị.
Với vai trò BA, bạn thường là người giữ cấu trúc và trí nhớ cho team. Làm chủ kỹ năng tổ chức retrospective trên Confluence giúp bạn biến mỗi sprint thành một bước tiến có bằng chứng — chứ không phải một buổi họp rồi quên.