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. /Khách hàng nhà nước đòi WBS, đội Scrum chỉ có ba…
Kế hoạch & tiến độ· Domain: Lập kế hoạch

Khách hàng nhà nước đòi WBS, đội Scrum chỉ có backlog: nối WBS với epic, feature và lộ trình sản phẩm

Hợp đồng yêu cầu WBS, ước tính chi phí theo WBS và báo cáo giá trị thu được, trong khi đội làm Scrum với backlog thay đổi mỗi sprint. GAO Agile Assessment Guide gợi ý một lời giải: WBS hướng sản phẩm ở cấp epic và feature, user story chỉ vào WBS sau khi lập kế hoạch phát hành.

HP
Nguyễn Thu Hà, PMP
01/12/2025
5 phút đọc 0 0
Khách hàng nhà nước đòi WBS, đội Scrum chỉ có backlog: nối WBS với epic, feature và lộ trình sản phẩm

Tình huống minh hoạ

Tình huống và số liệu dưới đây là giả định, dùng để minh hoạ.

Một công ty phần mềm trúng thầu xây cổng dịch vụ công trực tuyến cho một sở, thời gian 15 tháng. Hồ sơ mời thầu yêu cầu nhà thầu nộp WBS, ước tính chi phí theo WBS và báo cáo tiến độ hằng tháng. Đội phát triển làm Scrum, sprint 2 tuần.

Hai phe tranh luận trong buổi khởi động:

  • Trưởng nhóm kỹ thuật: "Backlog của chúng tôi thay đổi liên tục. Lập WBS 300 dòng đến từng chức năng là phí công, ba tháng sau đã sai."
  • Chuyên viên kế hoạch: "Không có WBS thì không có ước tính chi phí, không báo cáo được giá trị thu được, và khi khách hàng thêm yêu cầu ta không biết đó là thay đổi phạm vi hay không."

PM thử một phương án "lai": lấy danh sách sprint làm WBS (Sprint 1, Sprint 2… Sprint 30). Sau hai tháng, cách này lộ ra vấn đề — WBS theo sprint chỉ cho biết khi nào, không cho biết làm ra cái gì; báo cáo "Sprint 4 hoàn thành 100%" không nói được dịch vụ nào đã dùng được.

Phân tích theo PMBOK® Guide

WBS và backlog không loại trừ nhau

Hướng dẫn thực hành agile (Agile Practice Guide) và PMBOK® Guide ấn bản 7 nhìn phạm vi trong môi trường thích ứng như một thứ tiến triển dần: phạm vi tổng thể được mô tả ở mức cao (tầm nhìn, lộ trình), còn chi tiết được làm rõ gần thời điểm thực hiện. Scrum Guide 2020 mô tả Product Backlog là danh sách có thứ tự, luôn tiến hoá (emergent), và việc tinh chỉnh (refinement) là chia nhỏ, làm rõ các hạng mục.

Điều này không mâu thuẫn với WBS — vì WBS cũng là phân rã sản phẩm theo thứ bậc, và cũng được chi tiết hoá dần (rolling wave). Mâu thuẫn chỉ xuất hiện khi ta đòi WBS chi tiết đến user story ngay từ đầu.

Gợi ý của GAO Agile Assessment Guide

GAO Agile Assessment Guide (GAO-24-105506) dành chương 7 cho giám sát và kiểm soát chương trình agile, mở đầu bằng WBS. Một số ý chính (diễn đạt lại):

  • WBS là khung đầu vào cho ba công cụ kiểm soát chính: ước tính chi phí, lập lịch và EVM. Trong môi trường agile, WBS vẫn theo thứ bậc, hướng sản phẩm, chứa toàn bộ phạm vi chương trình.
  • Agile cũng có thứ bậc riêng: epic (năng lực lớn, cần nhiều vòng lặp) → feature (khối chức năng làm được trong một hai kỳ báo cáo) → user story (đơn vị nhỏ nhất, dễ thay đổi theo phản hồi).
  • Cấp feature là cấp nên được theo dõi qua các sản phẩm quản lý chương trình như ước tính chi phí vòng đời và lịch; feature trong WBS phải truy vết được về lộ trình (road map).

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
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
Kế hoạch & tiến độLập kế hoạch

Ước lượng ba điểm và PERT: khi đội chỉ đưa ra một con số lạc quan

Đội cam kết "28 ngày là xong" nhưng đó chỉ là kịch bản thuận lợi. Cách dùng ước lượng ba điểm, công thức PERT và độ lệch chuẩn để đưa ra mốc tiến độ có mức tin cậy.

Ngày đăng: 28/09/2026Lượt xem: 5Bình luận: 0
  • User story có thể thêm hoặc bỏ mà không làm thay đổi phạm vi tổng thể của feature; story chỉ nên vào WBS sau khi lập kế hoạch phát hành/vòng lặp và phải truy vết được về backlog đã ưu tiên.
  • Vì cấp story và task không ổn định, phần lớn thực hành giám sát truyền thống nên đặt ở cấp epic hoặc feature. WBS được cập nhật sau mỗi đợt phát hành khi thông tin rõ hơn.
  • WBS còn cho thấy quan hệ giữa phần phát triển agile và các phần khác của chương trình — quản lý chương trình, phần cứng, bản quyền phần mềm.
  • Vì sao WBS theo sprint là sai hướng

    GAO-20-195G liệt kê những thứ không nên làm phần tử WBS, trong đó có lịch của chương trình — WBS dẫn dắt lịch chứ không phải ngược lại. Sprint là đơn vị thời gian; dùng nó làm WBS cũng giống WBS theo giai đoạn: không có tiêu chí chấp nhận sản phẩm, không trả lời được "dịch vụ nào đã dùng được".

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

    Bước 1: Dựng WBS hai tầng ổn định

    CấpNội dungVí dụ
    1Toàn dự ánCổng dịch vụ công
    2Năng lực lớn (epic) + phần tử chungNộp hồ sơ trực tuyến; Thanh toán; Tra cứu; Tích hợp hệ thống một cửa; Hạ tầng; Quản lý dự án
    3Feature (khi đã đủ thông tin)Nộp hồ sơ: biểu mẫu động, ký số, đính kèm tài liệu
    4User storyChỉ thêm sau khi lập kế hoạch phát hành

    Tầng 1–2 được phê duyệt trong đường cơ sở; tầng 3 chi tiết hoá cho 1–2 đợt phát hành gần; tầng 4 nằm trong công cụ quản lý backlog, liên kết mã WBS.

    Bước 2: Gắn mã WBS vào backlog

    Mỗi epic/feature trong công cụ backlog có trường mã WBS. Khi Product Owner sắp xếp lại thứ tự, WBS không đổi; khi thêm một epic mới, đó là tín hiệu thay đổi phạm vi cần đánh giá theo hợp đồng.

    Bước 3: Định nghĩa "hoàn thành" ở cấp feature

    GAO nhấn mạnh chương trình cần có tiêu chí chấp nhận hoàn thành rõ ràng để đo hiệu suất khách quan. Ở đây: feature chỉ được tính là xong khi đạt Definition of Done và được đại diện sở nghiệm thu trên môi trường kiểm thử.

    Bước 4: Báo cáo theo feature, không theo sprint

    Báo cáo tháng cho khách hàng: số feature đã nghiệm thu so với kế hoạch phát hành, chi phí luỹ kế theo epic. Báo cáo sprint (burndown) vẫn dùng nội bộ cho đội.

    Sai lầm thường gặp

    • Đòi WBS đến user story từ ngày đầu: tốn công, sai nhanh, đội coi WBS là gánh nặng.
    • Dùng sprint hoặc đợt phát hành làm cấp 2: mất góc nhìn sản phẩm.
    • Bỏ phần tử chung: hạ tầng, bảo mật, quản lý dự án, chuyển đổi dữ liệu không phải story nên dễ "rơi" khỏi backlog lẫn WBS.
    • Coi mọi thay đổi trong backlog là thay đổi phạm vi: sắp xếp lại story trong một feature thường không phải thay đổi hợp đồng.

    Góc ôn thi PMP

    • Trong môi trường thích ứng, phạm vi được làm rõ dần; backlog và WBS có thể cùng tồn tại trong mô hình hybrid.
    • Epic → feature → story là phân rã theo thứ bậc, tương tự tinh thần decomposition của Create WBS.
    • Câu hỏi kiểu "khách hàng yêu cầu báo cáo truyền thống cho dự án agile" → tìm cách ánh xạ artefact agile sang công cụ kiểm soát của khách hàng, không bỏ agile cũng không từ chối khách hàng.

    Nguồn tham khảo

    • GAO Agile Assessment Guide: Best Practices for Adoption and Implementation (GAO-24-105506)
    • GAO Cost Estimating and Assessment Guide (GAO-20-195G)
    • The 2020 Scrum Guide
    #wbs#agile#epic#feature#product-backlog

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

    Câu 1/1
    Dự án phần mềm theo hợp đồng nhà nước dùng Scrum. Khách hàng yêu cầu WBS và báo cáo chi phí, tiến độ theo WBS hằng tháng. Backlog thay đổi thường xuyên ở cấp user story. PM nên cấu trúc WBS như thế nào?

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

    Product Owner muốn thêm một epic mới "Ứng dụng di động" mà không bỏ epic nào. Hợp đồng có WBS cấp 2 đã phê duyệt và giá cố định. Nếu là PM, bạn chọn cách nào?

    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ấtSai lầm thường gặpGóc ôn thi PMPNguồn tham khảoTrắ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)