Chi tiết về Sprint Planning Checklist cho người mới

admin01

12-04-2024

Sprint Planning Checklist là một công cụ hữu ích nếu được áp dụng ở cấp độ vận hành, giúp giảm tải áp lực của bạn và giúp bạn có thể phân bổ thời gian cho các công việc phù hợp hơn. Bài viết dưới đây của Cole sẽ giúp bạn hiểu rõ về Sprint Planning Checklist và cách thức hoạt động của nó.

Checklists là gì?

Bạn đã bao giờ biết về sự ra đời của checklist hay chưa? Mọi chuyện bắt đầu từ một tai nạn hàng không nhiều năm về trước, khi mà một chiếc máy bay mới với phi hành đoàn giày kinh nghiệm đã bị rơi ngay sau khi cất cánh. Vấn đề nằm ở chỗ, phần kỹ thuật máy bay hoàn toàn bình thường, nguyên nhân gây ra sự cố chính là phi hành đoàn đã bỏ qua một bước đơn giản trong quá trình cất cánh.

Nhìn chung, Checklist không phải là một phương tiện áp đặt các quy trình tiêu chuẩn hóa mà là một công cụ hữu ích cho những người thực hành ngay cả khi họ là Scrum Master sử dụng Sprint Planning Checklist.

Sự ra đời của Checklist mà nhiều người chưa biết

Chi tiết về Scrum Sprint Planning Checklist

Sprint Planning Checklist được mô phỏng theo team Scrum trước đây của một công ty utility truyền thống, đa quốc gia lớn khi bắt đầu hành trình Scrum. Nói cách khác, bạn sẽ không thể áp dụng danh sách kiểm tra này cho team Scrum của mình nếu không kiểm tra và điều chỉnh. Ví dụ: họ đã nỗ lực rất nhiều để chuẩn bị Sprint Planning trong các phiên sàng lọc Product Backlog thường xuyên. (Họ liên tục lên kế hoạch cho hai Sprint tiếp theo trong các phiên sàng lọc.)

Trên thực tế, bản thân Sprint Planning thường là sự xác nhận về những gì họ đã thống nhất trong quá trình sàng lọc Product Backlog. Họ có thể điều chỉnh phạm vi của Sprint đã lên kế hoạch trong quá trình lập kế hoạch năng lực. Tuy nhiên, hiếm khi xảy ra việc họ thay thế Sprint Goal đã dự đoán trước đó bằng một mục tiêu hoàn toàn khác. Do đó, một Sprint Planning thông thường chỉ mất từ một đến hai giờ.

Mẫu bảng Scrum Sprint Planning Checklist

Scrum Team được đề cập thường có quy mô khá lớn, khoảng 8 developers, chủ yếu làm việc cùng vị trí với hai hoặc ba thành viên trong nhóm remote. Họ sử dụng các công cụ Atlassian (Jira, Confluence) và có toàn quyền kiểm soát đường dẫn xây dựng của mình. Nói chung, các stakeholders có ảnh hưởng đáng kể đến hướng đi của Scrum Team, cản trở team nhiều lần trong quá trình này. Do đó, công việc của Scrum Master mang tính chất chiến thuật hoặc vận hành ở xưởng sản xuất nhiều hơn.

Về timeline, T=0 đề cập đến ngày bắt đầu của Sprint sắp tới và T-1 là ngày trước khi bắt đầu Sprint này. Do đó, T+1 là ngày sau Sprint Planning.

Chuẩn bị cho Sprint Planning

T-2: Đặt vị trí cho số lượng open tickets trong cột “code review” & “ready for acceptance columns.” Yêu cầu các thành viên trong nhóm tập trung chuyển tickets sang “Done” trước khi bắt đầu làm việc với tickets mới.
T-1: Yêu cầu các thành viên trong nhóm cập nhật bảng Sprint. (Cần đồng bộ hóa cả bảng Sprint vật lý và online.)
T-1: Chạy Sprint Review. (Hỏi: Chúng ta đã đạt được Sprint Goal chưa và chúng ta vẫn đang đi đúng hướng để đạt được product goal trong Sprint sắp tới chứ?)
T-1: Chạy Sprint Retrospective. (Chọn các action cải tiến liên tục cho Sprint sắp tới.)
T-1: Nhắc nhở các thành viên trong nhóm về Sprint Planning ngày mai.

Hiểu tổng quan về Sprint Planning trước khi bắt đầu

Trong quá trình thực hiện Sprint Planning

T=0: Bắt đầu Sprint Planning bằng cách chia sẻ phiên Zoom cho những thành viên trong nhóm không thể trực tiếp tham gia Sprint Planning.
T=0: Dọn dẹp (các) bảng cũ với toàn bộ Scrum Team bằng cách xem lại bảng, kiểm tra trạng thái của từng ticket và di chuyển các ticket nếu cần. Đồng bộ offline board với Jira board. (Nhóm luôn gặp khó khăn khi trả lời một câu hỏi đơn giản: Bảng nào dẫn đầu? Với các thành viên trong team remote, lẽ ra đó phải là Jira board.)
T=0: Thảo luận về khả năng lan tỏa: Những items Product Backlog chưa hoàn thành đó có còn giá trị không? (Sự lan tỏa là một thước đo phù hợp của nhóm và là một chủ đề hay cho buổi Cải tiến. Nếu tình trạng lan tỏa vẫn tiếp diễn trong một số Sprint, điều này sẽ gây ra nhiều cuộc thảo luận khác nhau trong nhóm, ví dụ:

Kích thước của các items Product Backlog có đúng không?
Việc sàng lọc các items Product Backlog có đầy đủ không? Chúng ta với tư cách là một nhóm có hiểu biết chung về các câu hỏi why, what và how hay không?
Và cuối cùng: Kanban có phù hợp hơn với nhóm không?

T=0: Nếu các item trong Product Backlog được hoàn tác sẽ không tràn sang Sprint sắp tới thì hãy chuyển chúng sang Product Backlog hoặc xóa/lưu trữ chúng.
T=0: Nếu chưa có, hãy tạo “Sprint” mới trong Jira.
T=0: Đóng Sprint trước đó:

Di chuyển tất cả các items của Product Backlog sẽ tràn vào các buckets phù hợp, ví dụ: Upcoming Sprint hoặc Product Backlog.
Xóa physical board khỏi các tickets cũ của Sprint trước.

T=0: Bắt đầu kế hoạch Sprint tiếp theo:

Với tư cách là Scrum Team, hãy tìm hiểu năng lực hiện có của nhóm: Ai có thể đóng góp công việc trong suốt Sprint tiếp theo?
Yêu cầu Product Owner chia sẻ business objective mà Sprint sắp tới sẽ hoàn thành.
Làm cho năng lực của Team Scrum phù hợp với mục tiêu kinh doanh của Product Owner: Điều này có thực tế không?
Nếu business objective và năng lực của nhóm không phù hợp, hãy thử loại bỏ phạm vi Sprint.
Nếu nhóm không thể hoàn thành mục tiêu kinh doanh đã đề xuất, hãy yêu cầu Product Owner đưa ra mục tiêu thực tế.
Tiến hành cộng tác và tạo Sprint Goal.
Development Team chọn các item Product Backlog cần thiết để đáp ứng Sprint Goal.
Hỏi team mình xem liệu scope of work có để lại thời gian rảnh rỗi để giải quyết các vấn đề không mong muốn hay không?
Hỏi team liệu scope of work có cung cấp khả năng giải quyết technical debt và bugs.
Scrum Team tạo các tickets cho physical board. (Đảm bảo tuân thủ mã màu cho các loại stickies khác nhau; các đột biến, user stories, technical tasks, sub-tasks và bugs đều có màu sắc khác nhau rõ ràng.)
T=0: Chạy khảo sát Sprint ẩn danh về Sprint trước đó. (Sprint survey bao gồm bốn câu hỏi: 1. Chúng ta có mang lại giá trị cho khách hàng trong Sprint gần đây không? 2. Mức technical debt có thay đổi trong Sprint vừa qua không? 3. Bạn có muốn giới thiệu một công việc tốt tại tổ chức này không? 4. Cá nhân bạn cảm thấy thế nào về tình hình công việc của mình?)
T=0: Tóm tắt kết quả của buổi Sprint Retrospective trước đó và cập nhật Sprint board mới với các action items. (Team Scrum đã thông báo một cách cởi mở về Retrospective result của họ.)

Các hoạt động nổi bật trong quá trình Sprint Planning

Sau khi thực hiện Sprint Planning

T=+1: Đồng bộ offline board với online board. (Team gặp khó khăn khi xử lý các công việc hành chính. Hơn nữa, do hiểu sai vai trò của Scrum Master nên việc đồng bộ hóa các board thường bị coi là nhiệm vụ của Scrum Master.)
T=+1: Bắt đầu thu thập dữ liệu cho Sprint Retrospective sắp tới, chẳng hạn bằng cách thiết lập Sprint mailbox.
T=+2: Vui lòng nhắc nhở các thành viên trong team tham gia khảo sát Sprint nổi bật. (Số lượng người tham gia tối thiểu là 8 trong số 8 developer cộng với hai business analysts, Product Owner và Scrum Master.)
T=+3: Công bố kết quả khảo sát Sprint của Sprint trước.

Input và output Sprint Planning

Hãy coi Sprint Planning Checklist như một công việc đang được tiến hành cần được xem lại và điều chỉnh thường xuyên. Về phương diện này, Scrum checklists không quá khác biệt, chẳng hạn như các thỏa thuận làm việc hoặc định nghĩa của “Done”. Theo dõi Cole và tham gia thêm các khóa học business analyst để cập nhật các kiến thức hay về lĩnh vực lập trình và khoa học dữ liệu.

>> Xem thêm: Tổng quan về COTS – Commercial-Off-The-Shelf