Sprint Planning

Cả sprint sống hay chết được quyết trong hai tiếng đầu tiên này, nên buổi nào bị rút xuống còn ba mươi phút cho nhanh thì y như rằng tuần sau có chuyện. Cả Scrum Team ngồi lại để trả lời một câu duy nhất: hai tuần tới chúng ta muốn đạt được điều gì, và làm cách nào. Kết thúc buổi này phải có Sprint Backlog, tức Sprint Goal cộng với danh sách item đã chọn cộng với kế hoạch thực hiện.

Sprint Planning không phải chỗ để phân tích yêu cầu lần đầu. Cái đó thuộc về Backlog Refinement, làm rải rác trong sprint trước.

Timebox và người tham dự

Scrum Guide 2020 đặt trần 8 giờ cho sprint một tháng, và ngắn lại theo tỉ lệ với sprint ngắn hơn:

Người tham dự: toàn bộ Scrum Team, gồm Product Owner, Scrum Master và Developers. Có thể mời thêm người ngoài để tư vấn, ví dụ kiến trúc sư hệ thống khi sprint đụng tới tích hợp lớn, hoặc một chuyên gia nghiệp vụ ngành. Mời thì mời, quyết định vẫn nằm ở team.

Ba chủ đề phải đi qua

Bản 2020 chia buổi này thành ba phần rõ ràng:

Vì sao (Why). PO trình bày sprint này định phục vụ mục tiêu gì. Cả team cùng gọt lại thành một Sprint Goal viết được thành một câu. Phần này hay bị bỏ qua nhất, vì trông như thủ tục. Nhưng tới ngày thứ tám, khi phải cắt bớt phạm vi, đây là thứ duy nhất cho bạn biết nên cắt cái nào.

Cái gì (What). Developers chọn item từ Product Backlog vào sprint. Chú ý chiều mũi tên: PO xếp thứ tự và giải thích, còn Developers là người quyết định lấy bao nhiêu. Không ai được giao số lượng xuống cho team.

Thế nào (How). Team phác cách làm cho vài item đầu tiên, chẻ thành task nếu thấy cần. Không cần chẻ hết mọi thứ ngay hôm nay, kế hoạch được cập nhật suốt sprint.

Ví dụ thực tế

Team 7 người làm cổng thanh toán học phí cho một trường đại học, sprint 2 tuần, buổi planning gói trong 2 tiếng rưỡi.

PO mở đầu: kỳ nhập học tháng 9 có hơn 6.300 sinh viên đóng học phí dồn trong 10 ngày, năm ngoái phòng kế toán phải đối soát tay 386 giao dịch treo. Sprint Goal được chốt: "Kế toán đối soát được giao dịch treo ngay trong ngày mà không cần mở file Excel."

Developers chọn 6 item, tổng 34 điểm, thấp hơn velocity trung bình 40 vì sprint này có hai ngày lễ. Ở phần How, một dev phát hiện API tra cứu trạng thái của ngân hàng giới hạn 60 lần gọi mỗi phút — thông tin này chưa ai biết. Team đổi cách làm sang chạy theo lô và điều chỉnh một item ngay tại chỗ. Nếu không có phần How, cái giới hạn đó sẽ nổ vào ngày thứ tám của sprint.

Lỗi hay gặp

• Biến thành buổi giao việc. Trưởng phòng ngồi cùng, đọc danh sách và phân cho từng người. Lúc đó Developers thôi tự quản, và trách nhiệm về kết quả cũng đi theo.
• Không có Sprint Goal, chỉ có danh sách item. Sprint kiểu này khi bị cắt bớt phạm vi thì không ai biết nên cắt cái nào.
• Phân tích yêu cầu ngay tại buổi planning. Story chưa được refine, cả team ngồi cãi nghiệp vụ 3 tiếng rồi ai cũng mệt. Dấu hiệu rõ nhất của việc thiếu refinement ở sprint trước.
• Nhồi cho đầy capacity. Lấy đúng bằng velocity tối đa từng đạt, không chừa chỗ cho ticket production hay việc phát sinh. Sprint nào cũng trượt vài item rồi cả team quen dần với việc trượt.
• PO vắng mặt, cử người ngồi thay ghi chép. Không ai trả lời được câu hỏi nghiệp vụ, buổi họp thành ra vô nghĩa.

Mẹo khi đi làm

Trước buổi planning một ngày, gửi trước danh sách item dự kiến kèm acceptance criteria vào kênh chat của team. Ai đọc trước thì buổi họp rút được gần một nửa thời gian. Và nhớ hỏi capacity thật: ai nghỉ phép, ai bị kéo sang hỗ trợ dự án khác, sprint có rơi vào tuần có lễ không. Con số capacity trên giấy với con số thật hay lệch nhau 20%.