Mở đầu — vì sao bài này quan trọng
Hãy hình dung một đội phát triển sản phẩm chạy Sprint suốt một năm trời. Họ làm Sprint Planning rất chỉn chu, demo sản phẩm đều đặn ở Sprint Review, nhưng có một điều kỳ lạ: hết Sprint này qua Sprint khác, họ vẫn vấp phải đúng những vấn đề cũ. Vẫn bị bug dồn vào ngày cuối. Vẫn estimate sai. Vẫn cãi nhau về Definition of Done. Đội tiến về phía trước, nhưng giống như đi bộ trên băng chuyền chạy ngược — tốn sức mà không cải thiện.
Vấn đề của họ không nằm ở kỹ thuật, mà nằm ở chỗ họ chưa bao giờ thật sự học từ chính mình. Và đó chính là lý do Sprint Retrospective tồn tại.
Có một câu nói rất hay trong giới Agile: "Không có Retrospective, Scrum chỉ còn là một cái lịch họp." Mọi sự kiện khác trong Scrum đều hướng tới việc tạo ra sản phẩm. Riêng Retrospective là sự kiện duy nhất hướng tới việc cải thiện chính cách đội làm việc. Nó là cơ chế tự sửa lỗi (self-correction) của một đội Scrum. Bỏ nó đi, đội mất khả năng tiến hóa.
Với vai trò Product Owner, bạn có thể nghĩ Retrospective là "chuyện của Scrum Master". Sai lầm lớn. PO là một thành viên đầy đủ của Scrum Team, và cách bạn tương tác với đội trong Retrospective ảnh hưởng trực tiếp đến chất lượng backlog, tốc độ giao hàng và sự tin tưởng giữa hai bên. Một PO biết tận dụng Retrospective sẽ có một đội mạnh hơn theo cấp số nhân. Bài học này sẽ giúp bạn làm chủ sự kiện đó.
Khái niệm cốt lõi
Sprint Retrospective là gì?
Sprint Retrospective là sự kiện cuối cùng trong một Sprint, diễn ra ngay sau Sprint Review và trước Sprint Planning của Sprint kế tiếp. Mục đích của nó, theo Scrum Guide, là để Scrum Team kiểm tra (inspect) cách họ vừa làm việc trong Sprint vừa qua và lập kế hoạch cải tiến (adapt) cho Sprint tới.
Điểm mấu chốt cần ghi nhớ: Retrospective xoay quanh con người, quan hệ, quy trình và công cụ — chứ không xoay quanh sản phẩm. Nếu Sprint Review hỏi "Chúng ta đã xây cái gì?" thì Retrospective hỏi "Chúng ta đã làm việc với nhau như thế nào, và làm sao để tốt hơn?".
Về thời lượng (timebox): với Sprint một tháng, Retrospective tối đa 3 giờ. Với Sprint hai tuần — phổ biến nhất ở Việt Nam — khoảng 1 đến 1.5 giờ là hợp lý. Sprint ngắn hơn thì Retro ngắn hơn tương ứng.
Ai tham gia?
Toàn bộ Scrum Team: Developers, Scrum Master và Product Owner. Đây là không gian nội bộ của đội. Theo nguyên tắc, không mời sếp cấp trên, khách hàng hay stakeholder bên ngoài vào — vì sự hiện diện của họ làm đội mất an toàn tâm lý, và người ta sẽ không dám nói thật. Scrum Master thường đóng vai facilitator (người điều phối), nhưng cũng có quyền tự nhận xét về công việc của mình.
Nguyên liệu quan trọng nhất: An toàn tâm lý
Trước khi bàn về format hay kỹ thuật, bạn phải hiểu nền móng của một Retrospective hiệu quả: psychological safety — an toàn tâm lý. Đó là cảm giác rằng mình có thể nói ra sự thật, thừa nhận sai lầm, đặt câu hỏi "ngớ ngẩn" mà không sợ bị trừng phạt hay chê cười.
Norman Kerth, cha đẻ của khái niệm Retrospective hiện đại, đề xuất "Prime Directive" (Chỉ thị tối cao) mà nhiều đội đọc to ở đầu mỗi buổi: "Bất kể chúng ta khám phá ra điều gì, chúng ta tin rằng mọi người đã làm tốt nhất có thể trong hoàn cảnh của họ, với kiến thức, kỹ năng và nguồn lực sẵn có lúc đó." Tinh thần này biến Retrospective từ phiên đổ lỗi thành phiên học hỏi.
Các format phổ biến
Không có một format "đúng" duy nhất. Người điều phối giỏi sẽ đổi format để giữ buổi họp tươi mới. Dưới đây là vài format kinh điển:
1. Start / Stop / Continue
Đội trả lời ba câu hỏi:
- Start — việc gì chúng ta nên bắt đầu làm? (ý tưởng mới, thử nghiệm)
- Stop — việc gì đang gây hại, ta nên ngừng lại?
- Continue — việc gì đang tốt, ta nên tiếp tục duy trì?
2. Mad / Sad / Glad
Tập trung vào cảm xúc: điều gì khiến bạn tức giận (mad), buồn (sad), vui (glad) trong Sprint. Format này hữu ích khi đội đang căng thẳng, cần xả van và xây dựng sự đồng cảm.
3. 4Ls — Liked / Learned / Lacked / Longed for
Đã thích gì, học được gì, thiếu gì, mong muốn gì. Cân bằng giữa cảm xúc và lý trí, rất hợp cho đội đã trưởng thành.
4. Sailboat (Thuyền buồm)
Một phép ẩn dụ trực quan: con thuyền là đội, gió đẩy thuyền là những thứ giúp ta tiến nhanh, mỏ neo là những thứ kéo ta chậm lại, đá ngầm là rủi ro phía trước, và hòn đảo là mục tiêu. Rất hợp khi họp online với bảng trắng số (Miro, Mural, FigJam).
Cấu trúc 5 bước của Esther Derby & Diana Larsen
Dù dùng format nào, một Retrospective tốt thường đi theo 5 giai đoạn kinh điển từ cuốn Agile Retrospectives:
- Set the Stage — khởi động, tạo không khí an toàn, "check-in" cảm xúc.
- Gather Data — thu thập dữ liệu, sự kiện, cảm nhận về Sprint.
- Generate Insights — đào sâu, tìm nguyên nhân gốc rễ (root cause).
- Decide What to Do — chọn ra 1–3 hành động cải tiến cụ thể.
- Close the Retrospective — chốt lại, cảm ơn, đánh giá nhanh buổi họp.
Tình huống thực tế
Tình huống 1 — Tiki và căn bệnh "Retro hình thức"
Giả định một squad tại một sàn thương mại điện tử lớn ở TP.HCM (lấy cảm hứng từ mô hình Tiki). Squad gồm 6 Developers, một Scrum Master và một PO tên Linh. Họ chạy Sprint hai tuần. Vấn đề: mỗi cuối Sprint, Retrospective chỉ kéo dài 20 phút, mọi người nói qua loa "Sprint ổn, không có gì đặc biệt", rồi giải tán đi ăn trưa. Suốt 4 Sprint liền, velocity dao động thất thường từ 22 đến 41 story points mà không ai biết tại sao.
Một Scrum Master mới về đã thay đổi cách làm. Anh áp dụng format Sailboat trên Miro, dành đủ 90 phút, và quan trọng nhất — ở bước "Generate Insights", anh dùng kỹ thuật 5 Whys (hỏi "tại sao" 5 lần). Khi đội than "Sprint nào cũng bị dồn việc vào ngày cuối", anh hỏi tại sao. Vì task to chỉ xong vào cuối Sprint. Tại sao? Vì task không được chia nhỏ. Tại sao? Vì refinement qua loa. Tại sao? Vì PO Linh thường bận họp stakeholder và đến refinement trễ. Tại sao? Vì lịch họp của Linh bị xếp chồng chéo.
Hóa ra gốc rễ nằm ở lịch của PO, chứ không phải kỹ năng của Developers. Hành động được chốt: Linh khóa cứng khung giờ refinement vào thứ Tư hằng tuần và không nhận họp khác trong khung đó. Hai Sprint sau, velocity ổn định quanh mức 34–37, và tỉ lệ task hoàn thành đúng hạn tăng rõ rệt.
Bài học: Retrospective hời hợt còn tệ hơn không có, vì nó tạo ảo giác rằng đội "đã cải tiến". Đào tới nguyên nhân gốc rễ mới ra được hành động đúng — và đôi khi gốc rễ nằm ở chính Product Owner.
Tình huống 2 — Startup fintech và action item "rơi vào hư không"
Một startup fintech ở Hà Nội, khoảng 30 người, đội sản phẩm chạy Scrum nghiêm túc. Retrospective của họ rất sôi nổi: mỗi buổi đội liệt kê được 8–10 vấn đề và đề ra cả chục hành động cải tiến. Nghe thì tuyệt, nhưng sau 6 tháng, người ta nhận ra hơn 80% các action item từ những buổi Retrospective trước chưa bao giờ được thực hiện. Đội nói rất hăng nhưng không có gì thay đổi.
Vấn đề là họ vi phạm hai nguyên tắc. Thứ nhất, họ chọn quá nhiều hành động cùng lúc — 10 action item nghĩa là không có cái nào đủ quan trọng để ưu tiên. Thứ hai, action item không có người chịu trách nhiệm (owner) và thời hạn cụ thể.
Họ sửa bằng cách áp quy tắc đơn giản: mỗi Retrospective chỉ chọn tối đa 2 action item, mỗi cái có một owner đích danh và phải hoàn thành trong Sprint kế tiếp. Quan trọng hơn, họ đưa các action item này thành các mục có thể nhìn thấy trên Product Backlog hoặc Sprint Backlog — coi cải tiến quy trình cũng là "công việc" thật sự cần làm. PO của đội đồng ý dành một phần nhỏ năng lực mỗi Sprint cho các cải tiến này. Đầu mỗi Retrospective, họ dành 5 phút điểm danh action item của lần trước: làm xong chưa, kết quả thế nào.
Sau ba tháng, tỉ lệ hoàn thành action item nhảy lên trên 90%. Buổi Retro ngắn lại nhưng có giá trị hơn hẳn.
Bài học: Giá trị của Retrospective không nằm ở số lượng vấn đề được nói ra, mà ở số lượng cải tiến thực sự được thực thi. Ít mà chất. PO đóng vai trò then chốt khi cho phép "công việc cải tiến" có chỗ đứng trong backlog.
Tình huống 3 — Đội phân tán và sự im lặng đáng sợ
Một công ty outsourcing tại Đà Nẵng có đội làm cho khách hàng Singapore, thành viên trải ở ba thành phố. Retrospective online luôn rơi vào cảnh: Scrum Master hỏi "Có ai có ý kiến gì không?", rồi 30 giây im lặng, cuối cùng chỉ một hai người nói, còn lại tắt camera ngồi im. Buổi họp trở thành độc thoại.
Nguyên nhân kép: rào cản online khiến người ta ngại cắt lời nhau, và yếu tố văn hóa — nhiều bạn trẻ Việt ngại nói thẳng vấn đề trước mặt cả đội, nhất là khi liên quan đến đồng nghiệp lớn tuổi hơn hoặc PO.
Giải pháp là chuyển sang thu thập dữ liệu im lặng và ẩn danh trước. Scrum Master dùng công cụ như EasyRetro hoặc bảng Miro, cho mọi người 7 phút viết sticky note đồng thời mà không cần nói. Sau đó mới gom nhóm và thảo luận. Anh cũng áp dụng dot voting — mỗi người có 3 chấm để bỏ phiếu cho vấn đề mình thấy quan trọng nhất, để cả đội cùng quyết ưu tiên thay vì người nói to nhất thắng.
Kết quả: số lượng ý kiến trong mỗi buổi tăng gấp ba, và những vấn đề "nhạy cảm" trước đây không ai dám nêu giờ xuất hiện qua note ẩn danh.
Bài học: Trong bối cảnh đội phân tán và văn hóa Á Đông, đừng dựa vào việc "ai cũng sẽ tự giác phát biểu". Hãy thiết kế buổi họp để ngay cả người ngại nhất cũng đóng góp được — viết trước, ẩn danh, rồi mới bàn.
Hướng dẫn từng bước
Đây là cách chạy một Sprint Retrospective hiệu quả, áp dụng được ngay:
Bước 1 — Chuẩn bị (trước buổi họp). Scrum Master chọn format phù hợp với tâm trạng đội (đội căng thẳng thì Mad/Sad/Glad; đội ổn định thì 4Ls; online thì Sailboat). Chuẩn bị bảng số nếu họp từ xa. Quan trọng: rà lại các action item của Retrospective trước để điểm danh đầu buổi.
Bước 2 — Set the Stage (5–10 phút). Mở màn bằng một câu check-in nhẹ nhàng: "Một từ mô tả Sprint vừa rồi của bạn?". Đọc to Prime Directive để tái lập an toàn tâm lý. Nhắc rằng đây là không gian học hỏi, không phải tòa án.
Bước 3 — Gather Data (15–20 phút). Cho mọi người viết note đồng thời, im lặng, theo format đã chọn. Tuyệt đối không để ai vừa viết vừa phải nghe người khác nói — viết trước, nói sau.
Bước 4 — Generate Insights (20–25 phút). Gom nhóm các note tương tự, dùng dot voting để chọn 2–3 chủ đề nóng nhất. Với mỗi chủ đề, đào nguyên nhân gốc bằng 5 Whys hoặc sơ đồ xương cá (fishbone). Đây là bước hay bị bỏ qua nhất — đừng vội.
Bước 5 — Decide What to Do (15 phút). Chọn tối đa 1–3 action item. Mỗi cái phải có: mô tả cụ thể, một owner đích danh, và thời hạn (lý tưởng là trong Sprint tới). Viết theo kiểu hành động được, ví dụ thay vì "cải thiện giao tiếp" thì viết "Lan tạo kênh Slack riêng cho việc báo blocker, xong trong tuần này".
Bước 6 — Close (5 phút). Tóm tắt các action item, cảm ơn cả đội, và làm một vòng đánh giá nhanh chính buổi Retro (ví dụ "ROTI" — Return On Time Invested, mỗi người giơ 1–5 ngón tay đánh giá buổi họp có đáng thời gian không).
Bước 7 — Theo dõi (suốt Sprint sau). Đưa action item vào nơi nhìn thấy được (Sprint Backlog, bảng task). Không để nó nằm im trong file ghi chú rồi bị lãng quên.
Lỗi thường gặp & mẹo
Lỗi 1 — Biến Retro thành phiên đổ lỗi. Khi không khí trở thành "tại ai", người ta phòng thủ và che giấu. Mẹo: tập trung vào hệ thống và quy trình, không vào cá nhân. Dùng Prime Directive làm tấm khiên.
Lỗi 2 — Bỏ qua bước đào nguyên nhân gốc. Đội liệt kê triệu chứng rồi vội chốt hành động bề mặt. Mẹo: luôn hỏi "tại sao" ít nhất 3 lần trước khi đưa ra giải pháp.
Lỗi 3 — Quá nhiều action item, không cái nào xong. Mẹo: giới hạn 1–3 hành động, có owner và deadline, và rà lại ở buổi sau. Một cải tiến được làm xong giá trị hơn mười cái chỉ nằm trên giấy.
Lỗi 4 — Luôn dùng một format gây nhàm chán. Sau dăm Sprint dùng Start/Stop/Continue, đội trả lời như cái máy. Mẹo: đổi format định kỳ để giữ sự tươi mới và góc nhìn mới.
Lỗi 5 — Mời stakeholder hoặc sếp vào dự. Điều này phá vỡ an toàn tâm lý. Mẹo: giữ Retrospective là không gian nội bộ của Scrum Team.
Lỗi 6 (đặc biệt cho PO) — PO biến Retro thành buổi review tiến độ. Một số PO tranh thủ Retrospective để phàn nàn về backlog chưa xong. Mẹo: PO hãy đến với tâm thế của một thành viên đội cùng cải tiến, không phải khách hàng đến đòi nợ. Cũng đừng bỏ Retro với lý do "bận họp khác" — sự vắng mặt của PO gửi đi thông điệp rằng cải tiến đội không quan trọng.
Lỗi 7 — Không có hành động nào dành cho chính PO. Nếu Sprint nào action item cũng chỉ thuộc về Developers, hãy tự hỏi liệu đội có đang ngại góp ý cho PO không. Mẹo: PO chủ động mời phản hồi về cách mình viết backlog, sắp ưu tiên, hay phản hồi câu hỏi.
Bài tập thực hành
- Tự soi một Sprint. Lấy một Sprint gần nhất bạn từng tham gia (hoặc một dự án bất kỳ). Áp dụng format Start/Stop/Continue, tự viết ra ít nhất 2 mục cho mỗi cột. Sau đó chọn 1 mục ở cột Stop và hỏi "tại sao" 5 lần để tìm nguyên nhân gốc.
- Viết action item chuẩn. Lấy ba câu cải tiến mơ hồ sau và viết lại thành action item có owner và deadline: (a) "Chúng ta cần giao tiếp tốt hơn"; (b) "Estimate cần chính xác hơn"; (c) "Code review quá chậm".
- Thiết kế một Retro online. Bạn có một đội 7 người phân tán ở ba thành phố, văn hóa hơi ngại phát biểu. Hãy phác thảo một kịch bản Retrospective 90 phút gồm: format chọn dùng, cách thu thập dữ liệu chống im lặng, cách bỏ phiếu chọn ưu tiên, và cách chốt action item.
- Góc nhìn của PO. Viết ra ba câu hỏi mà bạn — với tư cách PO — sẽ chủ động mời đội phản hồi về cách làm việc của mình trong buổi Retrospective tới.
Tóm tắt
Sprint Retrospective là cơ chế tự cải tiến của Scrum — sự kiện duy nhất mà đội dừng lại để học từ chính mình. Bỏ nó đi, đội mất khả năng tiến hóa và sẽ lặp lại sai lầm mãi mãi.
Những điều cốt lõi cần nhớ: Retrospective xoay quanh con người và quy trình, không phải sản phẩm; nó cần an toàn tâm lý làm nền móng, được bảo vệ bởi Prime Directive; một buổi tốt đi qua 5 giai đoạn (Set the Stage → Gather Data → Generate Insights → Decide → Close), và đừng bao giờ nhảy cóc bỏ qua bước đào nguyên nhân gốc. Hãy chọn format linh hoạt, giới hạn 1–3 action item có owner và deadline, rồi thực sự theo dõi chúng ở Sprint sau.
Với vai trò Product Owner, hãy nhớ ba điều: luôn có mặt, đến với tâm thế đồng đội cùng cải tiến chứ không phải khách hàng đòi nợ, và chủ động mời phản hồi cho chính mình. Cho phép "công việc cải tiến" có chỗ đứng trong backlog là một trong những đóng góp quan trọng nhất của bạn cho sức khỏe lâu dài của đội. Một đội biết Retrospective tử tế là một đội mỗi Sprint lại tốt hơn một chút — và những "một chút" đó cộng dồn lại tạo nên khác biệt khổng lồ theo thời gian.