Login

Sprint planning hiệu quả: từ Sprint Goal đến kế hoạch làm việc thực tế

  • author-image

    Nguyễn Đình Cường

  • blog-tag
  • blog-comment 0 comment
  • created-date 09 Nov, 2026
blog-thumbnail

Buổi sprint planning kéo dài bốn tiếng mà cuối buổi vẫn không ai rõ sprint này nhằm mục đích gì? Đây là tình trạng rất thường gặp. Sprint planning tốt ngắn gọn, có mục tiêu rõ và để lại cho nhóm một kế hoạch khả thi mà họ tin tưởng.

Sprint planning trả lời ba câu hỏi

Theo Scrum Guide, buổi lập kế hoạch sprint giải quyết ba chủ đề:

  1. Vì sao sprint này có giá trị? Product Owner đề xuất cách sprint làm tăng giá trị sản phẩm, và cả nhóm cùng thống nhất Sprint Goal.
  2. Làm được những gì? Nhóm chọn các mục từ Product Backlog dựa trên mục tiêu và năng lực của mình.
  3. Làm như thế nào? Nhóm phân rã các mục đã chọn thành công việc cụ thể, đủ nhỏ để hoàn thành trong vài ngày.

Sprint Goal: la bàn của sprint

Sprint Goal là một câu mô tả mục đích duy nhất cho sprint, mang lại sự linh hoạt khi mọi chuyện không theo kế hoạch. So sánh hai cách viết:

  • Yếu: 'Làm 8 ticket trong danh sách.'
  • Tốt: 'Người dùng mới có thể đăng ký và hoàn thành bài học đầu tiên mà không cần hỗ trợ.'

Khi gặp vướng mắc, nhóm có thể cắt bớt chi tiết nhưng vẫn bảo vệ mục tiêu. Mục tiêu giúp nhóm trả lời nhanh câu hỏi 'việc này có đáng làm trong sprint không?'.

Chuẩn bị trước buổi họp

Buổi planning hiệu quả là kết quả của việc chuẩn bị trước, thường qua hoạt động tinh chỉnh backlog (refinement):

  • Các mục ở đầu backlog đã rõ ràng, có tiêu chí chấp nhận, và đã được ước lượng.
  • Story quá lớn đã được cắt nhỏ.
  • Product Owner đã sắp xếp thứ tự ưu tiên và chuẩn bị đề xuất mục tiêu.
  • Nhóm biết ai nghỉ phép, ngày lễ nào rơi vào sprint.

Chọn bao nhiêu việc là vừa?

Dùng dữ liệu quá khứ làm cơ sở. Nếu velocity trung bình vài sprint gần đây là khoảng 25 điểm, hãy cân nhắc chọn trong khoảng đó thay vì kỳ vọng sprint này sẽ đặc biệt tốt. Sau đó điều chỉnh theo thực tế:

  1. Trừ thời gian cho người vắng mặt.
  2. Dành khoảng trống cho việc phát sinh như sửa lỗi production, hỗ trợ, họp.
  3. Xếp việc theo thứ tự ưu tiên và dừng lại khi cảm thấy đã đủ, đừng nhồi cho đầy.

Tốt hơn là hoàn thành đủ cam kết rồi nhận thêm việc, so với việc cam kết quá nhiều và kết thúc sprint với hàng loạt việc dang dở.

Phân rã công việc

Với mỗi story, nhóm cùng nghĩ ra các đầu việc cụ thể, ví dụ cho story 'đăng ký tài khoản':

  • Thiết kế biểu mẫu và kiểm tra dữ liệu nhập.
  • Viết API tạo tài khoản và gửi email xác nhận.
  • Viết kiểm thử tự động cho các trường hợp thành công và lỗi.
  • Cập nhật tài liệu và kiểm tra trên môi trường staging.

Việc này không để chia việc cho từng người ngay, mà để nhóm hiểu khối lượng và phát hiện phụ thuộc. Người nhận việc có thể quyết định dần trong sprint theo kiểu 'ai rảnh thì kéo việc kế tiếp'.

Thời lượng và cách điều phối

Scrum Guide nêu giới hạn thời gian tối đa là tám giờ cho sprint một tháng, và thường ngắn hơn với sprint ngắn hơn. Với sprint hai tuần, nhiều nhóm xong trong một đến hai giờ nếu đã chuẩn bị tốt. Một vài mẹo:

  • Đặt đồng hồ cho từng phần.
  • Bắt đầu bằng mục tiêu, sau đó mới đến danh sách việc.
  • Nếu một story gây tranh cãi quá lâu, tạm gác sang để thảo luận riêng với những người liên quan.
  • Ghi lại các giả định và rủi ro ngay trong thẻ công việc.

Dấu hiệu planning chưa tốt

  • Phát hiện story chưa rõ yêu cầu ngay giữa buổi họp.
  • Sprint Goal chỉ là liệt kê các story.
  • Một hai người nói, còn lại im lặng.
  • Cuối sprint thường xuyên không xong việc đã cam kết mà không ai rút bài học.
  • Quản lý ngoài nhóm chỉ định số lượng việc phải làm.

Kết luận

Một buổi sprint planning tốt cho ra ba thứ: mục tiêu rõ ràng, danh sách việc vừa sức và kế hoạch cụ thể ở mức cần thiết. Hãy bắt đầu bằng việc viết lại Sprint Goal cho sprint tới theo giá trị người dùng, không phải theo số lượng việc.

Nếu bạn muốn luyện cách lập kế hoạch cho dự án phần mềm từ cơ bản đến thực tế, hãy xem các khóa học tại codebem.com.

author_photo
Nguyễn Đình Cường

0 comment