Mở đầu — vì sao bài này quan trọng
Nếu bạn hỏi mười Scrum Team rằng event nào hay bị cắt bỏ đầu tiên khi áp lực deadline dồn dập, câu trả lời phổ biến nhất sẽ là Sprint Retrospective. Người ta xem nó như một buổi "ngồi nói chuyện" xa xỉ, không trực tiếp tạo ra tính năng, không giao được cho khách hàng. Đây chính là hiểu lầm tai hại nhất trong Scrum, và là cái bẫy mà đề thi PSPO I rất thích đặt ra để kiểm tra xem bạn có thực sự hiểu bản chất empirical (thực nghiệm) của Scrum hay không.
Với một Product Owner, Sprint Retrospective có vẻ là sân chơi của Scrum Master và Developers. Nhiều PO nghĩ rằng Retrospective bàn về "cách làm việc nội bộ" nên không liên quan đến mình. Nhưng nếu bạn nghĩ kỹ: chất lượng và hiệu quả làm việc của team chính là thứ quyết định bao nhiêu giá trị được tạo ra mỗi Sprint. Một team cải tiến liên tục sẽ giao được nhiều giá trị hơn, nhanh hơn, ít lỗi hơn — và đó chính xác là mục tiêu sống còn của PO. Vì vậy, hiểu sâu Retrospective không chỉ giúp bạn vượt qua các câu hỏi trong kỳ thi mà còn giúp bạn trở thành một PO biết tận dụng cơ chế cải tiến của Scrum để tối đa hóa value.
Trong bài này, chúng ta sẽ đi sâu vào định nghĩa chính xác theo Scrum Guide 2020, vai trò của từng thành viên (đặc biệt là Product Owner), timebox, và cách biến một buổi Retrospective hình thức thành một động cơ cải tiến thực sự.
Khái niệm cốt lõi
Định nghĩa theo Scrum Guide 2020
Sprint Retrospective là event cuối cùng trong một Sprint. Theo Scrum Guide 2020, mục đích của nó được phát biểu rất cô đọng: "The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness" — tức là lập kế hoạch để tăng chất lượng và hiệu quả.
Hãy chú ý cách diễn đạt này. Scrum Guide 2020 đã đơn giản hóa và mở rộng phạm vi của Retrospective so với các phiên bản trước. Trước đây người ta hay nói Retrospective tập trung vào "con người, mối quan hệ, quy trình và công cụ". Phiên bản 2020 nâng tầm lên thành hai từ khóa bao trùm: quality (chất lượng) và effectiveness (hiệu quả). Đây là chi tiết mà đề thi PSPO I rất hay khai thác.
Trong buổi này, Scrum Team kiểm tra (inspect) Sprint vừa qua trên các khía cạnh: cá nhân, sự tương tác, quy trình, công cụ, và Definition of Done. Việc Definition of Done được nêu tên cụ thể trong Scrum Guide 2020 rất đáng lưu ý — nó hàm ý rằng team có thể bàn về việc nâng chuẩn chất lượng đầu ra ngay tại Retrospective.
Khi nào diễn ra và kéo dài bao lâu
Sprint Retrospective diễn ra sau Sprint Review và trước khi kết thúc Sprint. Thứ tự này rất logic: Sprint Review nhìn vào sản phẩm và thị trường (cái gì đã làm, phản hồi của stakeholder, hướng đi tiếp theo), còn Retrospective nhìn vào cách team làm việc với nhau (làm như thế nào). Bạn cần xem xong "kết quả" trước khi mổ xẻ "cách thức tạo ra kết quả đó".
Về timebox: Retrospective được giới hạn tối đa 3 giờ cho một Sprint kéo dài một tháng (4 tuần). Với các Sprint ngắn hơn, event này thường ngắn hơn tương ứng. Ví dụ Sprint hai tuần thì Retrospective thường gói gọn trong khoảng 1,5 giờ. Hãy ghi nhớ con số này — đề thi rất thích hỏi về timebox của từng event.
Ai tham gia và Retrospective thuộc về ai
Đây là điểm mấu chốt mà nhiều người hiểu sai. Sprint Retrospective là event của toàn bộ Scrum Team, gồm: Product Owner, Scrum Master và Developers. Cả ba accountability đều tham dự.
- Developers thường là trọng tâm vì họ trực tiếp thực thi công việc, nhưng họ không phải là người duy nhất.
- Scrum Master tham gia với tư cách thành viên của Scrum Team, đồng thời thường đảm nhận vai trò facilitator (người điều phối) để buổi họp hiệu quả. Lưu ý: Scrum Guide 2020 không bắt buộc Scrum Master phải facilitate, nhưng đây là vai trò tự nhiên của họ.
- Product Owner THAM GIA Retrospective. Đây là điều bạn phải khắc cốt ghi tâm. Nhiều PO tự loại mình ra với lý do "đây là chuyện của team kỹ thuật". Sai. PO là một phần của Scrum Team, và cách PO tương tác với Developers (ví dụ: chất lượng của Product Backlog Item, cách trả lời câu hỏi, cách refinement) hoàn toàn nằm trong phạm vi cải tiến của Retrospective.
Đầu ra của Retrospective
Không giống một buổi "than thở cho nhẹ lòng", Retrospective phải tạo ra hành động cụ thể. Scrum Team xác định những cải tiến hữu ích nhất và lý tưởng là đưa ngay vào Sprint Backlog của Sprint kế tiếp. Đây là cách đảm bảo cải tiến không bị lãng quên. Trong nhiều phiên bản trước có nói về việc thêm ít nhất một "process improvement item" vào Sprint sau; Scrum Guide 2020 không bắt buộc cứng nhưng vẫn khuyến khích mạnh việc hành động hóa các cải tiến.
Quan hệ với Empiricism và Scrum Values
Retrospective chính là biểu hiện rõ ràng nhất của trụ cột Adaptation (thích nghi) trong ba trụ cột empirical: Transparency, Inspection, Adaptation. Team minh bạch về những gì đã xảy ra, kiểm tra nó, rồi điều chỉnh cách làm. Đồng thời, nó đòi hỏi các giá trị Scrum như Openness (cởi mở) để nói thật, Courage (dũng cảm) để nêu vấn đề khó, và Respect (tôn trọng) để góp ý mà không công kích cá nhân.
Tình huống thực tế
Tình huống 1: Công ty fintech tại TP.HCM cắt Retrospective vì "bận"
Một công ty fintech tại Quận 1, TP.HCM có một Scrum Team 7 người làm sản phẩm ví điện tử. Trong giai đoạn nước rút trước Tết, team chạy 3 Sprint liên tiếp và quyết định bỏ qua Retrospective để "tập trung code, lấy lại tiến độ". Product Owner đồng tình vì nghĩ thời gian đó nên dành cho phát triển tính năng.
Kết quả sau 6 tuần: cùng một loại lỗi tích hợp với cổng thanh toán xuất hiện lặp lại ở cả ba Sprint, mỗi lần ngốn khoảng 1,5 ngày công để xử lý. Hai Developers âm thầm bất mãn vì cảm thấy PO liên tục thêm yêu cầu giữa Sprint mà không có kênh nào để phản ánh. Velocity thực tế giảm khoảng 20% so với trước đợt nước rút, ngược hoàn toàn với kỳ vọng "tăng tốc".
Diễn giải: Khi cắt bỏ Retrospective, team mất đi cơ chế phát hiện và sửa vấn đề hệ thống. Lỗi cổng thanh toán lặp lại vì không ai ngồi lại hỏi "tại sao nó cứ xảy ra?". Sự bất mãn của Developers tích tụ vì không có không gian an toàn để nêu lên.
Bài học: Retrospective không phải là chi phí, nó là khoản đầu tư có lãi suất cao. Bỏ nó để "đi nhanh hơn" thường khiến team đi chậm lại. Một PO khôn ngoan sẽ là người bảo vệ event này, không phải người đầu tiên đề xuất cắt nó.
Tình huống 2: Sàn TMĐT giả định "ShopHaha" — Retrospective biến thành buổi đổ lỗi
"ShopHaha", một sàn thương mại điện tử giả định tại Hà Nội, có một team mà mỗi Retrospective đều biến thành phiên tòa. Khi tính năng giỏ hàng bị lỗi trên production, buổi Retrospective mở đầu bằng việc Product Owner chỉ thẳng: "Đợt rồi bạn Nam viết phần checkout ẩu quá". Nam phòng thủ, đổ ngược lại rằng yêu cầu của PO mơ hồ. Không ai đề xuất hành động nào, và buổi họp kết thúc trong không khí căng thẳng.
Scrum Master nhận ra vấn đề và thay đổi cách điều phối. Lần Retrospective sau, cô đặt ra một nguyên tắc trước khi bắt đầu (thường gọi là Prime Directive): "Mọi người đều đã làm tốt nhất có thể với thông tin, kỹ năng và nguồn lực họ có vào thời điểm đó." Cô chuyển cuộc thảo luận từ "ai sai" sang "hệ thống nào đã cho phép lỗi này lọt qua". Từ đó team phát hiện nguyên nhân thật: Definition of Done chưa bao gồm bước kiểm thử trên môi trường staging. Họ quyết định bổ sung tiêu chí này vào DoD và đưa task thiết lập môi trường staging vào Sprint Backlog kế tiếp.
Diễn giải: Retrospective thất bại khi nó trở thành sân đổ lỗi. Tâm lý phòng thủ giết chết Openness và Courage — hai giá trị cốt lõi để cải tiến. Việc reframe sang góc nhìn hệ thống giúp lộ ra nguyên nhân gốc thực sự nằm ở Definition of Done.
Bài học: Với PO, Retrospective không phải nơi để "chấm điểm" Developers. Nó là nơi cùng nhau nâng cấp cách làm việc. Và đáng chú ý: Definition of Done hoàn toàn có thể là chủ đề của Retrospective — đúng như Scrum Guide 2020 nêu tên.
Tình huống 3: Startup SaaS tại Đà Nẵng — Retrospective tạo ra cải tiến đo được
Một startup SaaS tại Đà Nẵng làm phần mềm quản lý nhà hàng có Scrum Master kỳ cựu luôn kết thúc mỗi Retrospective với đúng một cam kết hành động (action item) cụ thể, có người chịu trách nhiệm và đưa vào Sprint Backlog ngay. Một Sprint, team nhận ra Daily Scrum thường kéo dài 30-40 phút thay vì 15 phút vì lạc đề sang giải quyết vấn đề kỹ thuật. Action item: chuyển mọi cuộc thảo luận sâu sang "after-party" ngay sau Daily.
Ba Sprint sau, team đo được Daily Scrum trở về đúng 15 phút, tiết kiệm khoảng 100 phút mỗi tuần cho cả team. Quan trọng hơn, Product Owner ở team này tham gia đều đặn và một lần đã chủ động nêu: "Tôi nhận thấy mình hay thêm chi tiết yêu cầu giữa Sprint, làm Developers rối. Từ Sprint sau tôi sẽ gom chúng vào buổi refinement." Đây là một cải tiến đến từ chính PO.
Diễn giải: Sức mạnh của Retrospective nằm ở tính hành động và tính nhất quán. Một cải tiến nhỏ nhưng được thực thi đều đặn sẽ tạo hiệu ứng cộng dồn theo thời gian.
Bài học: Một Retrospective tốt luôn kết thúc bằng hành động cụ thể, không phải bằng danh sách "lần sau cố gắng hơn". Và PO tự soi mình cũng là một phần của cải tiến team.
Hướng dẫn từng bước
Dù Scrum không quy định một quy trình cứng cho Retrospective, có một cấu trúc kinh điển (do Esther Derby và Diana Larsen đề xuất) rất hữu ích để bạn vận hành buổi họp hiệu quả:
- Set the Stage (Mở màn). Tạo không gian an toàn để mọi người dám nói thật. Đọc lại Prime Directive, nhắc rằng mục tiêu là cải tiến chứ không phải đổ lỗi. Một câu hỏi khởi động đơn giản như "Một từ mô tả cảm giác của bạn về Sprint vừa rồi?" giúp mọi người mở lời.
- Gather Data (Thu thập dữ liệu). Cùng nhìn lại Sprint một cách khách quan: timeline sự kiện, các chỉ số (velocity, số lỗi, số lần thay đổi scope), và cả cảm xúc. Mục tiêu là dựng lại bức tranh chung, đảm bảo Transparency. PO đóng góp góc nhìn về giá trị giao được và phản hồi stakeholder từ Sprint Review.
- Generate Insights (Tìm hiểu nguyên nhân). Đây là phần quan trọng nhất. Đừng dừng ở triệu chứng, hãy đào nguyên nhân gốc. Kỹ thuật "5 Whys" (hỏi tại sao 5 lần) rất hiệu quả. Ví dụ: lỗi lọt production → tại sao? → không test staging → tại sao? → DoD không yêu cầu → tại sao?...
- Decide What to Do (Quyết định hành động). Chọn ra 1-2 cải tiến khả thi và tác động cao nhất. Đừng tham lam chọn mười việc rồi không làm việc nào. Mỗi action item cần có người chịu trách nhiệm và lý tưởng là đưa vào Sprint Backlog kế tiếp.
- Close the Retrospective (Kết thúc). Tóm tắt cam kết, cảm ơn nhau, và đôi khi thực hiện một "retrospective của retrospective" ngắn để cải tiến chính buổi họp này.
Lỗi thường gặp & mẹo
Lỗi 1 — Tưởng Retrospective là event của riêng Developers. Trong kỳ thi PSPO I, nếu gặp câu hỏi "Ai tham gia Sprint Retrospective?", đáp án đúng là toàn bộ Scrum Team, bao gồm cả Product Owner. Đừng bao giờ chọn đáp án loại PO ra.
Lỗi 2 — Nhầm lẫn Sprint Review với Sprint Retrospective. Đây là cặp đôi gây nhầm lẫn kinh điển. Sprint Review nhìn vào sản phẩm và điều chỉnh Product Backlog (cùng stakeholder). Sprint Retrospective nhìn vào cách làm việc và điều chỉnh quy trình (chỉ trong nội bộ Scrum Team, không có stakeholder bên ngoài). Review trả lời "chúng ta đã xây gì?", Retrospective trả lời "chúng ta đã làm việc với nhau như thế nào?".
Lỗi 3 — Sai timebox. Nhớ con số: tối đa 3 giờ cho Sprint một tháng. Đề thi hay đưa các con số sai như "8 giờ" hay "30 phút cố định" để gài bẫy.
Lỗi 4 — Retrospective không tạo ra hành động. Một buổi chỉ "xả" mà không có action item là Retrospective thất bại. Mẹo: giới hạn 1-2 cải tiến, gán người phụ trách, đưa vào Sprint Backlog kế tiếp để đảm bảo thực thi.
Lỗi 5 — Biến nó thành phiên đổ lỗi. Áp dụng Prime Directive và tư duy hệ thống (system thinking) thay vì chỉ trích cá nhân. PO đặc biệt cần giữ thái độ này vì lời của PO có sức nặng dễ khiến Developers phòng thủ.
Lỗi 6 — Tin rằng Retrospective có thể bị bỏ qua. Sprint Retrospective là event bắt buộc, diễn ra ở MỌI Sprint. Không có ngoại lệ. Nếu một câu hỏi gợi ý rằng team có thể bỏ Retrospective khi bận, đó là đáp án sai.
Mẹo bổ sung cho PO: Hãy xem Retrospective như cơ hội để lắng nghe Developers về chất lượng Product Backlog của bạn. Nếu Developers liên tục phàn nàn về yêu cầu mơ hồ hoặc thay đổi giữa Sprint, đó là tín hiệu trực tiếp ảnh hưởng đến value mà bạn cần điều chỉnh.
Bài tập thực hành
Bài 1 — Phân biệt event. Lập một bảng hai cột so sánh Sprint Review và Sprint Retrospective theo các tiêu chí: mục đích, ai tham gia (có stakeholder hay không), đối tượng được điều chỉnh (Product Backlog hay quy trình), và timebox. Đây là kỹ năng cốt lõi để không bị gài trong đề thi.
Bài 2 — Áp dụng 5 Whys. Lấy một vấn đề bạn từng gặp trong công việc (ví dụ: "khách hàng không dùng tính năng vừa ra mắt") và đào nguyên nhân gốc bằng 5 lần hỏi "tại sao". Viết ra chuỗi nhân quả và đề xuất một action item cụ thể có thể đưa vào Sprint Backlog.
Bài 3 — Tự soi với vai trò PO. Hãy liệt kê 3 hành vi của một Product Owner có thể làm giảm hiệu quả của Developers (ví dụ: thêm scope giữa Sprint, acceptance criteria mơ hồ, chậm trả lời câu hỏi). Với mỗi hành vi, viết một cải tiến mà bạn — với tư cách PO — sẽ cam kết tại Retrospective.
Bài 4 — Câu hỏi tự kiểm tra kiểu PSPO I. Trả lời nhanh: (a) Retrospective diễn ra trước hay sau Sprint Review? (b) Product Owner có tham gia không? (c) Timebox tối đa cho Sprint một tháng là bao nhiêu? (d) Đầu ra lý tưởng của Retrospective nên được đưa vào đâu? Đối chiếu đáp án với phần Khái niệm cốt lõi.
Tóm tắt
Sprint Retrospective là event cuối cùng của Sprint, diễn ra sau Sprint Review, với mục đích duy nhất theo Scrum Guide 2020: lập kế hoạch để tăng chất lượng và hiệu quả (quality and effectiveness). Toàn bộ Scrum Team tham gia — Product Owner, Scrum Master và Developers — và team kiểm tra mọi khía cạnh gồm cá nhân, tương tác, quy trình, công cụ và cả Definition of Done. Timebox tối đa là 3 giờ cho Sprint một tháng.
Đây là hiện thân rõ nhất của trụ cột Adaptation trong empiricism: minh bạch, kiểm tra, rồi điều chỉnh cách làm. Một Retrospective tốt luôn kết thúc bằng 1-2 cải tiến cụ thể, có người phụ trách, được đưa vào Sprint Backlog kế tiếp để đảm bảo thực thi.
Với riêng Product Owner: đừng tự loại mình khỏi event này. Cách bạn quản lý Product Backlog, làm rõ yêu cầu và tương tác với Developers đều ảnh hưởng trực tiếp đến giá trị giao được — và tất cả đều là chủ đề chính đáng tại Retrospective. Hãy là người bảo vệ event này, không phải người đầu tiên đề xuất cắt nó. Trong kỳ thi PSPO I, hãy nhớ ba cái bẫy phổ biến: PO luôn tham gia, đừng nhầm với Sprint Review, và Retrospective không bao giờ được bỏ qua.