Sprint Review: Họp Sơ kết là như thế nào?

Theo khung quản lý dự án Scrum, mỗi Sprint luôn bao gồm 4 sự kiện: Sprint Planning, Daily Scrum, Sprint Review và Sprint Retrospective. Cả 4 sự kiện đều đóng vai trò quan trọng như nhau cho sự thành công của một Sprint.

Trong nội dung sau đây, hãy cùng tìm hiểu kỹ hơn về sự kiện thứ 3: Sprint Review và cách thức tổ chức một buổi Sprint Review hiệu quả!

Sprint Review là gì?

Sprint Review (Sơ kết Sprint) là sự kiện diễn ra ở cuối Sprint nhằm thanh tra và thích nghi với sản phẩm đang được xây dựng. Theo Scrum Guide, sự kiện này bao gồm 2 hoạt động chính: dùng thử sản phẩm và thảo luận về tình hình của sản phẩm; xác định hướng đi tiếp theo và những điều chỉnh đối với sản phẩm nếu cần thiết.

Nói cách khác, Sprint Review là dịp để Scrum Team cùng các bên liên quan (Stakeholders) xem xét và cập nhật thông tin sản phẩm. Thông thường, thành phần khách mời tham dự buổi sơ kết Sprint được quyết định bởi Product Owner (PO).

• Lầm tưởng: Sprint Review là một buổi demo sản phẩm?
• Thực chất: Demo chỉ là một phần trong buổi Sprint Review. Hoạt động chính của Sprint Review là đánh giá kết quả sản phẩm chuyển giao trong Sprint; thu thập phản hồi và điều chỉnh những vấn đề tồn đọng (nếu có).

Thành phần tham dự

• Bắt buộc: Nhóm phát triển dự án (Development Team), Scrum Master, PO.
• Không bắt buộc: Khách hàng và các bên liên quan.

Tuy rằng khách hàng không nhất thiết tham gia buổi sơ kết Sprint, nhưng sự hiện diện của khách hàng sẽ giúp Scrum team nhận được thêm nhiều feedback để có sự điều chỉnh thích ứng cho sản phẩm. Sự cộng tác giữa Scrum team và khách hàng/các bên liên quan càng hiệu quả thì quá trình phát triển sản phẩm càng tối ưu.

Thời lượng

Đối với Sprint có độ dài 1 tháng, thời lượng tối đa của sự kiện Sprint Review là 4 giờ. Tương ứng, với Sprint tuần, thời lượng của buổi Sprint Review là 1 giờ.

Diễn biến của một buổi Sprint Review

• Đánh giá mục tiêu Sprint: PO cập nhật tình trạng của các hạng mục công việc đã lựa chọn Sprint (Product Backlog); đánh giá công việc đã hoàn thành hành chưa, mức độ hoàn thành như thế nào.
• Chia sẻ về Sprint đã hoàn thành: theo Scrum Guide, tất cả cần minh bạch. Vì thế, Nhóm phát triển dự án có thể thẳng thắn trình bày về quá trình triển khai công việc, những thách thức đã gặp phải và phương hướng giải quyết.
• Trải nghiệm sản phẩm: nhóm phát triển demo, giới thiệu tính năng, phần tăng trưởng của sản phẩm vừa mới hoàn thành. Sau đó, toàn bộ người tham gia buổi họp sẽ trực tiếp trải nghiệm những tính năng này.
• Thảo luận và đóng góp ý kiến: tất cả các thành viên cùng thảo luận và đóng góp ý kiến cho sản phẩm. PO và Nhóm phát triển sẽ tiếp nhận, trả lời những câu hỏi, thu thập góp ý từ người dùng và các bên liên quan.
• Cập nhật Product Backlog: sau khi đã thống nhất về những gì cần thay đổi hoặc điều chỉnh, Scrum team sẽ cập nhật các hạng mục cần làm cho Sprint tiếp theo.

Những vấn đề phát sinh thường gặp trong buổi Sprint Review

Vấn đề 1: Không nhận được phản hồi từ khách hàng và các bên liên quan

Mục đích chính của Sprint Review là thu thập phản hồi, nhưng chắc hẳn sẽ có những trường hợp khách hàng, các bên liên quan không tham gia; hoặc tham gia nhưng không có phản hồi. Lúc này, Scrum Master cần làm tốt vai trò điều phối, chủ động đặt câu hỏi, thúc đẩy các thành viên tham gia đưa ra ý kiến. Bên cạnh đó, cũng cần tìm ra nguyên nhân không nhận được phản hồi từ khách hàng.

Ví dụ: Nhóm phát triển là người Việt trong khi đó, PO và khách hàng là người Nhật khiến ngôn ngữ trở thành vấn đề rào cản. Nhóm phát triển trình bày bằng tiếng Việt nhưng communicator (phiên dịch viên) truyền đạt lại không đủ ý, dẫn đến khách hàng không nắm được đầy đủ thông tin sản phẩm.

→ Có thể cải thiện bằng cách để communicator trực tiếp demo với khách hàng thay vì chỉ đóng vai trò phiên dịch. Với phương án này, communicator đã phải được training kỹ về nghiệp vụ, trình tự demo trước đó.

Vấn đề 2: Sprint Review bị biến thành dịp khen/chê nhóm

Việc các bên liên quan sử dụng buổi họp sơ kết để phê bình năng suất làm việc của nhóm không phải là chuyện hiếm gặp. Để không bị động trước tình huống này, nhóm cần chỉ định ra một người đóng vai trò điều phối – thường là Scrum Master. Người điều phối sẽ dẫn dắt cuộc họp theo đúng lịch trình, không bị chệch hướng ra các chủ đề ngoài phạm vi thảo luận.

Vậy làm thế nào để buổi Sprint Review diễn ra hiệu quả?

Dưới đây là một số kinh nghiệm được đúc kết từ thực tế và chia sẻ bởi chuyên gia Agile Nguyễn Thế Nghị (Agile Coache, Squad Leader của Học viện Agile Phương Nam):

• Có một người điều phối, dẫn dắt cuộc họp
• Các quan điểm, góc nhìn về sản phẩm cần được chia sẻ thẳng thắn – cho dù đó là quan điểm bất đồng.
• Không trình bày những hạng mục Product Backlog chưa “hoàn thành”.
• PO nên sử dụng các kỹ thuật kiểm thử chấp nhận để đánh giá tính năng.

Bài viết thuộc series Agile 101. Nhấn vào đây hoặc hashtag agile 101 bên dưới để xem thêm các bài viết khác liên quan.