Hoạt động hiển nhiên phải có trong một buổi Sơ kết Sprint là trình diễn các chức năng đã hoàn thành trong Sprint đó. Nhưng một buổi Sơ kết Sprint tốt còn cần nhiều hoạt động khác nữa. Hãy thử xem xét các hoạt động trong một lịch trình của buổi Sơ kết Sprint dưới đây.

Chào mừng và giúp người tham gia sẵn sàng

Product Owner bắt đầu bằng lời chào mừng mọi người tham gia buổi Sơ kết Sprint. Có thể chỉ là một câu đơn giản: “Cám ơn mọi người vì đã có mặt ở đây.”

Nếu người tham gia chưa biết nhau, Product Owner có thể để mọi người tự giới thiệu ngắn về bản thân. Việc này đặc biệt cần thiết khi bắt đầu phát triển một sản phẩm mới. Chẳng hạn: Product Owner thì biết Joe là ở phòng marketing nhưng những thành viên khác thì không biết.

Việc giới thiệu cũng có ích khi có người lạ trong buổi Sơ kết Sprint. Có thể là Joe của phòng marketing chỉ tham gia hai buổi Sơ kết của hai Sprint có chức năng liên quan đến marketing.

Lời giới thiệu nên cực ngắn gọn. “Chào, Mình là Mike, lập trình viên. Mình đang làm chức năng giỏ hàng.” là đủ. Thi thoảng, chỉ cần “Mình là Mike và mình là lập trình viên” cũng đủ. Nhưng khi nhóm có nhiều người thì giới thiệu thêm một chút sẽ giúp các bên liên quan biết rõ ai đang làm gì.

Sau lời chào mừng đầu tiên của Product Owner và những lời giới thiệu cần phải có, Product Owner có thể nêu ra những qui tắc hoặc mong đợi về buổi Sơ kết Sprint. Ví dụ, vài Product Owner thấy rằng cần phải đưa ra qui tắc để giữ không khí lịch sự. Nếu ai đó không thích một chức năng thì không nên bảo nó là ngu ngốc. Mặc dù ta đều biết không nên nói vậy nhưng thỉnh thoảng vẫn phải nhắc để mọi người không bị quên.

Tùy theo số người tham gia và các yếu tố khác, Product Owner có thể nhắc mọi người: Dù mình muốn lắng nghe phản hồi về chức năng đã làm xong nhưng buổi Sơ kết Sprint không phải là lúc để thiết kế lại chức năng.

Sau lời chào mừng, (những) lời giới thiệu và những qui tắc căn bản, ta có thể tiếp tục với hoạt động tiếp theo của lịch trình.

Liệt kê những điều sẽ được/không được trình diễn.

Sau lời chào mừng, nhiều nhóm sẽ lập tức chuyển sang phần trình diễn chức năng. Tuy nhiên, người Product Owner nên giới thiệu tóm tắt về những chức năng sẽ được trình diễn và điều gì sẽ không được trình diễn.

Để tránh việc người tham gia không thể theo kịp Product Owner, nên cho danh sách các chức năng lên máy chiếu hoặc in ra cho những người tham gia.

Mike Cohn- founder of Mountain Goat Software cho biết “Tôi thích chuẩn bị danh sách này thành một file word và email cho mọi người vào cuối giờ làm của ngày hôm trước. Như vậy mọi người sẽ biết chức năng gì được trình diễn. Từ đó có thể đưa ra quyết định có cần phải tham gia buổi Sơ kết hay không. Tôi thích đưa danh sách có những thông tin như bảng dưới đây. Thứ tự danh sách nên theo thứ tự trình diễn, dù có thể thay đổi thứ tự này trong buổi Sơ kết.

Danh sách bắt đầu bằng cột miêu tả một hạng mục. Đưa User Story hoặc những miêu tả khác vào đó. Tiếp theo là độ lớn, thường sẽ tính bằng story point. Sau đó là trạng thái. Hầu hết trạng thái là đã hoàn thành hay chưa, nhưng cũng có thể là bất kì trạng thái nào cần lưu ý. Cuối cùng là cột đánh dấu là có trình diễn hay không.

Bạn có thể thắc mắc tại sao trong danh sách lại có những hạng mục mà nhóm không trình diễn. Hãy xem lại các ví dụ đó. Rõ ràng nếu hạng mục đã được đưa vào Sprint nhưng sau đó bị hủy thì không thể trình diễn. Ngoài ra còn có những sửa lỗi đơn giản kiểu thay đổi một kí tự trên màn hình cũng không được trình diễn.

Khả năng cao có người tham gia yêu cầu xem một hạng mục mà bạn không cho vào danh sách trình diễn. Nếu điều này xảy ra, hãy thoải mái trình diễn hạng mục đó. Bạn không né tránh trình diễn điều gì cả, bạn chỉ cố gắng tôn trọng thời gian của mọi người bằng cách không bắt họ xem những điều không thực sự cần phản hồi.

Để ý trong bảng trên, có trường hợp một Hạng mục Product Backlog được thêm vào giữa Sprint (MỚI THÊM), chú ý ghi rõ để phân biệt với những hạng mục được lên kế hoạch từ trước. Nếu việc thêm vào giữa Sprint xảy ra thường xuyên, ta có thể tạo thêm một cột cho mục này (điền A: Added-Mới thêm hoặc P: Planned-Theo kế hoạch).

Bạn cũng có thể thêm một cột ngoài cùng bên phải để miêu tả trạng thái của hạng muc mà nhóm quyết định trong phiên sơ kết: được chấp nhận bởi mọi người tham gia sơ kết hoặc  đã sẵn sàng để phát hành, v.v.

Tránh mất quá nhiều thời gian giới thiệu phần này. Bởi vì mục đích của phần này không phải để lấy phản hồi về các hạng mục hay nói về lý do tại sao một hạng mục chưa hoàn thành. Phần này chỉ đơn thuần là một bảng mục lục cho buổi họp. Sau khi Product Owner nói xong, chúng ta chuyển sang phần chính của buổi Sơ kết Sprint: phần trình diễn.

Thuyết minh chức năng mới

Đây là phần chính yếu của buổi Sơ kết Sprint. Và nếu bạn đã làm nhiều buổi Sơ kết Sprint thì rất có khả năng đây là phần duy nhất mà bạn làm.

Trong phần này, trình diễn các chức năng theo thứ tự trong danh sách bạn đã đưa ra trước đó. Luôn nhớ rằng mục đích của buổi Sơ kết Sprint là để thu thập phản hồi.

Không có quy định cứng nhắc về việc ai sẽ trình bày phần trình diễn. Có khi, Product Owner sẽ là người thao tác trên bàn phím. Product Owner nên làm vậy cùng những bên liên quan kỹ tính. Có khi các thành viên sẽ tự trình diễn hạng mục mà họ làm. Cách nào cũng tốt. Mọi người có thể thử nhiều cách để tìm được cách làm hợp với nhóm của mình.

Thảo luận những vấn đề chính

Sau khi trình diễn xong các chức năng là thời gian thảo luận về những vấn đề chính đã xảy ra trong Sprint.

Việc thảo luận này có thể được dẫn dắt bởi Product Owner hoặc Scrum Master. Tuy ai cũng có thể làm tốt việc này nhưng tôi hơi nghiêng về phía Scrum Master.

Vì trong suốt buổi Sơ kết Sprint, Product Owner đã nói nhiều rồi nên để Scrum master dẫn dắt phần thảo luận này sẽ cân bằng hơn. Ngoài ra, thảo luận trong phần này thường là về quy trình chứ không phải về sản phẩm, vốn thuộc về lĩnh vực của Scrum Master.

Trình bày những hạng mục Product Backlog tiếp theo

Phần cuối cùng của lịch trình Sơ kết Sprint nên là một phiên thảo luận về những hạng mục Product Backlog sẽ được làm tiếp. Vì mục đích của buổi Sơ kết Sprint là thu thập phản hồi về công việc của sprint hiện tại, mà điều này thường ảnh hưởng đến việc quyết định sẽ làm gì tại Sprint tiếp theo.

Ví dụ: nếu trong buổi Sơ kết mọi người thích giao diện mới, Product Owner có thể đẩy nhanh việc chuyển sang giao diện mới cho các phần khác. Hoặc nếu mọi người không thích một chức năng nào đó, có lẽ nó cần được chỉnh sửa trong Sprint sau trước khi làm tiếp các chức năng khác.

Product Owner bắt đầu phiên thảo luận bằng cách đưa ra những hạng mục Product Backlog tiếp theo sẽ làm. Product Owner có thể nói: “Mọi người có thể thấy trên màn hình là 10 hạng mục tiếp theo mà tôi nghĩ chúng ta sẽ làm, nhưng tôi muốn bổ sung thêm một vấn đề mới xuất hiện trong ngày hôm nay. Tôi sẽ chèn nó vào vị trí thứ 3.”

Sau đó Product Owner thu thập ý kiến của mọi người về những hạng mục sẽ làm. Tuy nhiên, Product Owner không nên xếp độ ưu tiên dựa trên những ý kiến đó ngay lập tức. Có nhiều lý do: Product Owner cần thêm thời gian đánh giá lại các ý kiến, hoặc cần thêm ước tính của nhóm về các thay đổi đưa ra ở buổi sơ kết,… Tóm lại, Product Owner thu thập ý kiến trong buổi Sơ kết Sprint rồi sau buổi sơ kết mới đưa ra quyết định.

Kết thúc buổi sơ kết

Kết thúc đơn giản bằng cách cám ơn mọi người vì đã tham gia. Có thể cám ơn cả nhóm vì đã hoàn thành công việc của Sprint. Có thể khen ngợi một hai người có năng suất tuyệt vời trong Sprint. Nhắc mọi người về thời gian và địa điểm của buổi Sơ kết tiếp theo.

Sau buổi Sơ kết Sprint

Dù không có trong lịch trình, sẽ phải có ai đó cập nhật hạng mục trên Product Backlog (online hoặc trên bảng/tường).

Tóm tắt lịch trình Sơ kết Sprint

Bạn tổ chức một buổi Sơ kết Sprint như thế nào?

Có thêm/bớt gì so với lịch trình phía trên? Có khác biệt gì căn bản? Có thể chia sẻ với mọi người tại mục bình luận phía dưới?

Nguồn: Mountain Goat

Dịch: Nguyễn Trung Tuyến