Sprint planning là gì? PO cần chuẩn bị gì trước buổi họp

Sáng mai họp sprint planning, bạn mang gì vào phòng?

Bạn làm PO cho ứng dụng đặt trà của một cửa hàng trà online. Sáng mai team họp sprint planning cho sprint hai tuần tiếp theo. Bạn mở backlog: hơn bốn mươi mục, có cái viết đủ, có cái chỉ một dòng “làm lại giỏ hàng”. Sếp vừa nhắn muốn có tính năng đặt lại đơn cũ trước đợt khuyến mãi. Kỹ sư thì từng nhắc phần thanh toán cần sửa lỗi tồn.

Đây là tình huống minh họa. Câu hỏi của bạn lúc này rất cụ thể: tối nay mình cần chuẩn bị gì, và sáng mai mình nói gì trong phòng họp? Có nên chia task cho từng người không? Có nên đề xuất luôn mỗi việc mất bao nhiêu ngày không?

Bài này trả lời theo Scrum Guide 2020 và theo cách làm thực tế của một PO mới: đến buổi họp với một đề xuất mục tiêu và phần đầu backlog đã sẵn sàng, rồi để team cùng quyết phần còn lại.

Vì sao sprint planning dễ rối với PO mới?

Sprint planning là buổi họp mở đầu sprint, nơi cả Scrum Team cùng lập kế hoạch cho sprint đó. Nghe đơn giản, nhưng người mới dễ vấp ở ba chỗ.

• Nhầm vai. Nhiều người mới nghĩ PO là người “giao việc”, nên đến buổi họp với danh sách ai làm gì. Theo Scrum Guide, Developers chọn việc cho sprint và tự quyết cách làm.
• Backlog chưa sẵn sàng. Nếu các mục trên cùng còn mơ hồ, buổi họp biến thành buổi viết yêu cầu tại chỗ. Thời gian hết mà chưa chốt được gì.
• Muốn nhiều hơn khả năng của team. Sếp muốn, khách muốn, bạn cũng muốn. Khi team nói không đủ thời gian, PO mới dễ ép thêm hoặc im lặng chấp nhận một kế hoạch không ai tin.

Gốc chung của ba lỗi này là đến buổi họp mà chưa chuẩn bị đúng phần việc của mình. Phần việc của PO không nằm ở chia task. Nó nằm ở hai thứ: vì sao sprint này đáng làm, và việc nào quan trọng nhất cần bàn trước.

Sprint planning gồm những phần nào?

Scrum Guide 2020 chia sprint planning thành ba chủ đề. Hiểu ai dẫn phần nào sẽ giúp bạn biết mình cần chuẩn bị gì và khi nào nên để team nói.

Ở chủ đề “vì sao”, Scrum Guide ghi rõ PO đề xuất cách sản phẩm có thể tăng giá trị trong sprint, rồi cả Scrum Team cùng xác định Sprint Goal. Sprint Goal phải được chốt trước khi buổi họp kết thúc.

Ở chủ đề “làm gì”, Developers chọn các mục từ Product Backlog qua trao đổi với PO. Scrum.org lưu ý dự báo của team đáng tin hơn khi họ hiểu hiệu suất các sprint trước, khả năng sắp tới và Definition of Done. Ở chủ đề “làm thế nào”, Scrum Guide nói cách làm hoàn toàn do Developers quyết.

Về thời lượng, Scrum Guide giới hạn tối đa tám giờ cho sprint một tháng. Sprint ngắn hơn thì buổi họp thường ngắn hơn. Một buổi kéo dài quá mức có thể là dấu hiệu backlog chưa được chuẩn bị.

Cần chuẩn bị gì 1 đến 2 ngày trước sprint planning?

Chuẩn bị trước một đến hai ngày cho bạn thời gian hỏi lại sếp, vận hành hay kỹ sư khi phát hiện chỗ còn thiếu. Để đến tối hôm trước thì không còn ai để hỏi.

• Xem lại Product Goal và kết quả sprint trước. Sprint vừa rồi xong gì, còn dở gì, có phản hồi nào từ người dùng hay stakeholder làm thay đổi ưu tiên không.
• Viết một đề xuất Sprint Goal. Một câu, nói sprint này mang lại giá trị gì cho ai. Đây là đề xuất, không phải quyết định cuối.
• Sắp thứ tự phần đầu backlog. Không cần sắp cả bốn mươi mục. Chỉ cần các mục có khả năng vào sprint này, cộng thêm vài mục dự phòng. Nếu đang bị nhiều bên ép ưu tiên, xem thêm bài về ưu tiên backlog.
• Kiểm tra các mục trên cùng đã đủ rõ chưa. Mỗi mục nên có người dùng, vấn đề, phạm vi và tiêu chí chấp nhận. Team bạn có Definition of Ready thì dùng nó để soát.
• Ghi lại phụ thuộc và rủi ro. Việc nào cần bộ phận khác, cần dữ liệu, cần quyết định của sếp, hay cần thiết kế xong trước.
• Hỏi trước về capacity. Ai nghỉ phép, ai phải trực hỗ trợ, có ngày lễ hay việc phát hành nào chiếm thời gian. Đây là thông tin để team tự tính, bạn chỉ gom sẵn.
• Đoán trước câu hỏi. Đọc từng mục như thể bạn là kỹ sư: chỗ nào sẽ bị hỏi “trường hợp này thì sao”? Trả lời trước, hoặc ghi rõ là chưa biết.

Nếu các mục trên cùng còn thiếu, cách tốt nhất là xử lý trong buổi refinement trước đó, không phải trong sprint planning. Scrum Guide mô tả refinement là việc chia nhỏ và làm rõ thêm các mục backlog, và người làm việc đó sẽ chịu trách nhiệm ước lượng.

• Ưu tiên backlog khi việc nào cũng gấp
• Definition of Ready và Definition of Done
• Cách viết user story cho người mới

Trong buổi họp, PO dẫn phần “làm gì” thế nào?

Khi đã có Sprint Goal đề xuất, phần “làm gì” là cuộc trao đổi giữa bạn và Developers. Bạn mang thứ tự và lý do. Team mang hiểu biết về độ khó, rủi ro và khả năng của mình. Mountain Goat Software nhấn mạnh sprint planning nên là cộng tác, không phải buổi bàn giao việc.

Một trình tự đơn giản có thể dùng:

• Mở đầu bằng mục tiêu. Đọc Sprint Goal đề xuất và nói vì sao nó quan trọng lúc này. Hỏi team: mục tiêu này có hợp lý với tình hình hiện tại không?
• Đi từ trên xuống. Giới thiệu từng mục theo thứ tự, mỗi mục nói ngắn người dùng, vấn đề và cách biết đã xong. Để team hỏi, đừng đọc hết tài liệu.
• Để team dừng. Khi Developers thấy đã đủ việc, họ nói. Bạn không cần đẩy thêm. Nếu còn chỗ, bạn đề xuất mục tiếp theo.
• Kiểm tra lại mục tiêu. Nhìn danh sách vừa chọn: nó có thật sự phục vụ Sprint Goal không? Nếu không, sửa danh sách hoặc sửa mục tiêu.
• Chốt điều chưa biết. Ghi lại câu hỏi chưa trả lời được, ai trả lời và trước khi nào.

Khi team hỏi một câu bạn chưa biết, nói thẳng là chưa biết và hẹn thời điểm trả lời. Đoán bừa trong buổi họp dễ dẫn tới team làm theo một quy tắc không ai xác nhận.

Khi capacity ít hơn số việc muốn làm thì sao?

Capacity là khả năng làm việc thực tế của team trong sprint này, sau khi trừ nghỉ phép, việc hỗ trợ, họp và việc phát hành. Mountain Goat Software lưu ý velocity các sprint trước có thể tham khảo, nhưng capacity của chính sprint đang lên kế hoạch mới là thứ quyết định.

Khi việc muốn làm nhiều hơn khả năng, ép team nhận thêm không làm tăng capacity. Nó chỉ làm kế hoạch kém đáng tin. Bạn có bốn hướng đáng cân nhắc.

Điều không nên làm là giữ nguyên danh sách và hy vọng team làm thêm giờ. Scrum Guide có cơ chế cho tình huống công việc khác dự kiến: Developers trao đổi với PO để thương lượng lại phạm vi trong sprint, miễn không ảnh hưởng Sprint Goal. Cơ chế này chỉ chạy được khi mục tiêu đủ rõ để biết phần nào cắt được.

Ví dụ: Sprint Goal tốt và chưa tốt

Quay lại ứng dụng đặt trà. Bảng dưới là các ví dụ minh họa. Các con số trong cột “Bản tốt hơn” là con số giả định, team thật sẽ thay bằng con số của mình.

Điểm chung của các bản tốt hơn: nói rõ ai được lợi, được lợi gì, và có dấu hiệu nhìn thấy được để biết đã đạt. Bản cuối còn cho biết phần nào có thể cắt nếu công việc khó hơn dự kiến. Đó là lúc Sprint Goal phát huy tác dụng: nó giúp team chọn cắt gì mà không phải hỏi lại PO từng chuyện.

Trong ví dụ đầu bài, nếu team chọn mục tiêu đặt lại đơn cũ, lỗi thanh toán vẫn có thể vào sprint như một mục riêng nếu còn capacity. Nó không cần nằm trong câu Sprint Goal. Scrum Guide gọi Sprint Goal là mục tiêu duy nhất của sprint, không phải danh sách mọi việc sẽ làm.

Mẫu checklist chuẩn bị và khung Sprint Goal

Hai mẫu dưới đây dùng được ngay. Bạn copy vào ghi chú, sửa theo cách team đang gọi tên mọi thứ.

1 đến 2 ngày trước buổi họp:
[ ] Đã xem lại Product Goal và kết quả sprint trước.
[ ] Đã có một đề xuất Sprint Goal trong một câu.
[ ] Đã sắp thứ tự các mục có khả năng vào sprint, kèm vài mục dự phòng.
[ ] Mỗi mục trên cùng có người dùng, vấn đề, phạm vi và tiêu chí chấp nhận.
[ ] Đã ghi phụ thuộc: bộ phận khác, dữ liệu, thiết kế, quyết định còn chờ.
[ ] Đã gom thông tin capacity: nghỉ phép, trực hỗ trợ, ngày lễ, việc phát hành.
[ ] Đã đọc từng mục như kỹ sư và trả lời trước câu hỏi dễ gặp.
[ ] Đã biết phần nào của mục tiêu có thể cắt nếu không đủ thời gian.

Trong buổi họp:
[ ] Mở đầu bằng mục tiêu và lý do.
[ ] Để Developers chọn số việc và cách làm.
[ ] Kiểm tra lại danh sách đã chọn có phục vụ mục tiêu không.
[ ] Chốt Sprint Goal trước khi kết thúc.
[ ] Ghi câu hỏi còn mở, người trả lời và hạn trả lời.

Cuối sprint này, [ai] có thể [làm được điều gì],
để [kết quả hoặc vấn đề được giải quyết].
Ta biết đã đạt khi [dấu hiệu nhìn thấy được].
Nếu không đủ thời gian, phần có thể để sau là [phần cắt được].

Dòng cuối trong khung dễ bị bỏ qua nhưng đáng giữ. Nó giúp team và bạn thống nhất trước điều gì là cốt lõi, điều gì là phần thêm, nên khi sprint gặp khó, cuộc thương lượng phạm vi diễn ra nhanh hơn.

Những lỗi PO mới hay mắc trong sprint planning

• Đến họp mà chưa có mục tiêu. Buổi họp thành buổi chọn ticket, cuối sprint không ai nói được sprint này để làm gì.
• Chia task và áp số ước lượng. Việc này lấy mất quyền của Developers và có thể làm ước lượng kém sát hơn, vì người làm mới là người hiểu độ khó.
• Viết yêu cầu ngay trong buổi họp. Nếu một mục cần hơn vài phút để giải thích, có thể nó chưa sẵn sàng; cân nhắc đưa về refinement.
• Ghép nhiều mục tiêu vào một câu. Khi mọi thứ đều là mục tiêu, team không biết cắt gì khi gặp khó.
• Im lặng khi kế hoạch quá tải. Nếu bạn thấy team nhận nhiều hơn khả năng, hỏi thẳng: phần nào mình có thể để sau mà vẫn giữ mục tiêu?
• Hứa với stakeholder trước buổi họp. Hứa ngày phát hành khi team chưa chọn việc đặt cả team vào thế khó.

Tóm tắt

• Sprint planning trả lời ba câu: vì sao (Sprint Goal), làm gì và làm thế nào. PO dẫn phần đầu, Developers quyết phần cuối.
• Chuẩn bị trước 1 đến 2 ngày: đề xuất Sprint Goal, sắp thứ tự phần đầu backlog, kiểm tra độ rõ, ghi phụ thuộc, gom thông tin capacity.
• Trong buổi họp, PO mang thứ tự và lý do. Developers chọn bao nhiêu việc và tự quyết cách làm.
• Khi việc nhiều hơn khả năng: thu hẹp mục tiêu, cắt nhỏ mục backlog, đổi thứ tự, hoặc báo sớm cho người chờ.
• Sprint Goal tốt nói ai được lợi, được lợi gì, khi nào là đạt, và phần nào có thể để sau.

Mình đang soạn thêm các tình huống PO khác theo cùng khung này, kèm mẫu dùng ngay. Nếu bạn muốn nhận khi có bài mới, đăng ký bản tin bên dưới.

• Nhận bài mới qua email

Câu hỏi thường gặp

Product Owner cần chuẩn bị gì trước sprint planning?

Một đề xuất Sprint Goal, phần đầu backlog đã sắp thứ tự và đủ rõ để bàn, cùng câu trả lời cho các câu hỏi team có thể hỏi về giá trị, phạm vi và tiêu chí chấp nhận. Nên chuẩn bị trước 1 đến 2 ngày để còn thời gian hỏi lại người liên quan.

Ai quyết định team làm bao nhiêu việc trong sprint?

Theo Scrum Guide 2020, Developers chọn các mục backlog đưa vào sprint, qua trao đổi với Product Owner. PO đề xuất thứ tự và giải thích giá trị, nhưng không áp số lượng hay ước lượng.

Sprint Goal là gì?

Sprint Goal là mục tiêu duy nhất của sprint, nói vì sao sprint này có giá trị. PO đề xuất, cả Scrum Team cùng chốt, và mục tiêu phải xong trước khi buổi sprint planning kết thúc.

Nguồn kiểm tra

• Scrum Guide 2020: Sprint Planning
• Scrum.org: What is Sprint Planning?
• Mountain Goat Software: Sprint Planning Meeting

Bài liên quan

• User story là gì? Cách viết cho người mới, kèm mẫu và ví dụ: Mẫu “Là…, tôi muốn…, để…” là phần dễ. Bài này chỉ cách chọn đúng người dùng, đúng vấn đề và cắt story đủ nhỏ, kèm ví dụ trước và sau.
• Acceptance criteria là gì? Cách viết để QA kiểm thử được: Cách viết acceptance criteria rõ đến mức QA đọc xong là biết phải thử gì, kèm ví dụ mã giảm giá và mẫu dùng ngay.
• Ưu tiên backlog khi việc nào cũng gấp: chọn cách nào?: Cách chọn giữa value vs effort, MoSCoW và RICE, tách hạn chót thật khỏi cảm giác gấp, và gửi stakeholder một ghi chú ưu tiên một trang.
• Cách nói không với sếp và stakeholder mà không mất lòng: Ba cách nói không thay cho một chữ “không”, cách xử lý khi người yêu cầu là sếp hoặc CEO, lúc nào nên escalate, kèm hội thoại mẫu và tin nhắn theo từng cấp.