Họp Agile sprint planning chưa chắc đã đảm bảo được sự thành công của một sprint, nhưng một sprint thành công thì chắc chắn không thể thiếu được hoạt động sprint planning. Nếu vận hành buổi họp sprint planning một cách đúng đắn, buổi họp này không chỉ biểu thị cho sự bắt đầu của một sprint mà còn cung cấp cho đội dự án về mục tiêu và cấu trúc công việc, hạn chế những việc chưa được hoạch định rõ rang, và thiết lập tiêu chuẩn mà công việc hoàn thành cần đạt được xuyên suốt một sprint. Ở đây, chúng ta sẽ bàn sâu hơn về những công việc chuẩn bị cũng như thực hiện tốt nhất cho một buổi họp sprint planning, đảm bảo rằng đội dự án có thể phối hợp và lập kế hoạch nhằm xác định nền tảng cho một sprint hiệu quả.

Chuẩn bị cho một buổi Agile sprint planning như thế nào

Khởi tạo một buổi sprint planning meeting bắt đầu bằng việc lập kế hoạch. Bằng việc chuẩn bị một số điểm chi tiết trước, bạn có thể sắp xếp cho buổi họp sprint planning nhằm tập trung vào việc phối hợp và sản phẩm bàn giao. Dưới đây là những công việc cần bắt đầu:

Chuẩn bị product backlog

Trước khi bắt đầu một sprint (lý tưởng là trước buổi sprint planning), Product Owner phân tích sơ bộ toàn bộ các hạng mục trong Product Backlog (còn được gọi là hoạt động backlog refinement-làm min/sàng lọc backlog). Product Backlog là một tập hợp các hạng mục cần thiết để tạo ra sản phẩm, sắp xếp theo một trật tự nhất định. Theo tính chất tự nhiên của phát triển phần mềm, Product Backlog sẽ không khi nào ở trạng thái chính xác hoàn toàn, và luôn luôn có xu hướng thay đổi.

Nhằm tổ chức được, và thống nhất chung một ý hiểu, Product Owner và đội phát triển (development team) nên thực hiện các hành động cải tiến liên tục nhằm sắp xếp lại mức độ ưu tiên, thêm nội dung chi tiết, loại bỏ những hạng mục dư thừa và điều chỉnh ước lượng (estimate về thời gian, công số) khi đánh giá sản phẩm và xuyên suốt quá trình phát triển. Từ Product Backlog, sẽ hoạch định được các hạng mục sẽ phát triển trong từng sprint, nên điều quan trọng là nhóm dự án cần cập nhật liên tục Product Backlog. Làm như vậy, các bên liên quan đều nắm bắt được những hạng mục phát triển còn trong “hàng đợi” (queue) và năng lực của team. Bạn cũng có thể tổ chức một buổi họp “pre-planning” để chuẩn bị cho Product Backlog và quyết định xem sẽ làm những phần việc nào trong sprint sắp tới. Buổi họp này có thể không cần cả team tham gia, chỉ cần có Product Owner và Scrum Master. Việc chuẩn bị product backlog trước buổi họp sprint planning càng kỹ bao nhiêu, bạn càng có thể tối ưu thời gian cho việc họp sprint planning bấy nhiêu

Đánh giá năng lực của team

Trước khi cam kết lịch của một sprint, cần đảm bảo rằng team đủ năng lực để xử lý những công việc đã được lựa chọn cho sprint đó. Hãy hỏi thành viên dự án về dự định nghỉ phép của họ, thời gian bận tại các dự án khác và những hạn chế/ràng buộc khác nếu có. Nếu một (hoặc một vài) thành viên không thể cam kết làm việc toàn thời gian trong sprint, cần điều chỉnh khối lượng công việc tương ứng. Song song với việc kiểm tra tính sẵn sàng của team, bạn cũng cần đảm bảo rằng các nguồn lực cần thiết khác cũng sẵn sàng. Tất cả những ngoại lệ, hoặc vấn đề được biết từ trước cần được phản ánh vào trong buổi họp sprint planning nhằm giải quyết trước khi sprint bắt đầu. Thiết lập năng suất làm việc của team Năng suất làm việc của team chính là khối lượng công việc cả team có thể xử lý được trong một sprint. Không có một tiêu chuẩn nào quy định rằng một team cần hoàn thành bao nhiêu. Năng suất của team phụ thuộc phần lớn vào việc mọi người đã làm cùng nhau trong bao lâu, đã giải quyết được bao nhiêu backlog item và đã lập kế hoạch cho sprint hiệu quả như thế nào. Nếu như bạn cần xác định năng suất cho một team mới thành lập, hãy theo dõi kết quả công việc, sản phẩm đầu ra và số lượng story points qua từ sprint nhằm đo lường được năng suất trung bình.

Lập kế hoạch cho buổi họp sprint planning

Scrum Master sẽ phụ trách cho những câu hỏi AI, CÁI GÌ, KHI NÀO, và Ở ĐÂU cho buổi sprint planning. Việc chuẩn bị này nhằm quyết định thời gian cũng như đối tượng tham gia của buổi họp. Nhằm xác định độ dài của buổi họp, đầu tiên hãy cân nhắc tới độ dài của sprint. Nhân số tuần của sprint với 2 giờ— bạn sẽ ra được estimate sơ bộ về thời gian cho buổi họp sprint planning. Ví dụ, một sprint kéo dài 2 tuần thì sẽ cần khoảng 4 giờ để họp sprint planning. Quan trọng nhất, Scrum Master cần xác định nội dung của buổi họp và thông báo cho các bên liên quan như Scrum team, Product Owner, và cách key stakeholders. Kinh nghiệm để vận hành buổi họp sprint planning Scrum sprint planning cần một khoảng thời gian nhất định để lập kế hoạch và lấy phối hợp của Scrum team. Cũng cần thiết phải thiết lập một ý hiểu chung về mục tiêu của sprint. Buổi họp sprint planning thường diễn ra để hiểu rõ công việc của team, nêu rõ nguyện vọng và tạo ra bản kế hoạch chính xác Thực hiện các bước dưới đây nhằm đảm bảo buổi họp sprint planning diễn ra hiệu quả để bắt đầu một sprint.

1. Bắt đầu với một bức tranh tổng thể

Bắt đầu buổi họp sprint planning bằng cách chính thức kết thúc sprint cũ và nắm bắt trạng thái công việc của mọi người. Hãy “dọn đường” cho sprint tiếp theo bằng việc nhắc nhở team của bạn về mục tiêu bao quát của cả dự án, khuyến khích, động viên mọi người có một cái nhìn lạc quan về công việc sắp tới sẽ trải qua. Bất kỳ mục tiêu đặc biệt cho sprint cần được phát biểu rõ ràng ngay từ đầu buổi họp, từ đó bạn và team của bạn có thể tham chiếu vào đó để lập kế hoạch cụ thể.

2. Phát biểu về những điểm cập nhật, những phản hồi và vấn đề

Khi mục tiêu của sprint đã được phát biểu cụ thể, Scrum Master và Product Owner cần nhắc qua về những điểm cập nhật hoặc những chi tiết họ vừa nhận được từ các stakeholders. Bạn cũng có thể thảo luận về những phản hồi khách hang nhằm cung cấp thông tin cho team của bạn, và hướng dẫn cho những công việc sắp tới. Đây cũng là thời gian để đi qua bất kỳ issue nào gây cản trở tới tiến độ của sprint trước đó. Những issue như thiếu nhân sự, giao tiếp kém, và những cản trở khác cần được xử lý và thảo luận nhằm thống nhất cho công việc trong sprint.

3. Xác nhận lại năng lực và năng suất của team

Xác nhận về mức độ sẵn sàng của team đối với từng giai đoạn của dự án, cũng như đảm bảo rằng team nhận thức được năng suất hiện tại của họ. Cập nhật cho team những thay đổi về vai trò, trách nhiệm hoặc giới thiệu thêm các thành viên mới so với sprint trước đó. Mục tiêu của bạn nên tối thiểu hóa những bất ngờ trong sprint bằng cách đặt ra những thời hạn (deadlines) và cho phép team lựa chọn story nào họ muốn triển khai trong sprint này.

4. Kiểm tra lại backlog items

Review lại các hạng mục trong backlog được chọn bởi Product Owner cùng với team của bạn. Backlog thường bao gồm công việc cho khoảng 2 sprint, từ đó team của bạn có thể sắp xếp và quyết định xem hạng mục nào là ưu tiên cao nhất cho sprint sắp tới. Trong quá trình thảo luận, nên cho phép các thành viên trong team được hỏi về các hạng mục trong backlog, và sự liên quan của các hạng mục này đối với sprint sắp tới. Với product backlog đã được cập nhật, team nên thống nhất với nhau về mục tiêu, về sprint backlog, và kết quả kỳ vọng của sprint. Nhằm đánh giá mức độ khả thi và thực tế, bạn có thể sử dụng user flow diagrams hoặc các biểu đồ UML để trực quan hóa cách thức từng hạng mục sẽ phù hợp với chiến lược sản phẩm chung như thế nào.

5. Xác định chủ sở hữu của các task

Review lại các hạng mục trong backlog và thảo luận với team để chốt ai sẽ làm task nào. Xác định xem ở mỗi task, điều gì là cần thiết, liên quan tới cả những ràng buộc về mặt nguồn lực và thời gian. Khi bạn đã biết những công việc cần làm, bạn có thể tạo ra Scrum board hoặc biểu đồ swimlane nhằm phác họa trách nhiệm và chốt các mốc deadline trong sprint. Scrum Master cũng cần định nghĩa mức độ hoàn thành của task, để các thành viên có thể đo lường chính xác được tiến độ của họ. Công việc này đòi hỏi một lượng lớn thời gian để thương lượng và hợp tác, nên Scrum Master nên lưu ý về mặt thời gian, nhằm đảm bảo rằng việc thảo luận sẽ diễn ra đúng hướng, trong khoảng thời gian cho phép.

6. Xác nhận các issue mới, mức độ ảnh hưởng và phụ thuộc

Hãy đảm bảo rằng có một khoảng thời gian còn lại để thảo luận có issue nào mới phát sinh ở thời điểm hiện tại hay không (hoặc còn tồn đọng nhưng chưa giải quyết được). Ghi nhận lại từng issue và xác định hành động xử lý, cũng như hành động phòng ngừa các issue tương tự trong tương lai. Product Owner cũng cần dành thời gian để trả lời những câu hỏi từ team.

7. Lấy được sự đồng thuận của team

Sau khi team thảo luận và ước lượng các hạng mục trong sprint backlog, cả team sẽ review lại một lượt và xác nhận kế hoạch của sprint. Hãy đảm bảo rằng kế hoạch của bạn phù hợp với chiến lược của sản phẩm, cũng như khả năng và năng suất của team. Quan trọng nhất, Product Owner và Scrum Master cũng cần xác nhận trên kế hoạch, cũng như khuyến khích sự tự tin, nhiệt huyết của team.

8. Chính thức bắt đầu sprint

Cuối cùng thì bạn cũng có thể bắt đầu sprint. Từ bây giờ, team của bạn sẽ có nhiều việc cần thực hiện, và toàn bộ nguồn lực cần sswowcj sử dụng để xử lý công việc, phối hợp với các bên khác. Hãy xác lập thời gian để check-in công việc với team hàng ngày, nhằm đối chiếu lại với kế hoạch đã xác định trong họp sprint planning, từ đó đảm bảo sprint sẽ về đích tốt đẹp nhất.

Nguồn: https://www.lucidchart.com/

Nhân dịp năm mới, mình dự định sẽ biên tập 1 series bài viết liên quan tới Agile/Scrum. Chúc cộng đồng Viblo ngày càng phát triển và đóng góp giá trị lớn cho cộng đồng IT Việt Nam. Chân thành gửi lời chúc sức khỏe, hạnh phúc và thành công tới toàn thể Viblo Community