Khi tiếp cận với mô hình Agile, đặc biệt là Scrum, điều khiến mình tâm đắc nhất chính là backlog được quản lý trong timebox. Cách làm này bảo vệ đội ngũ khỏi tình trạng bị phân tâm, nhận thêm việc ngoài kế hoạch, dẫn đến quá tải, chất lượng giảm sút, phải làm thêm giờ và dễ rơi vào kiệt sức.

Một Sprint kéo dài 2 tuần thường được coi là hợp lý: đủ ngắn để điều chỉnh chiến lược khi cần thiết, đủ dài để hoàn thiện một phase hoặc một tính năng, tạo ra một output vừa vặn khi kết thúc. Tuy nhiên, trên thực tế quản lý, luôn có những công việc chen ngang xuất hiện - thường là nhiệm vụ khẩn cấp, không thể chờ đến cuối Sprint. Nếu bỏ qua, dự án có thể đánh mất cơ hội hoặc đi sai hướng. Nếu đưa ngay vào Sprint đang chạy, thì vừa vi phạm nguyên tắc cam kết, vừa khiến team khó thực hiện trọn vẹn cả backlog cũ lẫn mới. Đây là một tình huống tiến thoái lưỡng nan mà mình từng nhiều lần gặp phải.

Ý chính tóm gọn

  • Không thể tránh hoàn toàn việc chen ngang trong Sprint -> cần cơ chế để xử lý.
  • Reserve Space = 20% effort dành cho công việc đột xuất, khẩn cấp.
  • Low Prioriry backlog có thể “lấp chỗ trống” nhưng sẵn sàng bị thay thế.
  • Nếu Reserve Space luôn bị vượt quá -> phải xem lại kế hoạch dự án và kỳ vọng của các Stakeholders.
  • Kết hợp kỷ luật của Scrum với linh hoạt thực tế -> giúp team vừa ổn định, vừa thích ứng.

Phân tích vấn đề

Như đã nêu ở phần mở đầu, các vấn đề có thể kể đến trong trường hợp này gồm:

  • Nếu bỏ qua: có nguy cơ bỏ lỡ cơ hội quan trọng, dự án đi chệch mục tiêu.
  • Nếu nhồi thêm vào Sprint: team bị quá tải, backlog cam kết từ đầu khó hoàn thành, chất lượng tổng thể giảm.

Kinh nghiệm thực tế cho thấy, việc này không thể giải quyết bằng cách áp dụng lý thuyết một cách cứng nhắc, mà cần có một cơ chế linh hoạt để hấp thụ các biến động.

Giải pháp: Reserve Space trong Sprint

Mình đã thử áp dụng một ý tưởng gọi là Reserve Space - tức dành trước một phần dung lượng Sprint để xử lý các công việc khẩn cấp. Cách làm như sau:

  1. Khi lập kế hoạch Sprint:
    • Chỉ commit backlog chính (Normal Backlog) ở mức khoảng 80% effort tổng Sprint.
    • 20% effort còn lại dành cho Reserve Space.
  2. Cách sử dụng Reserve Space:
    • Nếu có công việc khẩn cấp (Critical Backlog), chúng sẽ được đưa vào phần Reserve Space.
    • Các backlog ưu tiên thấp (Low Priority Backlog) có thể được xếp tạm trong Reserve Space để team thực hiện nếu không có việc chen ngang, nhưng sẵn sàng bị loại bỏ nếu cần nhường chỗ cho backlog quan trọng hơn.
  3. Khi Reserve Space bị vượt quá:
    • Nếu Sprint nào cũng xuất hiện quá nhiều backlog khẩn cấp vượt ngoài Reserve Space, đó là tín hiệu cần xem xét lại dự án: có thể team đang hứa hẹn quá mức hoặc kỳ vọng từ stakeholders chưa thực tế.

Bài học rút ra

Scrum mang lại sự kỷ luật trong cam kết, nhưng thực tế quản lý dự án luôn có biến số. Thay vì máy moc bỏ qua hoặc nhồi nhét backlog chen ngang, việc chủ động thiết kế một khoảng dung lượng dự phòng trong Sprint giúp đội ngũ vừa giữ được sự ổn định, vừa linh hoạt khi tình huống bất ngờ xảy đến.