Sprint Planning - Lập Kế Hoạch Sprint

1. Sprint Planning là gì?

Một Sprint bắt đầu bằng buổi lập kế hoạch Sprint để xác định mục tiêu và lên kế hoạch chi tiết cho những công việc cần thực hiện. Buổi Sprint Planning này sẽ lần lượt trả lời các câu hỏi chính:

Mục tiêu của Sprint này là gì?

Sprint này team mình cần chuyển giao cái gì?

Làm sao để team mình đạt được kết quả như mong muốn?

Diễn biến một buổi làm kế hoạch Sprint thường như sau:

1. What/Why: Product Owner trình bày tầm nhìn về sản phẩm, mục tiêu Sprint. Nhóm phát triển hỏi kỹ về các hạng mục cũng như mục tiêu. Tại sao Sprint này có thể mang lại giá trị cho sản phẩm, giá trị đó là gì? Product Goal của sản phẩm là gì? Có gì thay đổi trên thị trường không? Nó có liên hệ gì tới mục tiêu của Sprint tiếp theo?

2. How: Nhóm phát triển thảo luận, phân tích và dùng kỹ thuật để bẻ nhỏ thành Sprint Backlog, có thể trao đổi với PO.

2. Ai tham gia Sprint Planning?

Toàn bộ nhóm bắt buộc cần tham gia phần thứ nhất (What), xác định Mục tiêu của Sprint bao gồm Product Owner, Scrum Master và Nhóm phát triển. Tuy nhiên nếu Product Owner đã phân quyền và giao cho team quyền tự chủ quyết định việc mình sẽ làm trong mục tiêu ngắn (ví dụ tháng/quý) thì team hoàn toàn chủ động làm được phần này.

Phần thứ hai (How), Product Owner có thể vắng mặt, nhưng luôn cần ở trạng thái sẵn sàng support để làm rõ cho nhóm các hạng mục quan trọng. Nếu không có thể có mặt, có thể trả lời qua online hoặc qua điện thoại, tránh để mất thời gian chờ đợi nhau.

3. Sprint Planning dài bao lâu?

Timebox là yếu tố cực kỳ quan trọng của các buổi họp. Điều quan trọng là chúng ta có kết quả và bước tiếp theo cần phải làm gì sau mỗi cuộc họp chứ không phải muốn họp đến lúc nào thì họp. Thông thường,

Với sprint 1 tháng, buổi kế hoạch Sprint kéo dài 8 tiếng
Với sprint 2 tuần, buổi kế hoạch Sprint kép dài 4 tiếng

Với team sprint 1 tuần, buổi kế hoạch Sprint thường không kéo dài hơn 2 tiếng. Trong đó 1 tiếng dành cho việc xác định mục tiêu và thời gian còn lại dành cho việc tìm/trao đổi và xác định cách thực hiện.

Với các team mới làm quen với Scrum, những buổi họp đầu tiên thường bối rối và có thể vượt quá Timebox, nên điều chỉnh và cải tiến trong các buổi tiếp theo.

4. Product Backlog – Đầu vào của Sprint Planning

Không phải cứ đến giờ Sprint Planning, Product Owner hoặc cả team mới xác định Sprint này làm gì. Thông thường việc phát triển sản phẩm có roadmap khá rõ ràng với những milestone cụ thể, mục tiêu đạt được rõ ràng. Điều này được phản ánh thông qua các buổi Định hướng sản phẩm, Product Planning và sau đó được Product Owner chia sẻ lại với team thông qua công cụ Product Backlog, và đây cũng sẽ là đầu vào của hoạt động Sprint Planning.

Product Backlog là danh sách các tính năng mong muốn của sản phẩm. Danh sách được sắp xếp dựa trên độ ưu tiên của từng hạng mục. Các hạng mục được ưu tiên sẽ được để ở trên, và được nhóm Phát triển ưu tiên pick chọn. Product Backlog trong team Triển khai sản phẩm, sẽ thường là các nhiệm vụ của các Project khách hàng. Tuỳ vào mốc thời gian đã cam kết với khách hàng, các nhiệm vụ này sẽ được sắp xếp theo các thứ tự ưu tiên khác biệt.

Product Backlog có thể được quản lý trên Google Spreadsheet, trên Trello, hoặc sử dụng các công cụ quản lý source code như Github Project. Tại Haposoft, chúng mình sử dụng Trello cho hoạt động này.

5. Các bước tiến hành Sprint Planning

5.1. Xác định mục tiêu của Sprint

Product Owner sẽ trình bày mục tiêu mong muốn đạt được trong Sprint này, hoặc team sẽ chủ động nhắc lại các mục tiêu đã được thống nhất với PO từ đầu quý. Nếu cần làm rõ hơn các hạng mục trong Product Backlog, nhóm sẽ trao đổi trực tiếp với PO. Nhưng thông thường, việc làm rõ này đã được thực hiện trước qua các buổi làm mịn Backlog (hay còn gọi là Grooming) .

Thứ tiếp theo cần cân nhắc để lựa chọn số lượng mục tiêu cho phù hợp chính là năng lực của nhóm. Việc tính toán năng lực của nhóm là điều rất quan trọng, vì nếu tính toán không chính xác, bạn sẽ nhận nhiều hơn sức mình có hoặc quá ít so với năng lực của nhóm dẫn đến hiệu suất kém.

Có một lưu ý là nếu 1 ngày các bạn có 8 giờ làm việc, thì thời gian năng suất để mỗi thành viên thực sự làm việc được hiệu quả sẽ chỉ là 5 hoặc 6 giờ. Tiếp theo, hãy nhìn vào lịch cá nhân của mình xem có thành viên nào trong nhóm vướng mắc việc gì trong tuần này không, nếu có hãy chủ động chia sẻ ngay đầu buổi Planning.

5.2. Xác định cách thực hiện mục tiêu của Sprint

Làm thế nào để hoàn thành công việc đã chọn? Kết quả của phần làm việc chính là Sprint Backlog - bảng công việc được nhóm Phát triển sử dụng trong suốt Sprint.

Đối với mỗi hạng mục trong danh sách đã lựa chọn, nhóm sẽ tách thành những công việc cụ thể. Các công việc này thường đủ nhỏ để hoàn thành trong vòng một ngày hoặc ít hơn.

Thông thường các task của team sẽ là:

Thiết kế solution
Viết testing
Code
Viết tài liệu
Nghiên cứu kỹ thuật/công nghệ mới
Fix bug
Họp với team làm BA cho feature mới…

Sau khi xác định đầu mục công việc, nhóm sẽ cùng nhau chốt thời gian & nỗ lực team cần để hoàn thành công việc đó, có thể theo thời gian (giờ) hoặc point (điểm).

Thông thường trong 1 team phát triển, chúng mình sẽ có nhiều thành phần developer, tester, BA, nên việc ước lượng cho các task có thể có sự chênh lệch. Đó là lúc chúng mình sẽ dụng Planning Poker để tìm ra con số chung của nhóm.

Sau khi tính toán khối lượng công việc đã lựa chọn, nhóm phát triển có thể chủ động nhận thêm hoặc trao đổi với PO để cắt bớt các hạng mục.

5.3. Kiểm soát chất lượng bằng định nghĩa hoàn thành DoD

DoD

Product Owner sẽ thường làm việc với các team theo Quý với định hướng Quý, sau đó các team chủ động làm việc trong các Sprint. Việc tham gia Sprint Review cũng không bắt buộc với PO.

Liệu có dễ dàng và bị thiếu chất lượng khi để một nhóm tự đề xuất công việc dựa trên mục tiêu, rồi review với nhau và chủ động đưa ra các phiên bản update?

Có 2 cách để bạn quản lý chất lượng:

Một là giao nhiệm vụ, rồi kè kè bên cạnh kiểm soát và khi kết quả hoàn thành bạn sẽ check để soi lỗi.
Cách còn lại là giao nhiệm vụ, hướng dẫn team cách tự tư duy về định nghĩa hoàn thành (thế nào là hoàn thành) một cách cực kỳ chi tiết, team sẽ tự giám sát lẫn nhau và đảm bảo cho chất lượng đầu ra của mình.

Cách thứ 2 này là cách thường được lựa chọn. Chính vì vậy, định nghĩa hoàn thành lại trở thành một tiêu chuẩn cực kỳ quan trọng của bất cứ nhiệm vụ nào trong Sprint.

Định nghĩa hoàn thành là một danh sách các quy định những công việc cần được thực hiện xong trước khi một hạng mục được công nhận là DONE. Việc nhóm cùng nhau đưa ra định nghĩa hoàn thành cũng giúp mọi người trong nhóm hiểu chung về yêu cầu công việc, ngăn ngừa các mâu thuẫn do hiểu nhầm hoặc không hiểu rõ. Gia tăng tính minh bạch về yêu cầu cũng giúp nhóm tự tổ chức hiệu quả hơn. Chúng mình hay gọi Định nghĩa hoàn thành là DOD tức Definition of Done.

6. Bí kíp để buổi Sprint Planning đạt hiệu quả cao

6.1. Thống nhất giờ Sprint Planning phù hợp

Các team có sự lựa chọn thời gian Sprint Planning khác nhau, có team thì làm luôn vào chiều thứ 6, có team thì sáng thứ 2 mới làm.

Tuy nhiên, theo quan sát:

Các team tiếp xúc với khách hàng hay có sự thay đổi thường xuyên và công việc cần sự tiếp nối cao thì sẽ thích làm Planning vào chiều thứ 6 để không bị quên tình huống của khách hàng sau 2 ngày cuối tuần.
Còn các team ít sự biến động, chủ động hơn với mục tiêu công việc của mình sẽ chọn Planning vào đầu tuần.

6.2. Các thành viên trong team rà soát & chuẩn bị các task của bản thân đẩy lên trước và làm rõ

Buổi làm việc sẽ không thể hiệu quả nếu đến lúc đó bạn mới bê não vào phòng họp.

Ví dụ giờ planning của team là 15h30, chiều thứ 6 hàng tuần. Khoảng thời gian từ đầu giờ chiều thứ 6 đến buổi họp (2 tiếng trước buổi Planning) là lúc chúng ta sẽ cùng đẩy lên các mục tiêu của cá nhân hoặc chủ động nhìn lại các mục tiêu của team và đưa vào kế hoạch tuần.

6.3. Thực hiện Grooming (làm mịn) thường xuyên

Làm mịn là một kỹ thuật trong việc quản lý Product Backlog. Các hạng mục trong Product Backlog có kích thước khác nhau, mức độ chi tiết khác nhau và thường chúng cần được làm mịn trước khi đi vào sản xuất.

Làm mịn có thể bao gồm việc bẻ nhỏ những hạng mục có kích thước lớn thành những hạng mục nhỏ hơn, càng nhỏ, càng chi tiết thì càng rõ ràng và mịn.

Một nhóm Scrum có thể dành ra 10% thời gian Sprint để ngồi cùng nhau làm mịn Product Backlog cho các phiên tiếp theo.

Việc tư duy công việc từ trước để có sự chuẩn bị và không bị động là bí kíp để các buổi Sprint Planning được hiệu quả cao.

7. Check list kiểm tra lập kế hoạch sprint

✓ Buổi lập kế hoạch có diễn ra đúng giờ?
✓ Có thành viên nào thiếu không? Lí do vì sao?
✓ Product Backlog có sẵn sàng trước buổi lập kế hoạch?
✓ PO có sơ kết lại tình hình sản phẩm hiện tại đầu buổi lập kế hoạch?
✓ PO có đưa ra mong muốn mục tiêu Sprint đầu buổi lập kế hoạch?
✓ Khả năng của Nhóm Phát triển đã được tính?
✓ Có những vấn đề, sự kiện nào đặc biệt ảnh hưởng tới khả năng của nhóm không (ví dụ nghỉ hè, thành viên nào có việc riêng)?
✓ Nhóm Phát triển và PO có rà soát những hạng mục có thể sẽ phát triển trong Sprint?
✓ Những hạng mục có thể sẽ phát triển trong Sprint đã có tiêu chí chấp nhận?
✓ Nhóm Phát triển đã phân ra các hạng mục sẽ phát triển thành các công việc đưa vào Sprint Backlog?
✓ Các hạng mục trong Sprint Backlog đã được ước lượng?
✓ PO có hài lòng với cam kết của Nhóm Phát triển?

Chúc các bạn có hoạt động Sprint Planning hiệu quả nhé!

Tài liệu tham khảo
https://career.magestore.com/post/sprint-planning
https://www.atlassian.com/agile/scrum
https://scrumguides.org/scrum-guide.html#daily-scrum
https://www.scrum.org/resources