Sprint Backlog

Sprint backlog là gì?

Sprint Backlog là 1 phần nhỏ hơn của Product backlog, là danh sách các hạng mục mà đội phát triển dự định chuyển giao trong 1 Sprint, từ đó hoàn thành Sprint goal và tiến gần hơn đến kết quả mong muốn 

Sprint Backlog sẽ chứa các product backlog items mà team đã đồng ý với Product owner sẽ thực hiện vào buổi Sprint Planning. 

Lợi ích của việc thiết lập Sprint Backlog

Hình thành được 1 Sprint Backlog sẽ giúp team có một sự tập trung rõ ràng trong ngắn hạn. Khác với Product backlog là thứ cung cấp 1 cái nhìn tổng thể hơn về sản phẩm, nơi chứa các ý tưởng, hạng mục hướng tới tương lai.

Có một danh sách các Product backlog items trong Sprint backlog sẽ bảo vệ team khỏi việc thay đổi các ưu tiên, và các gián đoạn trong 1 khoảng thời gian ngắn, thường là 2 tuần.

Hơn nữa, giữ cho Sprint backlog minh bạch, hiện hữu được tiến độ thực hiện của các hạng mục là rất cần thiết. Điều này giúp team dễ dàng trao đổi, tương tác dựa trên trạng thái của hạng mục, từ đó tìm cách phối hợp để cùng nhau hoàn thành Sprint Goal.

Ai quản lý Sprint Backlog?

Development team, (đội phát triển) sẽ là người sở hữu và quản lý Sprint backlog. Họ là người sẽ xác định hạng mục nào mới cần thêm vào hoặc các hạng mục nào cần bỏ đi. 

Nếu team phát hiện ra có những nhiệm vụ - task cần hoàn thành để chuyển giao được các hạng mục trong Product Backlog, thì các task đó sẽ trở thành 1 phần của Sprint backlog.  Team có thể thêm, bớt các task trong quá trình diễn ra Sprint. 

Sprint backlog cũng có thể chứa các hạng mục công việc mà team nhận diện từ buổi Sprint Review, Retrospective ở Sprint trước. 

Quản lý Sprint Backlog như thế nào?

Sprint backlog thường được minh họa và tracking qua 1 bảng Kanban board/task board, thể hiện trạng thái dòng chảy công việc. 

Các hạng mục công việc này có thể là user story, được mô tả và có định nghĩa hoàn thành. 

Chúng cũng có thể là bug, cần được fix. Cũng có thể là các nghiên cứu cần được thực hiện, các thay đổi đối với sản phẩm, kiến trúc hoặc hạ tầng. 

Sprint Backlog chỉ tồn tại trong vòng 1 Sprint. Mỗi Sprint mới chúng ta lại khởi tạo 1 sprint backlog mới. Dù vậy, team có thể chọn thêm các hạng mục vào Sprint backlog của Sprint trước để tạo thành 1 Sprint Backlog mới. 

Ví dụ minh họa cách 1 team visualize Sprint Backlog

Team này thể hiện Sprint Backlog dưới dạng Kanban với các cột như sau:

• Cột 1: To Do/Weekly Goal/Sprint Goal: Sau buổi Sprint Planning, team xác định các hạng mục cần làm trong tuần và để ở cột này.
• Cột 2: Doing/In progress: Trong quá trình làm ai bắt đầu làm task nào thì sẽ pick sang cột này để thể hiện trạng thái đang làm
• Cột 3: Review/Staging: Đã làm xong và đang trong trạng thái chờ duyệt, chờ confirm từ PO - Cột 4: Done: Nhiệm vụ đã xong hoàn toàn, deliver được kết quả như mong muốn của customer.

Team có thể sử dụng công cụ Trello hoặc Gitlab để lưu giữ, cập nhật, tương tác trao đổi ngay trên các card.

Xác định Sprint Backlog như thế nào?

Chính trong buổi Sprint Planning, là lúc đội phát triển cùng xác định mục tiêu của Sprint. Đặt câu hỏi Sprint này team mình cần hoàn thành, chuyển giao các hạng mục gì? Làm sao để đạt được các kết quả như mong muốn. 

Bạn có thể xem chi tiết diễn biến 1 buổi Sprint Planning tại đây. 

Tựu chung lại, đây là buổi mà có sự tham gia của Product Owner, đội phát triển, và Scrum master. 

Các bước cụ thể thường thấy: 

Phần 1. Xác định mục tiêu Sprint. 

Phần đầu PO sẽ trình bày mục tiêu mong muốn đạt được qua Sprint này. Đối với một số team tự chủ có mức độ tự quản cao, đã có kế hoạch công việc từ trước thì team sẽ dành thời gian trước buổi Planning để thêm vào Sprint backlog các hạng mục mình muốn hoàn thành. 

Tiếp theo, cả team cùng với PO sẽ bàn bạc, thống nhất các hạng mục quan trọng ưu tiên chuyển giao sớm trong Sprint. Dựa trên năng lực của nhóm mình, team sẽ xác nhận với PO và cam kết với nhau các hạng mục nào là must-have/ ưu tiên cao, các hạng mục nào là should-have/ưu tiên thấp hơn.

Việc tính toán năng lực của nhóm là quan trọng vì nếu không ước lượng kỹ, team bạn có thể nhận nhiều hạng mục hơn sức có thể chuyển giao, dẫn đến quá tải, thậm chí làm nhiều mà chất lượng lại kém.

Phần 2. Xác định cách thực hiện mục tiêu Sprint. 

Đối với các hạng mục công việc được nhắm đến để hoàn thiện trong Sprint, team cần bẻ nhỏ công việc thành các task cụ thể, đủ nhỏ để hoàn thành trong vòng 1 ngày hoặc ít hơn. 

Thông thường các task sẽ thuộc các thể loại: thiết kế giải pháp, viết test case, code, viết tài liệu, nghiên cứu kỹ thuật/công nghệ mới, fixx bug, họp với team ABC, trao đổi với khách hàng,...

1 task được đưa vào Sprint Backlog không chỉ là tiêu đề của task mà còn cần có những thông tin chi tiết như:

• Mô tả task
• Định nghĩa hoàn thành/Acceptance Criteria: trả lời câu hỏi Thế nào là xong? Thế nào là chấp nhận được?. Đây là danh sách các công việc cần được thực hiện để giúp mọi người mường tượng rõ hơn về sản phẩm đầu ra, và tránh hiểu nhầm nhau. 
• Checklist các hành động cần thực hiện để hoàn thành
• Dự kiến thời gian, nỗ lực để hoàn thành.
  

Sau khi tính toán kỹ lưỡng khối lượng công việc, đội phát triển có thể thương lượng với PO để chủ động nhận thêm hoặc bớt các hạng mục kém quan trọng trong Sprint Backlog. 

Cách vận hành Sprint backlog của team Marketing tại Magestore

Team Marketing cũng như các team khác tại Magestore hiện đang vận hành task board trên Gitlab với 8 cột:

• Open: Các task team đã lên lịch thực hiện, các vấn đề tiếp nhận từ khách hàng hoặc từ team khác chưa làm rõ.
• Sprint Backlog: Các task được team xác định sẽ thực hiện trong tuần
• To do: Các vấn đề/task đã được làm rõ và sẵn sàng để thực hiện
• In Progress: Các task đang được thực thi
• Review: Các task non-tech đang được review, hoặc chờ feedback từ người khác. Hoặc các task Tech đang đã được fix/develop, sẵn sàng để test trên Live.
• Done: Task đã hoàn thành
• Close: Các vấn đề đã chốt là kết thúc, không quay trở lại nữa.

Team này định nghĩa 1 cột gọi là Sprint Backlog nơi chứa các hạng mục team muốn hoàn thành trong 1 Sprint nhất định. 

Đầu tuần team sẽ họp Sprint Planning, để xác định Sprint Backlog hay còn gọi là Milestone tuần. Các Task được team ấn định vào Milestone tuần sẽ được move từ cột Open sang cột Sprint Backlog. Với mỗi task được đưa vào cột Sprint Backlog, team đã:

• Viết đoạn chi tiết mô tả các task, với checklist các việc nhỏ hơn cần làm
• Viết định nghĩa hoàn thành và kết quả submit
• Estimate thời gian để hoàn thành.
• Gắn label cho mỗi task. Ví dụ: Các label loại task (Type:Question, Bug), label biểu thị mức độ ưu tiên theo giá trị (Value: Must have, Should have), label theo topic (Topic: Website, SEO, Training, Strategy...).
• Gắn với 1 task owner duy nhất. Ngoài ra còn tag thêm 1 thành viên khác trong team làm supporter nếu cần.

Trong tuần, thành viên nào đang làm task nào thì sẽ tự chuyển trạng thái task đó từ cột Sprint Backlog, sang các cột tiếp theo tương ứng với hiện trạng task mình làm.

Cuối tuần, trong buổi họp Sprint Review, các thành viên team và PO sẽ ngồi lại với nhau để

• Các task chưa hoàn thành, thì chia sẻ phần nào cần hoàn thiện tiếp.
• Trên các card có phần gắn link kết quả nên mọi người sẽ click vào link để review thêm 1 lần.
• Các tasks mà đã hoàn thành rồi thì sẽ Close task đó và close milestone.