Mở đầu — vì sao bài này quan trọng
Là một BA (Business Analyst), bạn sẽ thường xuyên đứng giữa hai thế giới: một bên là Product Owner, stakeholder, ban lãnh đạo muốn biết "dự án có đúng tiến độ không, sprint này có kịp không, team đang vướng ở đâu"; một bên là dữ liệu thật nằm rải rác trong hàng trăm issue của JIRA. Câu hỏi của họ rất đơn giản, nhưng để trả lời chính xác, bạn cần biết cách "rút ruột" dữ liệu đó thành những con số và biểu đồ đáng tin.
Tin tốt là JIRA đã có sẵn một bộ báo cáo dựng sẵn (built-in reports) khá mạnh — bạn không cần plugin trả phí, không cần biết lập trình, không cần dựng dashboard phức tạp. Chỉ cần biết báo cáo nào trả lời được câu hỏi nào, và quan trọng hơn: biết đọc biểu đồ đó để rút ra kết luận đúng.
Bài này tập trung vào các built-in reports — đặc biệt là ba báo cáo Scrum kinh điển (Burndown, Burnup, Velocity) cùng nhóm báo cáo Agile và báo cáo chung khác mà JIRA cung cấp ngay trong mục Reports. Đây là kỹ năng "nền" mà mọi BA làm việc với team Agile đều cần. Khi bạn đọc thành thạo một burndown chart trong 10 giây, bạn sẽ trở thành người mà cả team tin tưởng mỗi khi cần một câu trả lời nhanh về tình hình dự án.
Khái niệm cốt lõi
Trước hết cần phân biệt rõ: built-in reports khác với dashboard và gadget (sẽ học ở bài khác). Reports là những biểu đồ phân tích dựng sẵn, truy cập qua menu Reports của một project. Bạn chọn báo cáo, chọn board/sprint, JIRA tự vẽ. Chúng được thiết kế để trả lời những câu hỏi quản trị dự án cụ thể.
JIRA chia reports thành vài nhóm chính: Agile reports (gắn với board Scrum hoặc Kanban), và General/Issue analysis reports (phân tích issue theo nhiều chiều). Là BA, bạn cần nắm chắc nhóm Scrum trước vì đó là thứ stakeholder hỏi nhiều nhất.
Burndown Chart — công việc còn lại theo thời gian
Burndown chart trả lời câu hỏi: "Với tốc độ hiện tại, sprint này có hoàn thành đúng hạn không?". Trục hoành là thời gian (các ngày trong sprint), trục tung là khối lượng công việc còn lại (đo bằng story points hoặc số issue, tùy cấu hình estimation của board).
Biểu đồ có hai đường: đường lý tưởng (guideline) — một đường thẳng đi từ tổng công việc đầu sprint xuống 0 vào ngày cuối, thể hiện nhịp độ "đẹp như mơ"; và đường thực tế (remaining values) — đường gấp khúc theo dữ liệu thật mỗi ngày. Khi đường thực tế nằm trên đường lý tưởng, team đang chậm hơn kế hoạch. Khi nằm dưới, team đang vượt tiến độ. Đường thực tế đi ngang (không dốc xuống) là dấu hiệu cảnh báo: công việc không được hoàn thành.
Burnup Chart — công việc hoàn thành so với phạm vi
Burnup chart cũng vẽ theo thời gian, nhưng tách thành hai đường riêng: đường scope (tổng phạm vi công việc) và đường completed (công việc đã hoàn thành). Điểm mạnh của burnup so với burndown là nó tách bạch được hiện tượng scope creep — tức là khi phạm vi sprint phình to ra giữa chừng (ai đó thêm story vào sprint đang chạy).
Trong burndown, nếu team làm xong nhiều việc nhưng cũng bị thêm việc vào, đường còn lại có thể trông "đứng yên" và bạn không biết tại sao. Burnup làm rõ điều này: nếu đường scope nhảy vọt lên giữa sprint, bạn biết ngay phạm vi đã bị thêm vào — và đó là lý do team có vẻ "không tiến". Đây là công cụ tuyệt vời để BA chỉ ra nguyên nhân thật cho stakeholder.
Velocity Chart — vận tốc của team qua các sprint
Velocity chart không nhìn vào một sprint, mà nhìn vào nhiều sprint liên tiếp. Mỗi sprint hiển thị hai cột: Commitment (số story points cam kết đầu sprint) và Completed (số points thực sự hoàn thành). So sánh hai cột này qua nhiều sprint, bạn biết được "năng lực thật" của team là bao nhiêu points mỗi sprint.
Velocity là nền tảng để lập kế hoạch (capacity planning): nếu trung bình 3 sprint gần nhất team hoàn thành 40 points/sprint, thì khi planning sprint tới, đưa vào 38–42 points là hợp lý; nhồi 60 points là phi thực tế. Velocity ổn định (các cột completed gần bằng nhau) là dấu hiệu team trưởng thành. Velocity dao động mạnh cho thấy ước lượng chưa chính xác hoặc môi trường làm việc nhiều biến động.
Các báo cáo built-in khác cần biết
- Sprint Report: bảng tổng kết một sprint — issue nào hoàn thành, issue nào bị "đẩy" (removed) ra khỏi sprint, issue nào thêm vào sau khi sprint đã bắt đầu. Rất hữu ích cho retrospective.
- Cumulative Flow Diagram (CFD): biểu đồ vùng màu thể hiện số issue ở mỗi trạng thái (To Do, In Progress, Done) theo thời gian. Vùng "In Progress" phình to dần = bottleneck (work in progress quá tải).
- Control Chart: đo cycle time / lead time — thời gian trung bình một issue đi từ lúc bắt đầu đến lúc xong. Dùng cho team Kanban là chủ yếu.
- Created vs Resolved Issues Report: so sánh số issue được tạo và số được giải quyết theo thời gian — cảnh báo "nợ" công việc dồn ứ.
- Average Age Report, Pie Chart Report, Recently Created Issues Report: nhóm báo cáo phân tích issue tổng quát, không gắn với sprint.
Tình huống thực tế
Tình huống 1: Công ty fintech ở TP.HCM và burndown "đứng hình"
Một công ty fintech tại Quận 1, TP.HCM (tạm gọi là MoMoPay) có team phát triển tính năng ví điện tử chạy sprint 2 tuần. Đến giữa sprint, PO lo lắng vì cảm giác "team làm hoài không xong". Là BA, bạn mở Burndown Chart và thấy: từ ngày 4 đến ngày 7, đường thực tế gần như nằm ngang ở mức 35 points trong khi đường lý tưởng đã xuống 20 points.
Nhìn thoáng qua, có vẻ team lười. Nhưng bạn mở thêm Burnup Chart và phát hiện: đường scope đã nhảy từ 50 points lên 68 points vào ngày 5 — tức là có người thêm 18 points công việc vào sprint đang chạy. Hóa ra team vẫn hoàn thành đều đặn 4–5 points/ngày, vấn đề là phạm vi bị phình. Bài học rút ra: đừng kết luận chỉ từ một biểu đồ. Burndown cho thấy "có vấn đề", burnup cho thấy "vấn đề là scope creep, không phải năng suất". BA dùng dữ liệu này để đề xuất khóa scope sprint sau khi đã bắt đầu.
Tình huống 2: Outsourcing ở Đà Nẵng và bài toán cam kết với khách hàng
Một công ty outsourcing ở Đà Nẵng nhận dự án cho khách hàng Nhật Bản. Khách hàng liên tục hỏi "bao giờ xong 120 story points còn lại?". Trước đây team toàn trả lời cảm tính nên hay sai hẹn. BA mở Velocity Chart của 5 sprint gần nhất: lần lượt hoàn thành 22, 25, 24, 23, 26 points — trung bình khoảng 24 points/sprint, khá ổn định.
Từ con số này, BA tính: 120 points ÷ 24 points/sprint = 5 sprint, tức khoảng 10 tuần. Thay vì hứa "chắc khoảng 2 tháng", BA trình bày với khách hàng dựa trên velocity thật, kèm biểu đồ minh họa độ ổn định. Khách hàng Nhật vốn coi trọng dữ liệu đã rất hài lòng vì cam kết có cơ sở. Bài học rút ra: Velocity Chart biến lời hứa cảm tính thành dự báo có căn cứ. Một velocity ổn định còn là "bằng chứng" cho thấy team đáng tin — điều cực kỳ giá trị khi làm việc với khách hàng nước ngoài.
Tình huống 3: Sàn thương mại điện tử và bottleneck ẩn
Một sàn thương mại điện tử ở Hà Nội (tạm gọi ShopFast) có team 12 người nhưng tốc độ giao hàng tính năng chậm dần. Velocity vẫn ổn (khoảng 30 points/sprint) nên ban đầu không ai nghi ngờ. BA mở Cumulative Flow Diagram và phát hiện vùng màu "In Review" (chờ review code/QA) phình to dần qua từng tuần — số issue kẹt ở bước review tăng từ 3 lên 11.
Hóa ra chỉ có một QA lead duyệt tất cả, tạo nút thắt cổ chai. Velocity không bộc lộ điều này vì nó chỉ đo đầu ra cuối cùng. BA đề xuất bổ sung người review và đặt giới hạn WIP cho cột Review. Hai sprint sau, vùng "In Review" thu hẹp lại, cycle time giảm 30%. Bài học rút ra: mỗi báo cáo soi một góc khác nhau. CFD giúp BA thấy "công việc kẹt ở đâu trong quy trình" — thứ mà velocity và burndown không bao giờ chỉ ra.
Hướng dẫn từng bước
Dưới đây là quy trình thực tế để truy cập và đọc built-in reports trong JIRA (giao diện Cloud/Software project):
- Mở project và vào mục Reports. Ở thanh menu bên trái của project, tìm mục Reports. JIRA sẽ hiển thị toàn bộ báo cáo khả dụng, chia theo nhóm Agile và nhóm khác.
- Chọn báo cáo phù hợp với câu hỏi. Nếu stakeholder hỏi "sprint này kịp không?" → Burndown. "Phạm vi có bị phình không?" → Burnup. "Team làm được bao nhiêu mỗi sprint?" → Velocity. "Công việc kẹt ở đâu?" → CFD. Xác định câu hỏi trước, chọn báo cáo sau.
- Chọn board và sprint. Với báo cáo Scrum, bạn phải chọn đúng board và đúng sprint (Burndown, Burnup, Sprint Report) hoặc để JIRA hiển thị nhiều sprint (Velocity). Lưu ý: báo cáo chỉ chính xác nếu issue đã được estimate đúng đơn vị mà board cấu hình (story points hoặc original time estimate).
- Đọc biểu đồ theo trật tự: tổng thể → xu hướng → bất thường. Nhìn hình dạng chung trước (đường đi lên hay xuống), rồi xu hướng (đang cải thiện hay xấu đi), cuối cùng soi điểm bất thường (đường ngang, cú nhảy scope, cột completed thấp hơn nhiều so với commitment).
- Đối chiếu chéo nhiều báo cáo. Như các tình huống trên, một báo cáo hiếm khi đủ. Kết hợp Burndown + Burnup để hiểu scope, Velocity + Sprint Report để hiểu cam kết, CFD để tìm bottleneck.
- Xuất/chụp và diễn giải bằng lời. Stakeholder không tự đọc biểu đồ. Nhiệm vụ của BA là chụp lại, viết 2–3 câu kết luận: "Sprint đang chậm 15% do thêm 18 points giữa chừng; đề xuất khóa scope từ sprint sau." Con số + kết luận + hành động — đó mới là báo cáo có giá trị.
- Thiết lập nhịp xem báo cáo. Xem Burndown hằng ngày (trong daily), Velocity và Sprint Report cuối mỗi sprint (trong review/retro). Báo cáo chỉ hữu ích khi được xem đúng thời điểm.
Lỗi thường gặp & mẹo
Lỗi 1: Issue không được estimate. Nếu issue thiếu story points, nó không xuất hiện trên burndown/velocity, khiến biểu đồ "thiếu" công việc và gây hiểu nhầm. Mẹo: trước khi đọc báo cáo, kiểm tra mọi issue trong sprint đã có estimate.
Lỗi 2: Nhầm "Done" với "hoàn thành thật". Burndown chỉ tính issue đạt trạng thái Done (đúng theo cấu hình resolution của board). Nếu workflow của team có cột "Done" nhưng JIRA chưa map đúng là trạng thái cuối, biểu đồ sẽ không trừ điểm. Mẹo: đảm bảo cột cuối board được map đúng với status có resolution.
Lỗi 3: So sánh velocity giữa các team khác nhau. Story points là tương đối với từng team. Team A làm 40 points không có nghĩa "giỏi gấp đôi" team B làm 20 points. Mẹo: chỉ dùng velocity để so sánh chính team đó qua thời gian, không bao giờ xếp hạng giữa các team.
Lỗi 4: Kết luận từ một sprint duy nhất. Velocity của một sprint đơn lẻ rất nhiễu (do nghỉ lễ, người ốm, sự cố). Mẹo: luôn lấy trung bình 3–5 sprint gần nhất để có con số đáng tin.
Lỗi 5: Quên scope creep khi đọc burndown. Đây là lỗi kinh điển. Mẹo: hễ thấy burndown "đứng hình", phản xạ đầu tiên là mở burnup để kiểm tra scope có bị thêm không.
Mẹo vàng: Hãy biến mỗi báo cáo thành một "câu chuyện" gồm ba phần — chuyện gì đang xảy ra, vì sao, và nên làm gì. Stakeholder không nhớ biểu đồ, họ nhớ câu chuyện và đề xuất của bạn.
Bài tập thực hành
- Đọc Burndown: Vào project mẫu (hoặc project thật bạn có quyền), mở Burndown Chart của sprint gần nhất. Xác định: đường thực tế nằm trên hay dưới đường lý tưởng? Có đoạn nào đường đi ngang không? Viết 2 câu kết luận về tình hình sprint.
- Phát hiện scope creep: Mở Burnup Chart của cùng sprint đó. Đường scope có thay đổi giữa sprint không? Nếu có, vào Sprint Report để tìm xem issue nào được thêm vào sau khi sprint bắt đầu. Ghi lại tên các issue đó.
- Tính dự báo từ Velocity: Mở Velocity Chart, lấy trung bình completed của 3 sprint gần nhất. Giả sử backlog còn 90 points, tính xem cần bao nhiêu sprint để hoàn thành. Trình bày như thể đang báo cáo cho stakeholder.
- Tìm bottleneck: Mở Cumulative Flow Diagram của project. Vùng trạng thái nào đang phình to nhất? Đề xuất một hành động để giảm nút thắt đó.
- Viết báo cáo tổng hợp: Kết hợp cả ba báo cáo trên thành một đoạn báo cáo ngắn (khoảng 150 từ) gửi cho PO, theo cấu trúc: tình hình hiện tại — nguyên nhân — đề xuất hành động.
Tóm tắt
Built-in reports của JIRA là bộ công cụ miễn phí, mạnh mẽ giúp BA biến dữ liệu issue thành câu trả lời có căn cứ cho stakeholder. Ba báo cáo Scrum nền tảng cần nắm vững: Burndown (công việc còn lại theo thời gian — sprint có kịp không), Burnup (công việc hoàn thành so với phạm vi — phát hiện scope creep), và Velocity (vận tốc qua nhiều sprint — dự báo và lập kế hoạch). Bổ sung thêm Sprint Report, Cumulative Flow Diagram và Control Chart cho các góc nhìn về bottleneck và cycle time.
Nguyên tắc cốt lõi: không bao giờ kết luận từ một biểu đồ đơn lẻ — hãy đối chiếu chéo. Burndown nói "có vấn đề", burnup nói "vì scope", CFD nói "kẹt ở đâu". Và quan trọng nhất, vai trò của BA không dừng ở việc mở biểu đồ, mà là diễn giải nó thành câu chuyện: chuyện gì — vì sao — nên làm gì. Khi làm được điều đó một cách nhanh và chính xác, bạn trở thành nguồn thông tin đáng tin cậy nhất của cả team về tình hình dự án.