Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn là PM của một team 6 người. Sprint tới kéo dài 2 tuần, và theo velocity trung bình mấy sprint gần đây, team hoàn thành được khoảng 40 story points mỗi sprint. Bạn tự tin kéo 40 điểm vào Sprint Planning. Nhưng bạn quên mất: sprint này rơi vào tuần có nghỉ lễ Giỗ Tổ Hùng Vương, hai bạn dev đã đăng ký nghỉ phép đi du lịch, và bạn QA thì phải dành 30% thời gian hỗ trợ team khác. Kết quả? Cuối sprint chỉ xong 24 điểm, backlog dồn ứ, stakeholder thất vọng, và team cảm thấy áp lực vì "không đạt cam kết".
Đây chính xác là vấn đề mà Capacity Planning (lập kế hoạch năng lực) giải quyết. Velocity cho bạn biết team thường làm được bao nhiêu trong điều kiện bình thường. Nhưng không có sprint nào là "bình thường" cả — luôn có người nghỉ phép, có ngày lễ, có họp hành, có công việc hỗ trợ đột xuất. Capacity Planning là kỹ năng điều chỉnh kỳ vọng của sprint dựa trên năng lực thực tế của team trong khoảng thời gian cụ thể đó.
Với một PM, đây không phải bài toán kỹ thuật khô khan. Đây là công cụ giúp bạn cam kết đúng, bảo vệ team khỏi quá tải, và xây dựng lòng tin với stakeholder bằng những con số đáng tin cậy. Trong bài này chúng ta sẽ đi từ các yếu tố đầu vào của capacity, cách quản lý lịch nghỉ của team (Team Calendar) trong hệ sinh thái Jira, đến quy trình tính toán năng lực cho từng sprint.
Khái niệm cốt lõi
Capacity Planning là gì
Capacity Planning là quá trình xác định team của bạn thực sự có bao nhiêu năng lực làm việc trong một khoảng thời gian nhất định (thường là một sprint), sau đó dùng con số đó để quyết định nên đưa bao nhiêu công việc vào sprint. Nó khác với velocity ở chỗ: velocity là dữ liệu quá khứ (đã làm được bao nhiêu), còn capacity là dự báo tương lai (sắp tới làm được bao nhiêu, có tính đến các yếu tố đặc thù).
Có hai cách phổ biến để đo capacity:
- Theo giờ (hours-based): Tính tổng số giờ làm việc thực tế available của cả team trong sprint. Phù hợp khi team ước lượng công việc bằng giờ, hoặc dùng Kanban.
- Theo story points: Điều chỉnh velocity trung bình theo tỷ lệ available của team. Phù hợp với team Scrum estimate bằng points.
Bốn nhóm đầu vào của Capacity
Để tính capacity chính xác, bạn cần thu thập bốn nhóm thông tin đầu vào (inputs). Đây là xương sống của cả bài học.
1. Team size + role (quy mô và vai trò của team)
Không phải cứ 6 người là có 6 đơn vị năng lực như nhau. Bạn cần biết rõ vai trò: sprint này có bao nhiêu dev backend, bao nhiêu frontend, bao nhiêu QA. Nếu công việc trong sprint nghiêng nhiều về frontend nhưng team chỉ có một bạn frontend duy nhất, thì "nút cổ chai" nằm ở đó — tổng capacity của cả team không giúp ích nếu công việc bị dồn vào một vai trò thiếu người. PM giỏi luôn tính capacity theo từng nhóm vai trò khi công việc có tính chuyên môn hóa cao.
2. Velocity historical (velocity lịch sử)
Đây là dữ liệu nền tảng. Bạn lấy velocity của 3–6 sprint gần nhất, tính trung bình. Ví dụ ba sprint gần nhất là 38, 42, 40 → velocity trung bình khoảng 40 points. Con số này giả định team làm việc trong điều kiện đầy đủ. Nó chính là điểm khởi đầu để bạn điều chỉnh xuống theo các yếu tố còn lại.
3. PTO calendar (lịch nghỉ — vacation, holiday)
PTO là viết tắt của Paid Time Off — thời gian nghỉ có lương. Bạn cần nắm rõ trong sprint sắp tới:
- Ngày lễ chung: Tết Nguyên Đán, Giỗ Tổ Hùng Vương (10/3 âm lịch), 30/4 – 1/5, Quốc khánh 2/9... Ở Việt Nam mấy dịp này thường kéo dài và ảnh hưởng cả team.
- Nghỉ phép cá nhân: Ai đăng ký nghỉ phép, nghỉ ốm, đi công tác, nghỉ cưới...
- Ngày làm việc bán thời gian: Ai đó chỉ làm buổi sáng, hoặc làm 3/5 ngày trong tuần.
4. Capacity factor (hệ số năng lực — focus time, meetings, support)
Đây là yếu tố tinh tế nhất mà nhiều PM bỏ qua. Ngay cả khi một bạn dev đi làm đủ 8 tiếng/ngày, không phải cả 8 tiếng đó đều dành cho công việc sprint. Thời gian bị "ăn mòn" bởi:
- Meetings: Daily standup, planning, review, retro, các cuộc họp 1:1, họp với stakeholder.
- Support / interruptions: Trả lời câu hỏi từ team khác, xử lý bug production khẩn cấp, review code, hỗ trợ vận hành.
- Context switching + overhead: Đọc email, cập nhật Jira, chờ CI/CD chạy...
Team Calendar trong hệ sinh thái Jira
Bản thân Jira core không có tính năng lịch nghỉ mạnh mẽ, nhưng hệ sinh thái Atlassian và các add-on cung cấp nhiều lựa chọn:
- Team Calendars for Confluence: Add-on chính thức của Atlassian, cho phép tạo lịch nghỉ, đánh dấu PTO, ngày lễ, và đồng bộ với Jira. Đây là công cụ phổ biến nhất khi công ty đã dùng cả Jira lẫn Confluence.
- Capacity view trong Advanced Roadmaps (Plans): Ở gói Jira Premium, tính năng Plans cho phép nhập capacity theo tuần/sprint cho từng thành viên, có tính đến ngày nghỉ, và cảnh báo khi kế hoạch vượt quá năng lực.
- Add-on từ Marketplace: Các plugin như Tempo Timesheets, ActivityTimeline, Great Gadgets cung cấp capacity planning và resource management chuyên sâu.
- Giải pháp nhẹ: Nhiều team Việt Nam đơn giản dùng một Google Sheet hoặc Confluence page để theo dõi lịch nghỉ, rồi PM tính capacity thủ công. Hoàn toàn ổn khi team nhỏ.
Tình huống thực tế
Ví dụ 1 — Team fintech TP.HCM và cái bẫy ngày lễ 30/4
Công ty fintech "MoMoPay" (giả định) có một squad 5 dev + 1 QA, velocity trung bình 45 points/sprint (sprint 2 tuần = 10 ngày làm việc). PM tên Linh chuẩn bị planning cho sprint rơi vào cuối tháng 4.
Linh suýt kéo nguyên 45 points, nhưng may là chị mở Team Calendar ra kiểm tra. Sprint này có nghỉ lễ 30/4 và 1/5 rơi vào thứ Tư – thứ Năm, cộng thêm hai bạn dev đã đăng ký nghỉ phép "gộp" thêm thứ Sáu để về quê 3 ngày.
Linh tính lại:
- Tổng ngày-người lý thuyết: 6 người × 10 ngày = 60 ngày-người.
- Trừ 2 ngày lễ toàn team: 6 × 2 = 12 ngày-người mất đi.
- Trừ nghỉ phép cá nhân: 2 dev × 1 ngày = 2 ngày-người.
- Còn lại: 60 − 12 − 2 = 46 ngày-người available (so với 60 ngày lý thuyết = 76,7%).
- Capacity điều chỉnh: 45 × 76,7% ≈ 34,5 points.
Bài học: Luôn kiểm tra Team Calendar trước khi cam kết. Một phép tính 5 phút giúp tránh cả sprint thất bại.
Ví dụ 2 — Startup Đà Nẵng và focus factor bị thổi phồng
Startup SaaS "GreenLeaf" ở Đà Nẵng có team 8 người, velocity ghi nhận 60 points. PM tên Đức thấy sprint này không có ai nghỉ phép, không ngày lễ, nên tự tin kéo full 60 points. Nhưng sprint nào cũng "cháy", thường chỉ xong 45–48 points.
Đức mời mentor review. Vấn đề lộ ra: team đang gánh rất nhiều công việc ngoài sprint mà không ai tính đến. Cụ thể, hai dev senior phải dành khoảng 40% thời gian support khách hàng và fix bug production; team mới thành lập nên họp hành nhiều (daily 30 phút, cộng vô số họp ad-hoc).
Mentor hướng dẫn Đức tính focus factor thực tế bằng cách nhìn lại: velocity 60 vốn dĩ đã bao hàm các gián đoạn này rồi (vì velocity là dữ liệu thực tế đã xảy ra). Sai lầm của Đức là kéo 60 points nhưng lại kỳ vọng nó chạy trong điều kiện lý tưởng. Thực chất khi có thêm một dự án support đột xuất, focus factor sụt từ ~70% xuống ~55%.
Đức điều chỉnh: chỉ cam kết 45 points làm mục tiêu chính (commit), và để 10 points làm "stretch goal" (mục tiêu vươn tới nếu rảnh). Từ đó team đạt cam kết đều đặn, tinh thần cải thiện rõ.
Bài học: Velocity đã phản ánh focus factor lịch sử. Đừng "cam kết theo con số đẹp" rồi kỳ vọng điều kiện lý tưởng. Khi có yếu tố bất thường (support tăng, thành viên mới, họp nhiều), hãy chủ động hạ capacity xuống.
Ví dụ 3 — Team outsourcing và bài toán capacity theo vai trò
Công ty outsourcing "TechBridge" (giả định) nhận dự án cho khách Nhật, team gồm 4 backend, 1 frontend, 1 QA. Sprint tới backlog toàn là màn hình UI mới — công việc frontend chiếm phần lớn.
PM tính tổng capacity cả team ra 50 points và định kéo hết. Nhưng khi nhìn theo vai trò, chị nhận ra: 50 points này nếu 35 điểm là công việc frontend thì bất khả thi, vì chỉ có 1 bạn frontend duy nhất, capacity riêng của bạn đó chỉ đủ cho ~12 điểm frontend/sprint. Bốn bạn backend có ngồi chơi cũng không code UI thay được.
Giải pháp: chị làm việc với team để (1) chỉ đưa ~12 điểm frontend vào sprint, (2) tận dụng backend capacity cho các task API và refactor, (3) sắp xếp một backend học cross-skill làm frontend cơ bản cho sprint sau.
Bài học: Với team có chuyên môn hóa cao, phải tính capacity theo từng vai trò, không chỉ nhìn tổng. Nút cổ chai luôn nằm ở vai trò thiếu người nhất so với khối lượng công việc.
Hướng dẫn từng bước
Đây là quy trình chuẩn để làm capacity planning trước mỗi Sprint Planning:
Bước 1 — Xác định độ dài sprint và ngày làm việc chuẩn. Ví dụ sprint 2 tuần = 10 ngày làm việc/người.
Bước 2 — Liệt kê team và vai trò. Ghi rõ ai làm gì. Nếu công việc chuyên môn hóa cao, chia theo nhóm role (backend/frontend/QA).
Bước 3 — Mở Team Calendar, rà soát PTO. Đánh dấu mọi ngày lễ chung và nghỉ phép cá nhân trong khung thời gian sprint. Tính tổng số ngày-người bị mất.
Bước 4 — Tính số ngày-người available.
Công thức: Available = (Số người × Ngày làm việc) − Tổng ngày nghỉ.
Bước 5 — Áp dụng focus factor (nếu tính theo giờ).
Capacity giờ = Available (ngày) × 8 giờ × focus factor. Với focus factor mặc định 70% nếu chưa có dữ liệu.
Bước 6 — Quy đổi ra story points (nếu team dùng points).
Capacity points = Velocity trung bình × (Available thực tế ÷ Available đầy đủ).
Ví dụ velocity 45, sprint đầy đủ 60 ngày-người, sprint này chỉ có 46 → 45 × 46/60 ≈ 34,5 points.
Bước 7 — Đối chiếu theo vai trò. Kiểm tra xem có role nào bị quá tải so với công việc trong backlog không. Điều chỉnh scope nếu cần.
Bước 8 — Chốt commit và stretch goal. Đưa capacity đã điều chỉnh làm mục tiêu commit. Nếu muốn, thêm 5–10% làm stretch goal.
Bước 9 — Ghi lại và minh bạch với stakeholder. Ghi rõ trong Sprint Goal hoặc mô tả sprint lý do capacity giảm ("sprint này có 2 ngày lễ + 2 người nghỉ phép nên mục tiêu là 34 điểm thay vì 45"). Minh bạch giúp xây lòng tin.
Lỗi thường gặp & mẹo
Lỗi 1 — Giả định focus factor 100%. Không ai làm việc 8 tiếng thuần cho sprint. Luôn để 20–40% cho họp, support, overhead.
Lỗi 2 — Quên kiểm tra Team Calendar. Đây là lỗi phổ biến nhất và tốn kém nhất. Biến việc mở lịch nghỉ thành bước bắt buộc trong checklist planning.
Lỗi 3 — Chỉ nhìn tổng capacity, bỏ qua vai trò. Dẫn tới cam kết công việc mà một role không thể gánh nổi.
Lỗi 4 — Dùng velocity của một sprint duy nhất. Một sprint có thể là ngoại lệ. Luôn lấy trung bình 3–6 sprint để làm mượt biến động.
Lỗi 5 — Không tính người mới (ramp-up). Thành viên mới trong 1–2 sprint đầu chỉ đóng góp 30–50% capacity vì còn học việc. Đừng tính họ như một unit đầy đủ.
Mẹo 1 — Tạo mẫu capacity sheet dùng lại. Một Google Sheet hoặc Confluence template với công thức sẵn giúp planning nhanh trong 10 phút.
Mẹo 2 — Theo dõi "planned vs actual". Cuối mỗi sprint, so capacity dự tính với velocity thực tế. Qua vài sprint bạn sẽ hiệu chỉnh được focus factor chính xác cho team mình.
Mẹo 3 — Với team dùng Jira Premium, tận dụng Capacity view trong Advanced Roadmaps để hệ thống tự cảnh báo khi kế hoạch vượt năng lực.
Mẹo 4 — Đừng biến capacity thành công cụ ép sản lượng. Mục tiêu là cam kết đúng, không phải cam kết nhiều. Một PM ép capacity lên cao để "trông năng suất" sẽ nhanh chóng đánh mất lòng tin và làm team kiệt sức.
Bài tập thực hành
Bài tập 1 — Tính capacity cơ bản. Team của bạn có 5 người, sprint 2 tuần (10 ngày làm việc). Velocity trung bình 3 sprint gần nhất: 40, 44, 42 points. Trong sprint tới có 1 ngày lễ toàn team, và 1 người nghỉ phép 3 ngày. Hãy tính:
- Velocity trung bình.
- Số ngày-người available.
- Capacity points đề xuất cho sprint.
Bài tập 2 — Capacity theo vai trò. Team có 3 backend, 1 frontend, 1 QA. Backlog sprint tới có 30 điểm backend, 20 điểm frontend, 10 điểm QA. Biết mỗi người làm được ~10 điểm/sprint trong role của mình. Sprint nào cũng full attendance. Hãy chỉ ra role nào là nút cổ chai và đề xuất scope thực tế nên đưa vào sprint.
Bài tập 3 — Thiết lập Team Calendar. Chọn một công cụ (Team Calendars for Confluence, Google Sheet, hoặc Advanced Roadmaps) và phác thảo cách bạn sẽ quản lý PTO cho team 6 người. Liệt kê những thông tin cần theo dõi và quy trình cập nhật khi có người xin nghỉ.
Tóm tắt
Capacity Planning là kỹ năng giúp PM cam kết đúng thay vì cam kết theo con số đẹp. Bốn đầu vào cốt lõi là: team size + role, velocity lịch sử, PTO calendar (lịch nghỉ, ngày lễ), và capacity factor (focus time trừ đi họp, support, overhead). Velocity cho bạn điểm xuất phát; các yếu tố còn lại giúp bạn điều chỉnh xuống mức thực tế cho từng sprint cụ thể.
Quy trình gồm: xác định ngày làm việc, rà soát Team Calendar, tính ngày-người available, áp focus factor hoặc quy đổi theo tỷ lệ velocity, đối chiếu theo vai trò, rồi chốt commit minh bạch với stakeholder. Team Calendar — dù là Team Calendars for Confluence, Capacity view trong Advanced Roadmaps, add-on Marketplace hay đơn giản một Google Sheet — là trái tim của quy trình này.
Hãy nhớ ba nguyên tắc: (1) không bao giờ giả định 100% năng lực, (2) luôn kiểm tra lịch nghỉ trước khi cam kết, và (3) tính capacity theo vai trò khi công việc chuyên môn hóa. Làm tốt điều này, bạn không chỉ giao đúng hẹn — bạn còn bảo vệ team khỏi quá tải và xây dựng được uy tín bằng những con số đáng tin cậy.