Phân hệ PM Study
  • Tình huốngTình huống thực chiến
  • Kịch bảnRa quyết định tình huống
  • Biểu mẫuKho biểu mẫu tải về
  • Thẻ ghi nhớHọc thuật ngữ PMP
  • Công cụMáy tính EVM, PERT, dự phòng
  • Hỏi đápHỏi đáp & thảo luận
  • Thử tháchMỗi ngày một câu hỏi PMP
  • Lý thuyếtBài học PMBOK 8 & ECO 2026
  • Luyện thiThi thử & ôn tập PMP
  • Bài viếtThư viện bài viết PMP
PM Study
Trang chủLý thuyếtTình huốngLuyện thiBiểu mẫuHỏi đáp
6 chuyên mụcXem tất cả bài viết →
  • Quản lý các bên liên quanTình huống về kỳ vọng, giao tiếp và gắn kết stakeholder.
  • Lãnh đạo & đội nhómXây dựng, dẫn dắt và giải quyết xung đột trong đội dự án.
  • Kế hoạch & tiến độLập kế hoạch, ước lượng, nén tiến độ và kiểm soát baseline.
  • Rủi ro & thay đổiNhận diện, ứng phó rủi ro và kiểm soát thay đổi phạm vi.
  • Agile & HybridLựa chọn và vận hành cách tiếp cận Agile, Predictive, Hybrid.
  • Luyện thi PMPChiến lược ôn tập và mẹo xử lý câu hỏi tình huống PMP.
Công cụBài viết
Trang chủLý thuyếtTình huốngLuyện thiBiểu mẫuHỏi đápChuyên mụcCông cụBài viết
/
PM Study

Học quản lý dự án và ôn thi PMP bằng tiếng Việt: lý thuyết PMBOK® Guide 8, tình huống thực tế và đề luyện thi theo ECO 2026.

Chuyên mục

  • Quản lý các bên liên quan
  • Lãnh đạo & đội nhóm
  • Kế hoạch & tiến độ
  • Rủi ro & thay đổi
  • Agile & Hybrid
  • Luyện thi PMP

Tài nguyên

  • Project Management Institute (PMI)
  • PMP Exam Content Outline
  • The Scrum Guide
  • PMI Vietnam Chapter

PM Study

  • Tất cả bài viết
  • Bài viết nổi bật
© 2026 PM StudyPMP® và PMBOK® là nhãn hiệu đã đăng ký của Project Management Institute.Phiên bản 1.12.1
  1. /Kế hoạch & tiến độ
  2. /Burndown "đẹp" mà vẫn trễ hạn: chọn đúng thước đ…
Kế hoạch & tiến độ· Domain: Đo lường

Burndown "đẹp" mà vẫn trễ hạn: chọn đúng thước đo tiến độ

Sprint burndown luôn về 0 nhưng ngày phát hành cứ lùi. Phân biệt burndown, burnup, velocity và tránh các cạm bẫy đo lường theo PMBOK® 7.

HP
Nguyễn Thu Hà, PMP
01/09/2026
5 phút đọc 0 0
Burndown "đẹp" mà vẫn trễ hạn: chọn đúng thước đo tiến độ

Tình huống minh hoạ

Một đội Scrum sáu người (giả định) phát triển ứng dụng quản lý kho với sprint hai tuần. Sprint burndown của mọi sprint đều "đẹp" — đường thực tế về gần 0 vào ngày cuối. Thế nhưng ngày phát hành dự kiến cứ lùi dần, và sponsor bắt đầu nghi đội "báo cáo cho đẹp".

Số liệu minh hoạ sau 4 sprint:

  • Release backlog ban đầu: 200 story points; velocity các sprint lần lượt 22, 25, 28, 25 → trung bình 25 điểm/sprint.
  • Đã hoàn thành: 100 điểm.
  • Trong cùng thời gian, các bên liên quan bổ sung 60 điểm vào release backlog, nâng tổng phạm vi lên 260 điểm.

Ngoài ra, ban quản lý vừa đưa velocity vào chỉ tiêu đánh giá đội, và PM để ý thấy những story tương tự gần đây được ước lượng nhiều điểm hơn trước.

Phân tích theo PMBOK® Guide

Sprint burndown chỉ trả lời câu hỏi trong phạm vi một sprint. Nó không cho thấy phạm vi của cả bản phát hành đang tăng. Agile Practice Guide giới thiệu cả burndown chart và burnup chart; burnup có thể thể hiện riêng đường "tổng phạm vi" và đường "đã hoàn thành", nên thay đổi phạm vi hiện ra ngay trên biểu đồ.

Tính toán với số liệu minh hoạ:

Câu hỏiPhép tínhKết quả
Nếu phạm vi giữ nguyên 200 điểm(200 − 100) / 254 sprint nữa
Phạm vi hiện tại 260 điểm và ngừng tăng(260 − 100) / 25 = 6.47 sprint nữa
Phạm vi tiếp tục tăng 15 điểm/sprint160 / (25 − 15)16 sprint nữa

Dòng cuối cho thấy: nếu xu hướng bổ sung phạm vi giữ nguyên (60 điểm / 4 sprint = 15 điểm/sprint), tiến độ ròng chỉ còn 10 điểm mỗi sprint. Đây là thông tin quan trọng nhất cho sponsor, và sprint burndown không thể hiện được.

Các dự báo trên giả định velocity giữ quanh mức trung bình 25 điểm/sprint, số sprint được làm tròn lên, và mọi story được ước lượng trên cùng một thang điểm. Nếu điểm đang bị "phình" (story tương tự nhưng được chấm nhiều điểm hơn trước), velocity gần đây bị thổi phồng so với thang điểm của backlog ban đầu, nên dự báo sẽ lạc quan hơn thực tế.

PMBOK® Guide – Seventh Edition, Measurement Performance Domain gợi ý:

  • Phân biệt chỉ số dẫn dắt (leading indicators) — như tốc độ tăng phạm vi, lượng việc đang dở (WIP) — với — như số điểm đã hoàn thành.

Tình huống liên quan

Kế hoạch & tiến độLập kế hoạch

Ngày go-live "chắc chắn" chỉ đạt được 8% số lần mô phỏng: phân tích rủi ro tiến độ bằng Monte Carlo

Lịch dự án ERP ghi go-live ở ngày làm việc thứ 120, nhưng ba nhánh công việc cùng hội tụ vào một mốc. Mô phỏng Monte Carlo cho thấy ngày đó chỉ đạt được khoảng 8% số lần lặp. Cách đọc đường cong S, hiểu merge bias và chọn mức dự phòng tiến độ có căn cứ.

Ngày đăng: 04/10/2026Lượt xem: 0Bình luận: 0
Agile & HybridĐo lường

Bảng Kanban kín việc mà khách vẫn chờ lâu: giới hạn WIP và định luật Little

Đội hỗ trợ triển khai có 6 người nhưng đang "ôm" 31 yêu cầu dở dang, khách hàng chờ trung bình hơn ba tuần. Dùng bốn chỉ số dòng chảy của Kanban Guide và định luật Little để chứng minh rằng bắt đầu ít việc hơn mới là cách xong việc nhanh hơn.

Ngày đăng: 02/10/2026Lượt xem: 2Bình luận: 0
Kế hoạch & tiến độLập kế hoạch

Đội kiểm thử quá tải 160% trong ba tuần: chọn resource leveling hay resource smoothing?

Lịch trình trông hợp lý cho tới khi xếp người vào: đội kiểm thử phải gánh 160% công suất trong ba tuần. Phân biệt resource leveling và resource smoothing, khi nào chấp nhận lùi mốc và khi nào chỉ dùng float.

Ngày đăng: 01/10/2026Lượt xem: 4Bình luận: 0
Kế hoạch & tiến độLập kế hoạch

40 ngày công không phải 8 ngày với 5 người: chuyển ước lượng công sang thời lượng cho đúng

Ước lượng 40 ngày công, chia cho 5 người, kế hoạch ghi 8 ngày. Thực tế mất 19 ngày. Phân biệt công (effort), thời lượng (duration) và thời gian trôi qua, tính hệ số khả dụng, và hiểu vì sao thêm người không rút ngắn tuyến tính.

Ngày đăng: 29/09/2026Lượt xem: 0Bình luận: 0
chỉ số trễ (lagging indicators)
  • Xây dựng chỉ số theo tiêu chí SMART.
  • Cảnh giác với các cạm bẫy đo lường (measurement pitfalls): Hawthorne effect (việc đo lường làm thay đổi hành vi), vanity metric (chỉ số đẹp nhưng không giúp ra quyết định), làm mất động lực (demoralization), dùng sai chỉ số (misusing the metrics), confirmation bias và nhầm lẫn tương quan với nhân quả.
  • Đưa velocity vào chỉ tiêu đánh giá là ví dụ điển hình của Hawthorne effect và dùng sai chỉ số: velocity là thước đo để đội tự lập kế hoạch, dựa trên ước lượng tương đối của riêng đội đó, nên không phù hợp để làm KPI hay so sánh giữa các đội. Khi điểm "phình" ra, velocity tăng mà giá trị bàn giao không tăng.

    Cách xử lý đề xuất

    1. Bổ sung release burnup chart với hai đường: tổng phạm vi và phần đã hoàn thành. Đặt nó ở nơi mọi người cùng thấy như một information radiator.
    2. Dự báo bằng khoảng, không bằng một điểm. Với 160 điểm còn lại và velocity dao động 22–28: 160 / 28 ≈ 5.7 → 6 sprint; 160 / 22 ≈ 7.3 → 8 sprint. Báo cáo "6–8 sprint nếu phạm vi không tăng thêm".
    3. Đưa xu hướng tăng phạm vi lên bàn quyết định. Cùng Product Owner và sponsor chọn: giữ ngày phát hành và cắt bớt phạm vi theo thứ tự ưu tiên, hay giữ phạm vi và chấp nhận ngày muộn hơn.
    4. Tách velocity khỏi đánh giá hiệu suất. Đề xuất với ban quản lý các chỉ số hướng tới giá trị và dòng chảy công việc: giá trị kinh doanh đã bàn giao, lead time, cycle time, mức độ hài lòng của bên liên quan.
    5. Kiểm tra Definition of Done. Velocity chỉ có ý nghĩa khi điểm được tính cho công việc thật sự xong. Story chưa đạt DoD thì không được tính điểm.
    6. Đặt ngưỡng hành động (threshold). Ví dụ: nếu phạm vi tăng hơn 10% trong một sprint, PM và Product Owner phải xem xét lại kế hoạch phát hành.

    Góc nhìn đề thi PMP

    • Khi cần thể hiện cả thay đổi phạm vi lẫn phần đã hoàn thành, hãy nghĩ tới burnup chart.
    • Phương án dùng velocity để so sánh hoặc xếp hạng các đội thường là phương án sai.
    • Khi bên liên quan nghi ngờ số liệu, hướng đúng thường là minh bạch hoá dữ liệu (information radiator, sprint review) và cùng phân tích nguyên nhân, không phải "làm báo cáo dày hơn" hay giấu bớt thông tin.
    • Trong ECO 2021 (phiên bản trước), việc đo tiến độ theo phương pháp phù hợp nằm trong nhiệm vụ Plan and manage schedule thuộc domain Process. Đề thi PMP áp dụng ECO mới từ khoảng tháng 7/2026 — hãy kiểm tra ECO mới nhất trên pmi.org.

    Bài học rút ra

    • Một biểu đồ đẹp chưa chắc là một dự án khoẻ: hãy hỏi biểu đồ đó trả lời câu hỏi gì.
    • Phạm vi tăng là chuyện bình thường trong Agile, nhưng phải nhìn thấy được và được quyết định có chủ đích.
    • Đo lường để hỗ trợ quyết định; khi chỉ số trở thành chỉ tiêu, hành vi sẽ chạy theo chỉ số thay vì theo giá trị.

    Tài liệu tham khảo

    • PMI. PMBOK® Guide – Seventh Edition, 2021 — Measurement Performance Domain.
    • PMI & Agile Alliance. Agile Practice Guide, 2017.
    • PMI. Project Management Professional (PMP)® Examination Content Outline — dùng bản mới nhất trên pmi.org; tên nhiệm vụ nêu trong bài theo bản 2021.
    #burnup#burndown#velocity#do-luong

    Biểu mẫu tải về

    • Bộ mẫu biểu đồ burndown (Smartsheet)5 mẫu có dữ liệu ví dụ: burndown đơn giản, burndown phát hành (release), burndown dự án, burndown sprint Agile và burndown rủi ro. Dùng để so sánh đường lý tưởng với thực tế và phát hiện sớm nguy cơ trễ hạn. Excel, Google Sheets.smartsheet.com · 0 lượt mở
      Mở liên kết
    • Mẫu biểu đồ burndown cho sprint (Miro)Bảng trắng gồm tổng story point, trục thời gian sprint, đường lý tưởng, đường thực tế và vùng ghi nhận việc còn lại mỗi ngày. Dùng trong daily scrum để cả đội cùng nhìn tiến độ thật. Trực tuyến (Miro).miro.com · 0 lượt mở
      Mở liên kết
    • Hướng dẫn biểu đồ burndown trong Agile (Atlassian)Hướng dẫn đọc và tạo biểu đồ burndown của sprint và epic, cách hiểu đường lý tưởng và những tín hiệu cảnh báo. Dùng để nhận ra khi burndown "đẹp" chỉ vì phạm vi bị cắt bớt hoặc ước lượng bị thổi phồng. Trực tuyến.atlassian.com · 0 lượt mở
      Mở liên kết
    • Mẫu biểu đồ burndown trên Excel (ProjectManager)Bảng tính nhập công việc còn lại theo ngày và tự vẽ đường thực tế so với đường lý tưởng của sprint. Dùng khi đội chưa có công cụ Agile, hoặc để đối chiếu với số liệu xuất từ công cụ. Excel.projectmanager.com · 0 lượt mở
      Mở liên kết
    • Bốn chỉ số Kanban nên dùng: lead time, cycle time, WIP, throughput (Atlassian)Bài hướng dẫn các chỉ số dòng chảy và biểu đồ dòng tích luỹ (cumulative flow diagram) để thấy điểm nghẽn. Dùng để bổ sung thước đo dòng chảy cho burndown, phát hiện việc dồn ứ ở khâu kiểm thử hay chờ duyệt. Trực tuyến.atlassian.com · 0 lượt mở
      Mở liên kết
    • Năm chỉ số Agile hữu ích cho đội (Atlassian)Tổng hợp burndown của sprint và epic, velocity, biểu đồ kiểm soát (control chart) và biểu đồ dòng tích luỹ, kèm cách dùng đúng. Dùng để chọn bộ thước đo tiến độ phù hợp thay vì chỉ nhìn một biểu đồ. Trực tuyến.atlassian.com · 0 lượt mở
      Mở liên kết

    Trắc nghiệm tình huống PMP

    Câu 1/5
    Sprint burndown của đội luôn về gần 0 cuối mỗi sprint nhưng ngày phát hành cứ lùi vì các bên liên quan liên tục bổ sung story vào release backlog. PM muốn sponsor nhìn thấy ngay cả thay đổi phạm vi lẫn phần đã hoàn thành. Công cụ nào phù hợp nhất?

    Bạn chọn phương án nào?

    Sprint burndown luôn về 0 nhưng ngày phát hành cứ lùi vì phạm vi đã tăng thêm 60 điểm; ban quản lý vừa đưa velocity vào chỉ tiêu đánh giá đội. Nếu là PM, bạn ưu tiên việc gì?

    Bài viết hữu ích? Chia sẻ cho đồng nghiệp nhé!

    Đánh giá bài viết

    Bình luận

    Mục lục

    Tình huống minh hoạPhân tích theo PMBOK® GuideCách xử lý đề xuấtGóc nhìn đề thi PMPBài học rút raTài liệu tham khảoBiểu mẫu tải vềTrắc nghiệmBình chọn
    Quảng cáoTemplate quản lý dự án (mẫu)
    Quảng cáoBộ đề thi thử PMP (mẫu)