Để báo cáo tuần giúp đưa ra quyết định

Báo cáo tuần có thể liệt kê đủ mọi việc đã làm mà người bảo trợ vẫn không biết cần hành động gì. Thứ còn thiếu thường không phải chi tiết, mà là thông tin điều gì đã thay đổi và lựa chọn nào đang quan trọng. Hãy coi báo cáo là bản tóm tắt phục vụ quyết định. Người đọc cần hiểu triển vọng bàn giao mà không phải tự ghép số lượng phiếu công việc với biên bản họp.

Mở đầu bằng thay đổi trong triển vọng bàn giao

Nêu kết quả nghiệp vụ mong muốn, dự báo hiện tại và điểm khác so với báo cáo trước. Giải thích thay đổi bắt nguồn từ bằng chứng mới, điều chỉnh phạm vi hay giả định chưa kiểm chứng. Tách mốc mục tiêu do quản lý đặt ra khỏi dự báo dựa trên bằng chứng thực hiện.

Scrum Guide gắn kiểm tra với thích ứng và mô tả Sprint Review là dịp xem xét kết quả để xác định điều chỉnh tiếp theo.[1] Báo cáo tuần không phải một sự kiện Scrum bắt buộc. Khuyến nghị ở đây là áp dụng sự phân biệt thực tế tương tự: trình bày quan sát trước, rồi đề xuất phản ứng phù hợp.

Biến mỗi yêu cầu thành câu hỏi có thể trả lời

Thay “đang chờ phản hồi” bằng lựa chọn có người quyết định, các phương án, khuyến nghị và hạn trả lời. Nêu hậu quả nếu chưa có câu trả lời. Nếu chưa ai có thẩm quyền, hãy chuyển cấp vấn đề thiếu người quyết định, thay vì ngầm coi yêu cầu đã được chấp thuận.

Đặt một khối thông tin quyết định ngắn trước phần giải thích chi tiết.

• Nêu kết quả nghiệp vụ bị ảnh hưởng, không chỉ công việc chậm.
• Chỉ ra bằng chứng làm đổi dự báo và phần chưa chắc chắn.
• Liệt kê phương án cùng hệ quả bàn giao của từng phương án.
• Xác định người quyết định và thời điểm bắt đầu chuyển cấp.
• Ghi lựa chọn cuối cùng cạnh yêu cầu ban đầu.

Ví dụ giả định: dữ liệu nhập chưa hoàn tất

Trong ví dụ giả định về cổng thành viên, nhóm có thể phát hành chức năng đăng ký nhưng chưa xác thực được dữ liệu liên hệ nhập từ hệ thống cũ. Báo cáo yếu chỉ nói việc chuyển dữ liệu đang tiếp tục. Báo cáo hữu ích yêu cầu người bảo trợ chọn phát hành giới hạn chưa có dữ liệu nhập, hoặc lùi phát hành để kèm phần chuyển dữ liệu.

Báo cáo dẫn tới kết quả kiểm tra mẫu không đạt, xác định nhóm người dùng phải nhập thủ công và nêu thời điểm tiếp theo có thể cải thiện độ chắc chắn của dự báo. Không phương án nào được mô tả là không có rủi ro. Người bảo trợ có thể đánh giá giới hạn dịch vụ thay vì đoán ý nghĩa của trạng thái màu vàng.

Giữ báo cáo gọn nhưng không giấu rủi ro

Đưa chi tiết kỹ thuật vào hồ sơ liên kết, nhưng giữ lại rủi ro chưa giải quyết có thể làm đổi quyết định. Tài liệu GitHub mô tả issue là nơi lập kế hoạch, thảo luận và theo dõi công việc.[2] Dù dùng công cụ nào, nên duy trì một hồ sơ bằng chứng thay vì nhiều bản sao mâu thuẫn.

Báo cáo ngắn có thể đơn giản hóa quá mức phần việc chưa chắc chắn. Hãy khắc phục bằng mức độ tin cậy rõ ràng và giả định cụ thể, không phải thêm mã màu. Sau chu kỳ báo cáo tiếp theo, kiểm tra từng yêu cầu quyết định đã có câu trả lời chưa. Bỏ phần không ai dùng, nhưng giữ thông tin giải thích vì sao hướng thực hiện đã thay đổi.