Mẫu chương trình lập kế hoạch sprint cho các nhóm kỹ thuật

Vì sao các sprint bị quá tải

Lập kế hoạch sprint có một thất bại cấu trúc mà các mẫu không ngăn được: các nhóm chọn backlog sprint trước khi có ai kiểm tra năng lực. Kết quả là một sprint trông có vẻ khả thi trên bảng trắng nhưng sụp đổ vào thứ Tư khi hai kỹ sư nghỉ nửa tuần, một ticket phình phạm vi gấp ba, và ba mục có những phụ thuộc chưa nêu vào một dịch vụ mà nhóm nền tảng đang viết lại.

Cách khắc phục thì đơn giản và gần như không bao giờ được thực hiện: cam kết về năng lực trước khi cam kết về công việc. Mẫu dưới đây mở đầu bằng một bước rà soát năng lực chính vì lý do đó.

Chương trình họp (sao chép và dán)

Thời lượng: 2 giờ cho một sprint 2 tuần; 1 giờ cho một sprint 1 tuần
Định dạng: Có người điều phối, với backlog hiển thị cho cả nhóm

Phần 1 — Mục tiêu sprint (10 phút)

Một câu: một sprint thành công trông như thế nào từ bên ngoài nhìn vào?
Mục tiêu nên đủ cụ thể để bất kỳ thành viên nào cũng có thể đánh giá vào cuối sprint xem bạn có đạt được nó không
Bác bỏ những mục tiêu chỉ là một danh sách ticket ("hoàn thành việc tái cấu trúc auth và trang thanh toán") — đó là một backlog, không phải một mục tiêu

Phần 2 — Rà soát năng lực (15 phút)

Liệt kê từng thành viên trong nhóm theo tên
Với mỗi người: nghỉ phép đã lên kế hoạch, ca trực on-call, các cuộc họp định kỳ, các cam kết bên ngoài đã biết
Diễn đạt năng lực bằng số story point hoặc số ngày khả dụng — không phải bằng số đầu người
Con số này là trần; đừng chọn nhiều việc hơn mức nó có thể gánh

Phần 3 — Chọn backlog (45 phút)

Duyệt các mục ưu tiên cao nhất từ backlog đã được tinh lọc
Với mỗi ứng viên: nhóm có đủ điều kiện để bắt đầu chưa, hay còn những câu hỏi bỏ ngỏ cần lời giải trước khi sprint bắt đầu? Câu hỏi bỏ ngỏ thuộc về hàng đợi tinh lọc, không thuộc về sprint
Dừng chọn khi bạn chạm 80% năng lực; 20% còn lại hấp thụ phần dôi ra và công việc phát sinh ngoài kế hoạch

Phần 4 — Tiêu chí chấp nhận (20 phút)

Với mỗi mục được chọn: nêu tiêu chí xác định nó đã xong
Nếu nhóm không thể nêu một tiêu chí trong 60 giây, ticket chưa được tinh lọc đủ — chuyển nó trở lại backlog
Viết nó vào ticket ngay bây giờ, ngay trong phòng; đừng dựa vào "chúng ta sẽ thêm sau"

Phần 5 — Rủi ro và phụ thuộc (15 phút)

Điều gì có thể chặn việc hoàn thành mục tiêu sprint mà nhóm không kiểm soát được?
Nêu tên người phụ trách phụ thuộc; đưa nó ra ngay bây giờ khi vẫn còn thời gian giải quyết trước giữa sprint
Những phụ thuộc chưa giải quyết được giao cho một người phụ trách từ nhóm để theo dõi chúng

Kết thúc (15 phút)

Xác nhận mục tiêu sprint vẫn còn hợp lệ với khối lượng công việc đã chọn
Chỉ định người ghi chú tóm tắt sprint, hoặc xác nhận thiết lập báo cáo tự động
Xác nhận ngày lập kế hoạch tiếp theo

Điều mà hầu hết các mẫu lập kế hoạch sprint bỏ sót

Các mẫu lập kế hoạch sprint phổ biến nhất tập trung vào việc dọn dẹp backlog và định-nghĩa-hoàn-thành. Cả hai đều quan trọng. Nhưng không cái nào giải quyết lỗi lập kế hoạch tạo ra nhiều thất bại sprint nhất: chọn việc mà không kiểm tra khả năng sẵn có.

Một nhóm năm kỹ sư ở năng lực đầy đủ có khoảng 200 story point sẵn có mỗi sprint 2 tuần. Một nhóm năm người với hai kỹ sư nghỉ phép, một người luân phiên trực on-call, và một người tham dự một chuyến offsite ba ngày thì chỉ có chừng 110. Nếu bạn chọn 180 point trong sprint thứ hai, bạn đã thất bại từ đầu. Bước chọn việc là nơi việc cam kết quá mức xảy ra, và năng lực phải đi trước nó.

Khoảng trống thứ hai là tiêu chí chấp nhận. Các nhóm lướt nhanh qua buổi lập kế hoạch và định viết tiêu chí sau. Cái "sau" đó không diễn ra ở cùng mức độ cụ thể. Người lẽ ra sẽ viết một tiêu chí chính xác ngay trong phòng lại viết một thứ mơ hồ hơn từ trí nhớ vào ngày hôm sau, hoặc không viết gì cả. Những bất đồng giữa sprint về việc "xong" nghĩa là gì gần như luôn truy về được tiêu chí chấp nhận bị bỏ qua trong buổi lập kế hoạch.

Cái giá tích lũy của những khoảng trống này — sprint quá tải, phát hiện giữa sprint, những định nghĩa bị đem ra tranh cãi lại — hiện ra rõ ràng khi bạn cộng lại: Thuế họp hành.

Vì sao ghi chú lập kế hoạch sprint khó hơn vẻ ngoài của nó

Lập kế hoạch sprint sinh ra nhiều thông tin hơn gần như bất kỳ cuộc họp định kỳ nào khác: mục tiêu sprint, các con số năng lực, lý do chọn từng mục, tiêu chí chấp nhận cho từng ticket, người phụ trách phụ thuộc, các mục rủi ro. Viết một bản tóm tắt hữu ích đòi hỏi ghi lại tất cả dưới một dạng vẫn hữu ích ba ngày sau khi ai đó hỏi "vì sao chúng ta cắt mục đó?"

Pavleur tạo báo cáo lập kế hoạch sprint tự động vào cuối cuộc gọi. Nó ghi lại mục tiêu sprint, backlog đã chọn kèm lý do, tiêu chí chấp nhận đúng như đã nêu trong cuộc họp, và người phụ trách phụ thuộc đúng như đã nêu tên. Nếu ai đó chia sẻ màn hình backlog hay bảng tính năng lực, hình ảnh đó được đưa vào báo cáo cùng với phần thảo luận — ngữ cảnh mà các công cụ chỉ có âm thanh như Otter hay Fireflies sẽ bỏ sót hoàn toàn. Bất kỳ ai vào trễ hoặc cần kiểm tra một quyết định giữa sprint đều có bản ghi đầy đủ. Để so sánh cách điều này khác với các công cụ chỉ có âm thanh: Pavleur so với các lựa chọn khác.

Xử lý việc thay đổi kế hoạch giữa sprint

Kế hoạch sprint là một cam kết, không phải một hợp đồng. Khi có điều gì đó giữa sprint thực sự làm vô hiệu kế hoạch — một sự cố sản xuất, một phụ thuộc quan trọng chặn ba ticket, một thay đổi ưu tiên từ lãnh đạo — phản ứng đúng là một cuộc gọi lập kế hoạch lại nhanh gọn, không phải âm thầm cắt bỏ phạm vi. Cuộc gọi lập kế hoạch lại mất 20 phút và tạo ra một mục tiêu sprint cập nhật phản ánh thực tế. Cách khác là một sprint thất bại trên giấy nhưng được điều chỉnh không chính thức theo những cách không ai ghi lại, khiến buổi hồi cố khó hơn và các con số vận tốc trở nên vô nghĩa.

Hãy xây dựng thói quen lập kế hoạch lại một cách rõ ràng. Dùng cùng cấu trúc: năng lực cập nhật, lựa chọn được điều chỉnh, mục tiêu được nêu lại. Nó mất ít thời gian hơn nhiều so với sự rối loạn mà nó ngăn ngừa.