Sprint Backlog (SB) là một trong ba artefact quan trọng của khung Scrum, cùng với Product Backlog và Increment. SB không chỉ là danh sách các công việc cần thực hiện trong một Sprint mà còn là “bản đồ hành trình” giúp đội ngũ phát triển (Development Team) theo dõi tiến độ, điều chỉnh và tối ưu hoá quy trình làm việc. Khi SB được vẽ (hoặc thiết kế) một cách khoa học, minh bạch và linh hoạt, nó sẽ:
Tăng tính minh bạch: Mọi thành viên đều biết rõ những gì đang được thực hiện, ai đang chịu trách nhiệm và thời gian dự kiến hoàn thành.
Hỗ trợ giao tiếp: Các stakeholder có thể nhanh chóng nắm bắt trạng thái dự án mà không cần tham gia sâu vào chi tiết kỹ thuật.
Giảm rủi ro: Khi có sự thay đổi, đội ngũ có thể nhanh chóng cập nhật và tái ưu hoá các công việc còn lại.
Nâng cao năng suất: SB giúp tập trung vào giá trị thực tế, tránh lãng phí thời gian vào những công việc không cần thiết.
Vậy “cách vẽ Sprint Backlog” thực sự là gì? Bài viết này sẽ cung cấp một quy trình chi tiết, từ chuẩn bị, lựa chọn công cụ, thiết kế layout, đến cách duy trì và cập nhật liên tục trong suốt Sprint.
2. Các yếu tố cốt lõi của Sprint Backlog
Trước khi bắt tay vào vẽ, chúng ta cần hiểu rõ các thành phần cơ bản của SB:
Thành phần
Mô tả
Lợi ích
User Stories / Product Backlog Items (PBIs)
Các mục công việc được chọn từ Product Backlog cho Sprint hiện tại.
Đảm bảo giá trị kinh doanh và mục tiêu Sprint.
Tasks (Công việc chi tiết)
Các công việc nhỏ hơn (thường từ 4‑8 giờ) được tách ra từ mỗi User Story.
Giúp ước lượng thời gian, phân công rõ ràng.
Definition of Done (DoD)
Tiêu chuẩn hoàn thiện cho mỗi công việc.
Đảm bảo chất lượng đồng nhất.
Burndown Chart (Biểu đồ giảm công việc)
Đồ thị thể hiện lượng công việc còn lại theo thời gian.
Theo dõi tiến độ và phát hiện sớm vấn đề.
Sprint Goal
Mục tiêu chung của Sprint, thường là một tuyên bố ngắn gọn.
Định hướng toàn bộ đội ngũ, giúp quyết định ưu tiên.
Impediments (Rào cản)
Các vấn đề đang cản trở tiến độ.
Đưa ra hành động giải quyết kịp thời.
Những yếu tố này sẽ được “vẽ” trong một khung hình (board) sao cho mọi người có thể nhìn thấy và cập nhật một cách dễ dàng.
3. Chuẩn bị trước khi vẽ Sprint Backlog
3.1. Xác định Sprint Goal
Bước 1: Tổ chức buổi Sprint Planning. Đầu tiên, Product Owner (PO) trình bày các mục tiêu kinh doanh, các giá trị cần đạt trong Sprint.
Bước 2: Đội ngũ thảo luận, đưa ra một Sprint Goal ngắn gọn, rõ ràng (điểm mạnh: 1‑2 câu, dễ nhớ).
Bước 3: Ghi Sprint Goal ở vị trí nổi bật trên board (thường ở phía trên cùng).
3.2. Chọn các Product Backlog Items (PBIs)
Tiêu chí chọn: Giá trị kinh doanh cao, độ ưu tiên (Priority) và khả năng hoàn thành trong Sprint (Velocity dựa trên dữ liệu lịch sử).
Kỹ thuật: Sử dụng Planning Poker hoặc T-Shirt Sizing để ước lượng Story Points.
Kết quả: Danh sách PBIs được “đánh dấu” (selected) cho Sprint.
3.3. Phân tách thành Tasks
Cách Vẽ Sprint Backlog
Có thể bạn quan tâm: Cách Vẽ Speed Line Chuẩn Mực: Hướng Dẫn Từ Cơ Bản Đến Nâng Cao Cho Người Mới Bắt Đầu Và Nghệ Sĩ Chuyên Nghiệp
Mỗi PBI được chia thành tasks (công việc chi tiết) trong buổi Backlog Refinement hoặc Sprint Planning.
Quy tắc: Một task không nên kéo dài quá 1 ngày làm việc (8‑10 giờ). Nếu nhiều hơn, hãy tiếp tục chia nhỏ.
Ghi chú: Gắn Assignee (người chịu trách nhiệm) và Estimated Time (thời gian ước tính) cho mỗi task.
3.4. Xác định Definition of Done (DoD)
DoD thường được thống nhất toàn đội: code review, unit test, integration test, tài liệu, deploy lên môi trường staging, v.v.
Đặt DoD ở vị trí dễ nhìn để mọi người luôn nhớ áp dụng.
4. Lựa chọn công cụ vẽ Sprint Backlog
4.1. Công cụ truyền thống (Physical Board)
Ưu điểm
Nhược điểm
– Tương tác trực tiếp, dễ thảo luận nhóm. – Không cần internet, không phụ thuộc vào công nghệ.
– Hạn chế không gian, khó chia sẻ với remote team. – Cập nhật thủ công, dễ lỗi.
Cách thực hiện:
– Sử dụng whiteboard hoặc corkboard.
– Dán các sticky notes màu sắc khác nhau: màu xanh cho “To Do”, màu vàng cho “In Progress”, màu đỏ cho “Impediment”, màu xanh lá cho “Done”.
– Dùng magnetic strips hoặc Kanban cards nếu muốn độ bền cao hơn.
4.2. Công cụ số (Digital Board)
Công cụ
Đặc điểm
Khi nào dùng
Jira
Tích hợp mạnh với Scrum, có burndown chart tự động.
Dự án lớn, đa team, cần báo cáo chi tiết.
Trello
Giao diện trực quan, dễ sử dụng, hỗ trợ Power‑Ups.
Nhóm nhỏ, dự án ngắn hạn, không cần tính năng phức tạp.
Azure DevOps
Tích hợp CI/CD, phù hợp với môi trường Microsoft.
Đội phát triển .NET, Azure.
Miro / Mural
Bảng trắng online, hỗ trợ vẽ tự do, brainstorming.
Khi cần kết hợp brainstorming, thiết kế UI/UX cùng Sprint.
ClickUp
Đa dạng view (list, board, Gantt), tính năng task dependencies.
Dự án đa dạng, muốn quản lý thời gian chi tiết.
Lựa chọn dựa trên:
– Kích thước đội ngũ (small, medium, large).
– Môi trường làm việc (on‑site, remote, hybrid).
– Chi phí (free tier vs paid).
– Tích hợp với các công cụ CI/CD, repo code, test automation.
5. Bước‑bước vẽ Sprint Backlog trên công cụ số
5.1. Tạo Board mới
Cách Vẽ Sprint Backlog
Có thể bạn quan tâm: Cách Vẽ Sóng Biển Đẹp Và Chân Thực: Hướng Dẫn Từng Bước Cho Người Mới Bắt Đầu
Tên board: “Sprint 5 – 2026‑06” (hoặc theo chuẩn naming của công ty).
Columns (cột):
Backlog (To Do) – chứa các tasks chưa bắt đầu.
In Progress – công việc đang thực hiện.
Review / QA – đã hoàn thành code, đang chờ kiểm thử.
Done – đã hoàn thiện và đáp ứng DoD.
Impediments – rào cản, cần hỗ trợ.
Swimlanes (hàng ngang):
User Story 1 (hoặc PBI 1)
User Story 2
…
Bug Fixes (nếu có).
5.2. Thêm các Card (công việc)
Tiêu đề: Ngắn gọn, mô tả hành động (verb + object). Ví dụ: “Implement login API”, “Write unit tests for Cart Service”.
Mô tả: Chi tiết hơn, bao gồm Acceptance Criteria, liên kết tới ticket trên repository (GitHub, GitLab).
Fields:
Assignee (người thực hiện)
Story Points (nếu áp dụng)
Estimated Time (giờ)
Priority (High/Medium/Low)
Labels (frontend, backend, bug, spike…)
5.3. Đánh dấu Sprint Goal và Definition of Done
Sprint Goal: Đặt trong một widget hoặc banner cố định ở trên cùng của board.
DoD: Tạo một card riêng, đặt ở cột “Definition of Done”, hoặc dùng sticky note cố định.
5.4. Thiết lập Burndown Chart
Hầu hết các công cụ (Jira, Azure DevOps) tự động sinh Sprint Burndown dựa trên Story Points hoặc thời gian ước tính.
Đối với Trello, có thể sử dụng Power‑Up “Burndown for Trello” hoặc tích hợp Google Sheets.
5.5. Thiết lập Automation (tùy chọn)
Automation rule: Khi một card chuyển sang “Done”, tự động cập nhật Remaining Hours trong chart.
Reminder: Gửi thông báo Slack/Teams nếu một task chưa di chuyển trong 2 ngày.
6. Cách vẽ Sprint Backlog trên Whiteboard (Physical)
6.1. Chuẩn bị vật liệu
Whiteboard hoặc bảng gỗ (kích thước phù hợp).
Sticky notes (màu xanh – To Do, màu vàng – In Progress, màu xanh lá – Done, màu đỏ – Impediment).
Marker (các màu: đen, xanh, đỏ).
Tape hoặc magnetic strips để chia cột.
6.2. Vẽ bố cục
Header (đầu bảng): Viết Sprint Goal lớn, dùng màu nổi bật.
Columns: Vẽ 4‑5 cột dọc: To Do, In Progress, Review, Done, Impediment.
Swimlanes: Dọc theo cột, chia thành các hàng ngang cho mỗi User Story. Đánh số hoặc viết tiêu đề Story ở đầu mỗi hàng.
Sticky notes: Viết mỗi task trên một sticky note, dán vào đúng cột và hàng tương ứng.
Khi thành viên bắt đầu làm, họ di chuyển sticky note sang In Progress và ghi tên mình trên note.
Khi hoàn thành và qua kiểm thử, chuyển sang Review.
Khi đạt DoD, di chuyển sang Done.
Nếu gặp vấn đề, dán note lên Impediment và thông báo Scrum Master.
6.4. Theo dõi tiến độ
Daily Stand‑up: Mỗi thành viên cập nhật vị trí sticky note, đồng thời Scrum Master ghi lại số lượng note còn lại trong cột To Do + In Progress để tính Burn‑Down thủ công.
Burndown Chart: Vẽ một biểu đồ trên giấy hoặc bảng phụ, cập nhật mỗi ngày.
7. Các Best Practices khi vẽ Sprint Backlog
7.1. Giữ tính Transparency (Minh bạch)
Đảm bảo mọi thành viên đều có quyền truy cập (đọc/viết) vào board.
Không ẩn bất kỳ công việc nào; nếu có công việc “không chính thức”, vẫn ghi lại dưới dạng “Spikes” hoặc “Technical Debt”.
7.2. Đảm bảo Granularity (Mức độ chi tiết)
Tasks nên đủ nhỏ để ước lượng thời gian chính xác, nhưng không quá nhỏ gây lãng phí quản lý.
Nếu một task kéo dài hơn 2 ngày, hãy xem xét chia nhỏ hơn.
7.3. Sử dụng Color Coding (Mã màu)
Màu xanh – Feature development.
Màu vàng – Bug fixing.
Màu tím – Technical spikes.
Màu đỏ – Impediment.
7.4. Đánh dấu Priority và Dependency
Đối với công việc phụ thuộc, sử dụng arrow hoặc link trên công cụ số; trên bảng vật lý, vẽ mũi tên giữa các sticky notes.
Đảm bảo các task quan trọng (High Priority) luôn ở vị trí dễ nhìn.
7.5. Kiểm tra Definition of Done thường xuyên
Mỗi lần một task chuyển sang “Done”, người chịu trách nhiệm kiểm tra lại DoD.
Nếu DoD chưa được đáp ứng, đưa task trở lại cột “In Progress” hoặc “Review”.
7.6. Cập nhật Impediments ngay lập tức
Cách Vẽ Sprint Backlog
Có thể bạn quan tâm: Cách Vẽ Songoku Ultra: Hướng Dẫn Chi Tiết Từ Cơ Bản Đến Nâng Cao
Khi một impediment xuất hiện, người phát hiện phải dán note vào cột Impediment và thông báo Scrum Master.
Scrum Master chịu trách nhiệm giải quyết hoặc escalates ngay trong ngày.
7.7. Đánh giá Velocity sau mỗi Sprint
Tổng Story Points (hoặc giờ) đã hoàn thành = Velocity của Sprint.
Sử dụng velocity để ước lượng khả năng của Sprint tiếp theo, tránh over‑commit.
8. Khi nào và làm sao để re‑plan Sprint Backlog
8.1. Các trường hợp cần re‑plan
Scope change: PO đưa thêm một PBI quan trọng.
Impediment nghiêm trọng: Một task lớn bị chặn, thời gian hoàn thành kéo dài.
Capacity change: Thành viên nghỉ phép, bệnh, hay tăng thành viên mới.
8.2. Quy trình re‑plan
Daily Stand‑up → Nhận thông tin vấn đề.
Scrum Master → Ghi lại các rủi ro, đề xuất giải pháp.
Sprint Review (nếu gần cuối Sprint) → Đánh giá mức độ hoàn thành, quyết định giữ, hoãn hoặc chuyển sang Sprint tiếp.
Sprint Retrospective → Rút kinh nghiệm, cập nhật cách vẽ và quản lý SB cho Sprint sau.
8.3. Cập nhật board
Thêm/loại bỏ task, cập nhật estimate và assignee.
Đánh dấu các task đã bị de‑scoped bằng màu xám hoặc “canceld” label.
Cập nhật Burndown Chart để phản ánh thay đổi.
9. Ví dụ thực tế: Vẽ Sprint Backlog cho một dự án e‑commerce
9.1. Sprint Goal
“Cung cấp tính năng giỏ hàng (Cart) hoàn chỉnh, hỗ trợ thêm, sửa, xóa sản phẩm và tính toán tổng tiền.”
Cách Vẽ Sprint Backlog
9.2. Product Backlog Items đã chọn
#
PBI
Story Points
1
“User can add product to cart”
8
2
“User can view cart summary”
5
3
“User can update quantity”
5
4
“User can remove product from cart”
3
5
“Calculate total price with discounts”
8
6
“Persist cart data across sessions”
5
9.3. Tasks (với màu sắc)
PBI
Task
Assignee
Estimate (h)
Màu
1
Design DB schema for Cart
Linh (Backend)
4
Xanh
1
Implement API POST /cart/add
Nam (Backend)
6
Xanh
1
Frontend UI button “Add to Cart”
Huy (Frontend)
3
Vàng
2
Create Cart Summary page
Huy (Frontend)
5
Vàng
2
API GET /cart
Nam
4
Xanh
3
UI edit quantity component
Huy
3
Vàng
3
API PUT /cart/{itemId}
Nam
4
Xanh
4
Delete button UI
Huy
2
Vàng
4
API DELETE /cart/{itemId}
Nam
3
Xanh
5
Discount calculation engine
Linh
6
Xanh
5
Unit tests for discount
Linh
4
Xanh
6
Store cart in localStorage
Huy
3
Vàng
6
Sync cart with server on login
Nam
5
Xanh
9.4. Board layout (digital)
Columns: To Do → In Progress → Review → Done → Impediment.
Swimlanes: Mỗi PBI là một hàng, các task nằm dưới hàng tương ứng.
Burndown: Dựa trên tổng 45 giờ (hoặc 37 Story Points). Mỗi ngày cập nhật giờ còn lại.
9.5. Kết quả cuối Sprint
Completed Story Points: 33/37 (90%).
Impediments: “Discount engine performance issue” → giải quyết bằng refactor, được chuyển sang Sprint tiếp theo.
Velocity: 33 points → dùng làm dự báo cho Sprint tiếp.
10. Những lỗi thường gặp khi vẽ Sprint Backlog và cách tránh
Lỗi
Mô tả
Cách khắc phục
Over‑commit
Chọn quá nhiều PBIs, không đạt được Sprint Goal.
Dùng Velocity lịch sử để ước lượng, luôn để khoảng dự phòng 20‑30%.
Under‑detail
Tasks quá lớn, không biết bắt đầu từ đâu.
Chi tiết hoá task, đảm bảo mỗi task ≤ 8‑10 giờ.
Không cập nhật
Board bị bỏ quên, thông tin lỗi thời.
Đặt reminder hàng ngày, Scrum Master kiểm tra trong Stand‑up.
Không phản ánh impediment
Rào cản không được ghi lại, dẫn tới trì hoãn.
Tạo cột Impediment ngay, yêu cầu mọi người báo ngay khi gặp vấn đề.
Mất tính minh bạch
Chỉ một vài người mới xem được board.
Đảm bảo quyền truy cập cho toàn bộ team, sử dụng công cụ cloud nếu có remote.
Không tuân DoD
Đưa “Done” mà chưa đáp ứng tiêu chuẩn.
Kiểm tra DoD trước khi chuyển sang “Done”, thực hiện peer review.
Quá phụ thuộc vào công cụ
Khi công cụ gặp lỗi, mất dữ liệu.
Thường xuyên backup, hoặc có bản sao trên whiteboard.
11. Tổng kết: Quy trình “cách vẽ Sprint Backlog” trong 7 bước chính
Xác định Sprint Goal – Định hướng chung, viết nổi bật.
Lựa chọn PBIs – Dựa trên priority và capacity.
Phân tách thành tasks – Đảm bảo độ chi tiết, ước lượng thời gian.
Chọn công cụ – Physical board hoặc Digital board phù hợp.
Tạo layout board – Columns, swimlanes, màu sắc, DoD, Impediments.
Cập nhật liên tục – Daily Stand‑up, chuyển task, ghi chú impediment, cập nhật burndown.
Đánh giá và cải tiến – Sprint Review, Retrospective, điều chỉnh cách vẽ cho Sprint sau.
Khi thực hiện đúng quy trình trên, Sprint Backlog không chỉ là một danh sách công việc mà còn trở thành công cụ giao tiếp, quản lý rủi ro và nâng cao năng suất cho toàn bộ đội Scrum. Đừng quên rằng SB luôn là một artefact động – nó thay đổi, được cập nhật và cải tiến liên tục dựa trên phản hồi thực tế của đội ngũ.
Nhắc nhở cuối cùng: Đừng để Sprint Backlog trở thành “bức tường” không thể di chuyển. Hãy giữ nó linh hoạt, minh bạch và luôn phản ánh thực tế công việc. Khi mọi người trong team cảm thấy “sở hữu” board, năng lực cộng tác sẽ tăng lên đáng kể, và kết quả Sprint sẽ luôn đạt hoặc vượt mục tiêu đã đề ra. Chúc bạn và đội ngũ Scrum thành công trong việc vẽ và sử dụng Sprint Backlog một cách tối ưu!
