Mẫu thuyết trình báo cáo trạng thái dự án miễn phí cho các nhóm Agile

Một báo cáo trạng thái dự án Agile hữu ích cần cho phép các bên liên quan trả lời nhanh chóng bốn câu hỏi: Chúng ta có đang tiến tới mục tiêu sản phẩm không? Giá trị sử dụng được nào đã được cung cấp? Điều gì đang đe dọa kết quả tiếp theo? Cần ra quyết định hoặc hỗ trợ gì ngay bây giờ? Nếu một bài thuyết trình không thể trả lời những câu hỏi đó trong vài phút, việc thêm nhiều biểu đồ thường chỉ làm cho nó dài hơn chứ không tốt hơn.

Đối với hầu hết các nhóm Agile, một bộ slide trạng thái gồm bảy trang là đủ: trạng thái tổng quan, mục tiêu và kết quả, tiến độ, rủi ro và trở ngại, phạm vi và thay đổi, chất lượng/sẵn sàng phát hành, và các hành động hoặc quyết định tiếp theo. Mẫu dưới đây được thiết kế cố tình ngắn gọn. Nó nhằm mục đích cải thiện tính minh bạch cho các bên liên quan, chứ không thay thế Sprint Review, Daily Scrum, product backlog hoặc các công cụ làm việc khác.

Tính đến ngày 11 tháng 9 năm 2026, phiên bản chính thức hiện hành của Scrum Guide vẫn là phiên bản tháng 11 năm 2020. Tài liệu này nhấn mạnh vào tính minh bạch, việc kiểm tra thường xuyên tiến độ hướng tới các mục tiêu đã thỏa thuận và sự thích ứng khi kết quả hoặc điều kiện thay đổi. Nó cũng nói rằng Sprint Review là một phiên làm việc mà trong đó Nhóm Scrum và các bên liên quan kiểm tra các kết quả và xác định những việc cần làm tiếp theo—chứ không chỉ đơn thuần là một bài thuyết trình. Xem Scrum Guide chính thức.

Một bộ slide trạng thái chất lượng cao cần đạt được điều gì

Bộ slide thành công khi mọi người rời đi với một cái nhìn chung về thực tế và một số ít các hành động rõ ràng. Nó không thành công chỉ vì mỗi slide đều được lấp đầy nội dung.

Điều này phù hợp với nguyên tắc của Tuyên ngôn Agile rằng phần mềm hoạt động được là thước đo chính của tiến độ. Đối với các nhóm tạo ra thứ gì đó khác với phần mềm, hãy sử dụng cùng ý tưởng cơ bản: nhấn mạnh vào một phần gia tăng hoặc kết quả có thể sử dụng và xác minh được thay vì chỉ nhấn mạnh vào hoạt động. Xem Các nguyên tắc đằng sau Tuyên ngôn Agile.

Mẫu báo cáo trạng thái dự án Agile miễn phí: Cấu trúc 7 slide

Slide 1: Trạng thái dự án tổng quan

Bắt đầu với thông tin mà một bên liên quan bận rộn cần trước bất kỳ điều gì khác:

• Tên sản phẩm hoặc dự án
• Kỳ báo cáo hoặc số Sprint
• Mục tiêu Sản phẩm hoặc mục tiêu chính
• Mục tiêu Sprint
• Trạng thái tổng thể với một lời giải thích ngắn gọn
• Một đến ba rủi ro hàng đầu
• Một câu về những gì đã thay đổi kể từ báo cáo trước

Nếu bạn sử dụng trạng thái đỏ/vàng/xanh, hãy định nghĩa ý nghĩa của chúng. “Vàng” có thể có nghĩa là Mục tiêu Sprint vẫn có thể đạt được nhưng một phụ thuộc có thể ảnh hưởng đáng kể đến thời gian. Một màu sắc mà không có tiêu chí sẽ trở nên chủ quan và có thể khuyến khích sự lạc quan về trạng thái.

Kiểm tra chất lượng: một bên liên quan chỉ đọc slide này nên hiểu được hướng đi hiện tại và mối quan tâm quan trọng nhất.

Slide 2: Mục tiêu, kết quả cho khách hàng và giá trị đã cung cấp

Cho thấy những gì nhóm đang cố gắng đạt được và những gì đã thay đổi đối với người dùng, khách hàng hoặc doanh nghiệp. Slide này có giá trị hơn một danh sách “các nhiệm vụ đã hoàn thành” dài.

Một cấu trúc đơn giản là:

Trong Scrum, một Phần gia tăng (Increment) phải có thể sử dụng được và phải đáp ứng Định nghĩa Hoàn thành (Definition of Done) trước khi nó được coi là một phần của Phần gia tăng. Đó là một điểm neo tốt hơn cho trạng thái so với việc đếm các mục backlog chưa hoàn thành một phần như thể chúng cung cấp giá trị tương đương. Scrum Guide định nghĩa Định nghĩa Hoàn thành là mô tả chính thức về trạng thái của Phần gia tăng khi nó đáp ứng các tiêu chuẩn chất lượng bắt buộc của sản phẩm.

Kiểm tra chất lượng: phân biệt rõ ràng giữa “đã xong”, “đang thực hiện” và “đã lên kế hoạch”. Không mô tả công việc là đã cung cấp nếu nó chưa đáp ứng Định nghĩa Hoàn thành của nhóm.

Slide 3: Tiến độ Sprint và dự báo

Chỉ sử dụng một hoặc hai hình ảnh trực quan về tiến độ nếu chúng giúp ích cho việc ra quyết định. Scrum Guide công nhận các thực hành như burn-down, burn-up và dòng chảy tích lũy là các kỹ thuật dự báo hữu ích, đồng thời lưu ý rõ ràng rằng chúng không thay thế chủ nghĩa thực nghiệm.

Các lựa chọn hữu ích bao gồm:

• Biểu đồ Burn-up: hữu ích khi phạm vi thay đổi và bạn muốn hiển thị công việc đã hoàn thành so với tổng phạm vi.
• Biểu đồ Burn-down: hữu ích để trực quan hóa công việc còn lại trong một Sprint hoặc dự báo phát hành có giới hạn.
• Dòng chảy tích lũy: hữu ích khi bạn cần phơi bày công việc đang thực hiện (WIP) đang tăng lên hoặc một nút thắt cổ chai trong quy trình làm việc.
• Bảng kết quả đơn giản: thường tốt hơn biểu đồ đối với các nhóm nhỏ hoặc khán giả là lãnh đạo.

Tránh thêm tốc độ (velocity) chỉ vì các bài thuyết trình Agile được mong đợi là phải chứa biểu đồ. Scrum Guide không định nghĩa velocity là một chỉ số Scrum bắt buộc. Nếu nhóm của bạn sử dụng nó để dự báo, hãy giải thích con số đó đại diện cho điều gì và so sánh nó với lịch sử của chính nhóm thay vì coi nó như một điểm năng suất phổ quát.

Kiểm tra chất lượng: biểu đồ nên trả lời một câu hỏi. Nếu việc loại bỏ nó không thay đổi sự hiểu biết hoặc quyết định của bất kỳ ai, hãy loại bỏ nó.

Slide 4: Rủi ro, trở ngại và phụ thuộc

Đây thường là slide liên quan nhất đến việc ra quyết định. Phân biệt ba khái niệm:

• Rủi ro: một sự kiện hoặc điều kiện trong tương lai có thể tạo ra vấn đề.
• Trở ngại: điều gì đó hiện đang cản trở tiến độ.
• Phụ thuộc: công việc, thông tin hoặc năng lực cần thiết từ một nhóm khác, nhà cung cấp, hệ thống hoặc người ra quyết định.

Sử dụng các cột như:

Scrum đánh giá cao sự cởi mở về công việc và các thách thức, và Scrum Master chịu trách nhiệm giúp loại bỏ các trở ngại đối với tiến độ của nhóm. Một bộ slide trạng thái che giấu các rủi ro khó chịu đi ngược lại tính minh bạch cần thiết cho việc kiểm tra hữu ích.

Kiểm tra chất lượng: mọi trở ngại quan trọng nên có một người chịu trách nhiệm hoặc một yêu cầu leo thang rõ ràng. “Nhóm đang theo dõi” hiếm khi đủ đối với một phụ thuộc quan trọng.

Slide 5: Thay đổi phạm vi và những gì nhóm đã học được

Báo cáo trạng thái Agile không nên ngụ ý rằng kế hoạch ban đầu là bất khả xâm phạm. Scrum Guide nói rằng phạm vi có thể được làm rõ và đàm phán lại với Chủ sở hữu Sản phẩm khi có thêm thông tin, miễn là Mục tiêu Sprint không bị đe dọa.

Cho thấy những thay đổi ảnh hưởng đáng kể đến kỳ vọng của các bên liên quan:

• Yêu cầu mới được phát hiện
• Mục backlog bị loại bỏ vì nó không còn đóng góp đủ giá trị
• Giả định kỹ thuật bị bác bỏ
• Phụ thuộc thay đổi
• Phản hồi của khách hàng dẫn đến việc ưu tiên lại

Sử dụng một bảng ngắn “Thay đổi / Tại sao / Tác động”. Điều này làm cho sự thích ứng trở nên hiển thị mà không buộc khán giả phải so sánh thủ công hai ảnh chụp nhanh backlog.

Kiểm tra chất lượng: giải thích xem một thay đổi ảnh hưởng đến mục tiêu, dự báo, chi phí, chất lượng hay chỉ là phương pháp triển khai.

Slide 6: Chất lượng và sẵn sàng phát hành

“Đúng tiến độ” là không đủ nếu chất lượng đang suy giảm. Bao gồm một số tín hiệu chất lượng quan trọng đối với sản phẩm. Tùy thuộc vào nhóm, điều đó có thể bao gồm:

• Tuân thủ Định nghĩa Hoàn thành
• Lỗi nghiêm trọng đang mở
• Sức khỏe của kiểm thử tự động
• Các kiểm tra bảo mật hoặc khả năng truy cập
• Xu hướng sự cố sản xuất
• Các trở ngại phát hành
• Sẵn sàng vận hành

Đừng lấp đầy slide bằng mọi chỉ số kỹ thuật có sẵn. Chọn bằng chứng gắn liền với việc Phần gia tăng có thể sử dụng được hay không và liệu các bên liên quan có thể tin tưởng hợp lý vào quyết định phát hành hay không.

Kiểm tra chất lượng: nếu bộ slide nói “xanh” trong khi một lỗi chặn phát hành vẫn chưa được giải quyết, mô hình trạng thái cần phải thay đổi.

Slide 7: Quyết định, các bước tiếp theo và người chịu trách nhiệm

Kết thúc bằng hành động, không phải một slide “Cảm ơn” chung chung. Một bảng đơn giản hoạt động tốt:

Kiểm tra chất lượng: sau bài thuyết trình, không nên có sự mơ hồ về việc ai sở hữu hành động tiếp theo có thể nhìn thấy từ bên ngoài.

Chỉ số nào thuộc về một bài thuyết trình trạng thái Agile?

Chỉ sử dụng các chỉ số khi chúng hỗ trợ việc kiểm tra và thích ứng. Một khung lựa chọn thực tế là:

Đừng biến bộ slide thành một bảng điểm của các chỉ số hư danh. Số điểm câu chuyện đã hoàn thành, số lượng vé đã đóng hoặc mức độ sử dụng đều có thể là các tín hiệu nội bộ hợp lệ trong một bối cảnh cụ thể, nhưng chúng không phải là chất thay thế cho các kết quả có thể sử dụng được. Sự nhấn mạnh của Tuyên ngôn Agile vào phần mềm hoạt động được như là thước đo chính của tiến độ là một rào chắn hữu ích ở đây.

Khi nào bài thuyết trình là công cụ sai

Một bộ slide hữu ích khi khán giả cần một bản tổng hợp định kỳ, ngắn gọn. Thay đổi cách tiếp cận khi:

• Các bên liên quan cần dữ liệu vận hành thời gian thực; hãy sử dụng một bảng điều khiển trực tiếp.
• Nhóm cần phối hợp công việc hôm nay; hãy sử dụng Daily Scrum và Sprint Backlog hiện tại.
• Khán giả cần kiểm tra Phần gia tăng thực tế; hãy trình diễn nó thay vì mô tả nó trên các slide.
• Nhóm đang thảo luận lý do quy trình của họ thất bại; hãy sử dụng Sprint Retrospective.
• Cần sắp xếp backlog chi tiết; hãy làm việc trực tiếp trong backlog hoặc hệ thống quản lý sản phẩm.

Scrum Guide đặc biệt rõ ràng rằng Sprint Review không nên bị giới hạn trong một bài thuyết trình. Một bộ slide trạng thái dự án có thể chuẩn bị cho các bên liên quan và tóm tắt bối cảnh, nhưng nó không nên thay thế việc kiểm tra cộng tác về sản phẩm và thảo luận về những việc cần làm tiếp theo.

Bạn nên cập nhật bộ slide thường xuyên như thế nào?

Phù hợp nhịp độ báo cáo với các quyết định mà khán giả cần đưa ra. Nhiều nhóm cập nhật trạng thái một lần mỗi Sprint, trong khi các chương trình có nhiều phụ thuộc đáng kể có thể cần một bản tóm tắt hàng tuần ngắn hơn. Báo cáo thường xuyên hơn không tự động minh bạch hơn nếu bộ slide chỉ đơn giản lặp lại dữ liệu của ngày hôm qua.

Một quy tắc hữu ích là: cập nhật khi thông tin có thể thay đổi quyết định của bên liên quan, dự báo hoặc phản ứng rủi ro. Giữ ngày nguồn hiển thị trên mọi chỉ số không phải là dữ liệu trực tiếp.

Các quy tắc thiết kế cải thiện khả năng đọc

PowerPoint hỗ trợ bắt đầu từ một mẫu đã chuẩn bị cũng như một bài thuyết trình trống, và Microsoft khuyến nghị sử dụng các mẫu khi bạn muốn một sự sắp xếp nhất quán về bố cục, phông chữ, màu sắc và hiệu ứng. Xem hướng dẫn thuyết trình PowerPoint của Microsoft.

Đối với một bộ slide trạng thái:

• Sử dụng một thông điệp mỗi slide.
• Ưu tiên các bảng ngắn và nhãn trực tiếp hơn là các đoạn văn dày đặc.
• Hiển thị kỳ báo cáo và ngày dữ liệu.
• Giữ các màu trạng thái nhất quán và định nghĩa chúng.
• Sử dụng văn bản lớn vẫn dễ đọc trong phòng họp.
• Không chỉ dựa vào màu sắc để truyền tải rủi ro; hãy thêm văn bản hoặc biểu tượng.
• Liên kết đến hệ thống nguồn khi cần chi tiết sâu hơn.

Nếu bạn muốn tái sử dụng bộ slide, Microsoft cũng hỗ trợ lưu một bài thuyết trình tùy chỉnh dưới dạng mẫu PowerPoint (.potx) để cùng một cấu trúc có thể được sử dụng cho các báo cáo trong tương lai. Xem hướng dẫn tạo mẫu của Microsoft.

Làm thế nào để biết khi nào mẫu cần thay đổi

Đừng giữ nguyên các slide mãi mãi chỉ vì bộ slide có thương hiệu. Thay đổi mẫu khi thông tin của nó không còn hỗ trợ các quyết định đang được đưa ra.

Các tín hiệu bao gồm:

• Các bên liên quan liên tục yêu cầu cùng một thông tin còn thiếu.
• Các slide được sao chép nguyên vẹn qua nhiều Sprint.
• Các nhóm dành nhiều thời gian cho định dạng hơn là thảo luận về rủi ro hoặc kết quả.
• Các chỉ số khuyến khích hành vi không hữu ích, chẳng hạn như tối ưu hóa số lượng vé thay vì giá trị.
• Các mục rủi ro vẫn màu đỏ mà không có người chịu trách nhiệm hoặc hành động.
• Bộ slide trùng lặp với một bảng điều khiển trực tiếp mà không thêm bất kỳ sự diễn giải nào.
• Cuộc họp trở thành một bài thuyết trình một chiều thay vì kiểm tra và thích ứng.

Một mẫu hữu ích nên giảm nỗ lực báo cáo theo thời gian, không tạo ra một hệ thống quản lý dự án thứ hai phải được duy trì thủ công.

Giới hạn của mẫu báo cáo trạng thái miễn phí này

Cấu trúc này hoạt động tốt cho một nhóm Agile nhỏ, một luồng sản phẩm đơn lẻ, hoặc một bản tóm tắt điều hành của một sáng kiến lớn hơn. Nó ít phù hợp hơn khi một chương trình chứa nhiều sản phẩm, các cổng giai đoạn được quản lý chặt chẽ, báo cáo giá trị thu được theo hợp đồng, tài chính danh mục phức tạp, hoặc hàng tá phụ thuộc giữa các nhóm. Trong những trường hợp đó, bộ slide bảy trang có thể vẫn là bản tóm tắt điều hành, nhưng quản trị chi tiết nên nằm trong các hệ thống nguồn và kiểm soát chương trình phù hợp.

Nó cũng không quy định một bộ chỉ số Agile phổ quát. Scrum cố tình nhẹ nhàng, và Scrum Guide lưu ý rằng các kỹ thuật và chiến thuật có thể khác nhau rộng rãi tùy theo bối cảnh. Chọn bộ bằng chứng nhỏ nhất làm cho trạng thái thực tế của công việc đủ hiển thị để đưa ra các quyết định tốt.

Danh sách kiểm tra chất lượng cuối cùng

• Mục tiêu Sản phẩm và Mục tiêu Sprint là hiển thị.
• Giá trị đã cung cấp được tách biệt khỏi công việc vẫn đang thực hiện.
• Trạng thái được hỗ trợ bằng bằng chứng, không chỉ bằng màu sắc.
• Các biểu đồ dự báo có một mục đích rõ ràng.
• Rủi ro, trở ngại và phụ thuộc được phân biệt.
• Các thay đổi đáng kể về phạm vi hoặc giả định được giải thích.
• Bằng chứng về chất lượng và sẵn sàng phát hành được bao gồm khi liên quan.
• Mọi quyết định hoặc leo thang được yêu cầu đều có người chịu trách nhiệm và ngày tháng.
• Bộ slide đủ ngắn gọn để thảo luận thay vì đọc to.
• Bài thuyết trình bổ sung—chứ không thay thế—các sự kiện Scrum và các công cụ trực tiếp của nhóm.

Một bài thuyết trình trạng thái dự án Agile mạnh mẽ cuối cùng là một công cụ hỗ trợ ra quyết định. Nó làm cho thực tế hiện tại của nhóm trở nên hiển thị, kết nối tiến độ với các mục tiêu và kết quả có thể sử dụng, phơi bày rủi ro đủ sớm để hành động, và kết thúc bằng các bước tiếp theo rõ ràng. Nếu bộ slide làm được điều đó với năm slide thay vì bảy, hãy dùng năm. Nếu một bảng điều khiển trực tiếp làm cho một slide trở nên thừa, hãy loại bỏ nó. Mẫu nên phục vụ tính minh bạch và sự thích ứng—không trở thành một nghi lễ khác mà nhóm phải nuôi dưỡng.