Field Marshal Helmuth Graf von Moltke – Nhà quân sự suất sắc nhất thế kỷ 19 sau Napoleon đã nói:

Lập kế hoạch là tất cả, kế hoạch không là gì.

Điều này cho chúng ta thấy được tầm quan trọng của việc lập kế hoạch thay vì kế hoạch.

Vậy với những nhóm ít kinh nghiệm chúng ta cần lập kế hoạch Sprint thế nào để đạt được hiệu quả?

Khi Nhóm Phát triển (gọi tắt là Nhóm) của bạn có nhiều thành viên non kinh nghiệm, họ gặp khó khăn trong việc hiểu đúng yêu cầu, tìm giải pháp phát triển và/hoặc cách cài đặt từng hạng mục nhỏ. Cách lập kế hoạch sau đây sẽ giúp ích rất nhiều cho bạn.

1. Xác định những hạng mục sẽ phát triển

Vì việc ước lượng theo giờ còn có sai số rất lớn, do đó bạn nên chọn khối lượng công việc sẽ làm trong Sprint này gần với số lượng đã hoàn thành được trong các Sprint trước đó – vận tốc của Nhóm. Nếu Nhóm cảm thấy Sprint này có thể làm được nhiều hơn hay ít hơn thì cũng nên căn cứ vào vận tốc đã có để quyết định.
Dĩ nhiên Nhóm sẽ phải chọn những hạng mục có độ ưu tiên cao nhất, những hạng mục nằm ở trên cùng của Product Backlog. Vì một lý do nào đó như sự phụ thuộc của các yêu cầu hoặc khả năng thực thi, v.v. mà Nhóm muốn làm một vài hạng mục có độ ưu tiên thấp hơn việc của họ là cần trao đổi với Product Owner.

Product Owner trình bày nội dung các yêu cầu đã được chọn và Nhóm sẽ hỏi chị ta để làm rõ yêu cầu trước khi đi tiếp. Nhóm thường sẽ cần rất nhiều thời gian để lập kế hoạch, nên phần này làm rõ yêu cầu với Product Owner cần lưu ý về mặt thời gian. Nếu yêu cầu đã rõ ràng trước khi lập kế hoạch thì phần này thường ngắn. Tuy nhiên, khi Nhóm Phát triển mất nhiều thời gian để tìm hiểu yêu cầu trong buổi lập kế hoạch bạn cần xem xét lại việc tổ chức các buổi làm mịn Product Backlog. Nếu cần hãy huấn luyện Nhóm thực hiện các buổi này đủ thời gian và đúng cách.

2. Phân tách từng yêu cầu thành những hạng mục công việc đủ nhỏ

Nhóm ít kinh nghiệm, nên việc phân tách các hạng mục công việc nhỏ sẽ giúp họ làm rõ thêm về yêu cầu, đưa ra được giải pháp cũng như cách thức thực hiện. Hãy giúp Nhóm chia nhỏ các hạng mục công việc, tốt nhất là nhỏ hơn một ngày làm việc. Một ngày chúng ta có 8 giờ làm việc, nhưng thực chất là thời gian tập trung của mỗi người chỉ khoảng 5 giờ (65%). Vậy nên, nếu độ chính xác là 100% thì bạn cũng chỉ làm được 5 giờ mỗi ngày.

3. Ước lượng theo giờ với Planning Poker

  1. Bước 1: Nhóm xác định các công việc sẽ được ước lượng.
  2. Bước 2: Mỗi thành viên sẽ tự xác định thời gian mà mình cho là Nhóm sẽ hoàn thành công việc đó thông qua việc chọn một cây poker (quân bài) tương ứng. Úp xuống trước mặt.
  3. Bước 3: Tất cả thành viên cùng lật cây poker mình đã chọn.
  4. Bước 4: Nếu cả Nhóm cùng chọn một cây poker (cùng số giờ) thì việc ước lượng cho việc đó đã hoàn thành.
  5. Bước 5: Nếu có sự khác biệt thì các thành viên lý giải lựa chọn của mình. Thông thường thì chỉ có người đưa ra ước lượng thấp nhất và cao nhất đưa ra lý giải. Chú ý nên giới hạn thời gian trình bày là 1 phút cho mỗi người. Sau đó mọi người thực hiện lại Bước 2.
  6. Với mỗi công việc thì chỉ nên giới hạn ước lượng trong 3 lần. Tới lần thứ 3 mà chưa đạt được sự đồng thuận thì nên lấy theo số đông hoặc chọn cơ chế khác để không tốn quá nhiều thời gian. Giá trị ở đây là sự trao đổi chứ không phải các con số.

Cách ước lượng này giúp cho mọi thành viên trong Nhóm đưa ra ý kiến một cách độc lập và từ đó họ sẽ giúp nhau tìm ra một cách hiểu đúng về công việc sẽ phải làm.

Xu hướng thường thấy đối với những người ít kinh nghiệm là họ đưa ra ước lượng quá thấp, ví dụ một việc chỉ mất 15 phút để hoàn thành. Lúc đó hãy nhắc Nhóm rằng một việc được gọi là hoàn thành bao gồm cả việc tiến thành xong nó, tự kiểm tra và làm những thao tác khác để tích hợp với công việc của nhóm VD như commit, tạo pull request, cập nhật bảng công việc, v.v…

Hoạt động lập kế hoạch Sprint theo phương pháp kể trên cần người điều hành (ScrumMaster) phải theo dõi và đảm bảo thời gian cũng như các quy tắc đã trình bày một cách liên tục. Chỉ cần một sự sao nhãng có thể làm cho buổi lập kế hoạch không đem lại giá trị hoặc mất quá nhiều thời gian.