Skip to main content

Scrum Process — From Product Backlog to Sprint Review & Retrospective (PMI-ACP)

Minh hoạ quy trình Scrum: Product Backlog, Sprint Planning, Sprint Backlog, Sprint, Daily Scrum, Sprint Review, Sprint Retrospective, Increment
Scrum Process — Từng vòng Sprint, từng increment giá trị.

Ngôn ngữ • Language

Scrum Process (Quy trình Scrum)​

TL;DR
  • Scrum xây dựng sản phẩm bằng increment nhỏ, theo từng Sprint (1–4 tuần), ưu tiên theo giá trị dựa trên Product Backlog.
  • Luồng chính:
    1. Product Owner xây và sắp xếp Product Backlog (danh sách yêu cầu, sắp xếp theo giá trị).
    2. Sprint Planning → chọn việc từ đỉnh Product Backlog thành Sprint Backlog + đặt Sprint Goal.
    3. Sprint: đội làm việc tập trung, mỗi ngày có Daily Scrum (daily stand-up).
    4. Cuối Sprint: Sprint Review (khách hàng xem & feedback) + Sprint Retrospective (đội tự soi để cải tiến).
    5. Có Increment “potentially releasable” → có thể gộp nhiều Sprint thành một Release.
  • PMI-ACP lens: Value-Driven Delivery, Incremental Delivery, Adaptive Planning, Servant Leadership, Team Empowerment, Inspection & Adaptation, Definition of Done (DoD).
Lối tắt:ECO 2025 · 4 domain
Lưu ý cho người mới

Đừng cố gắng thuộc hết thuật ngữ ngay vòng đầu.
Hãy đi theo câu chuyện “hệ thống kế toán” dưới đây. Đọc hết 1 lượt để nắm flow, sau đó quay lại ôn từng khái niệm.

Câu chuyện: xây hệ thống kế toán bằng Scrum​

Giả sử bạn và đội đang được thuê xây một hệ thống kế toán cho một doanh nghiệp.

Họ muốn có rất nhiều thứ:

  • Accounts Receivable – tạo hoá đơn, gửi cho khách, nhận tiền.
  • Accounts Payable – nhập hóa đơn đầu vào, thanh toán.
  • Payroll – tính lương, khấu trừ, chi trả.
  • Bank Reconciliation – đối soát sao kê ngân hàng.
  • Reports – báo cáo doanh thu, chi phí, lãi lỗ, v.v.
  • Sau đó là Inventory, Inventory Reports… danh sách cứ dài thêm.
Product Backlog (ordered by value)
1. Accounts Receivable
2. Accounts Payable
3. Payroll
4. Bank Reconciliation
5. Reports
6. Inventory Management
7. Inventory Reports
...

Thay vì xây cả hệ thống một lần rồi mới giao, Scrum sẽ:

Chia nhỏ thành increment và luôn giao phần có giá trị cao nhất trước.

Để làm được điều đó, ta cần hiểu những vai trò và những “chiếc hộp” chính trong quy trình.

Các vai trò chính trong quy trình​

  • Product Owner (PO)

    • Đại diện cho khách hàng / business / sponsor.
    • Chịu trách nhiệm tối đa hoá giá trị và sở hữu Product Backlog.
    • Là người duy nhất có quyền ưu tiên lại Product Backlog.

  • Scrum Master

    • Trong Scrum, Scrum Master là người dẫn dắt việc hiểu & áp dụng Scrum đúng, bảo vệ tinh thần empiricism và timeboxing.
    • Là Servant Leader: gỡ bỏ impediments, hỗ trợ cả PO lẫn đội, coach đội tự quản.

  • Agile Project Manager / Agile Team Facilitator (PMI-ACP)

    • Trong đề thi PMI-ACP, vai trò người dẫn dắt đội thường được mô tả là Agile Project Manager / Agile Team Facilitator.
    • Về hành vi, rất gần với Scrum Master: coach, facilitate, gỡ vướng, bảo vệ đội, tập trung vào giá trị & cải tiến.

  • Developers / Agile Team

    • Những người thực sự làm việc: phân tích, thiết kế, code, test, thiết kế UI, viết tài liệu vận hành, v.v.
    • Tự ước lượng và tự chọn lượng việc phù hợp cho Sprint (dựa trên velocity của chính đội).
    • Sở hữu Sprint Backlog và chịu trách nhiệm đạt Sprint Goal.
Scrum vs PMI-ACP terminology

Scrum Guide không có chức danh Project Manager – chỉ có Product Owner, Scrum Master, Developers (gộp lại là Scrum Team).
Trong PMI-ACP, đề thi vẫn dùng các từ như Agile Project Manager, Agile Leader, Team Facilitator. Khi gặp câu hỏi, hãy tập trung vào hành vi servant leadership, gỡ impediments, coach đội — đó chính là “chân dung” của Scrum Master / Agile Project Manager trong ngữ cảnh Agile.

Nhảy nhanh tới các bước chính​

1. Product Backlog – nơi mọi thứ bắt đầu

Ví dụ & ghi nhớ nhanh về Product Backlog

Hãy tưởng tượng Product Owner ngồi với một tờ giấy (hoặc tool), và viết:

  • Feature #1 – Accounts Receivable
  • Feature #2 – Accounts Payable
  • Feature #3 – Payroll
  • Feature #4 – Bank Reconciliation
  • Feature #5 – Reports
  • …

Đó chính là Product Backlog.

💡 Nhớ cho exam:
Product Backlog = danh sách các tính năng / yêu cầu mà stakeholders muốn, thường được mô tả dưới dạng Product Backlog Items (PBIs) / User Stories, được sắp xếp theo giá trị.

Điểm quan trọng:

  • PO là người tạo & duy trì Product Backlog.
  • PO xếp thứ tự theo giá trị: cái nào giúp business sống còn hơn thì đặt ở trên cùng.
    • Với hệ thống kế toán:
      1. Nhận tiền (Accounts Receivable)
      2. Trả tiền (Accounts Payable)
      3. Payroll
      4. Bank Reconciliation
      5. Reports…

Thêm một điều “kỳ diệu” nữa:

Product Backlog không bao giờ “xong”.
Trong lúc đội đang xây Accounts Receivable, khách hàng có thể nghĩ ra thêm: Inventory, Inventory Reports, tích hợp bank mới…

PO cứ thế thêm mới và re-prioritize.

2. Sprint Planning & Sprint Backlog

Ví dụ & ghi nhớ nhanh về Sprint Planning & Sprint Backlog

Khi đã có Product Backlog, đội bước vào Sprint Planning.

Sprint là gì?
  • Một timebox cố định (thường 1–4 tuần) đội dùng để:
    • chọn một Sprint Goal rõ ràng,
    • và hoàn thành một tập việc cụ thể để đạt Sprint Goal đó.

🔑 Ví dụ Sprint Goal:
“Trong Sprint này, người dùng có thể tạo và gửi hoá đơn để bắt đầu thu tiền.”

Trong Sprint Planning, có vài ý chính:

  1. Đội nhìn vào đỉnh Product Backlog
    • Chỉ lấy từ trên xuống, không nhảy xuống cuối chọn việc “mình thích”.
    • Đó là cách Scrum bảo vệ thứ tự giá trị của PO.
  2. Đội ước lượng khả năng (capacity / velocity)
    • Dựa trên kinh nghiệm Sprint trước, đội biết “bình thường sprint làm được tầm này việc”.
    • Ví dụ: đội thấy trong Sprint tới họ chỉ làm được 1 feature lớn, nên họ chọn Accounts Receivable.
  3. Tạo Sprint Backlog
    • Khi đã chọn xong, item (hoặc nhiều item) được đưa vào Sprint Backlog – tức là:
      “Những việc mà đội commit sẽ làm trong Sprint này để đạt Sprint Goal.”

Ví dụ:

  • Sprint 1: chỉ làm Accounts Receivable.
  • Sprint 2: làm Accounts Payable + Payroll (vì hai cái này nhỏ hơn).
Sprint vs Iteration (PMI-ACP)

Trong Scrum dùng từ Sprint.
Trong PMI-ACP và các phương pháp Agile nói chung, từ Iteration được dùng rộng hơn.
Khi đi thi, nếu đề nói Iteration mà bối cảnh là Scrum, bạn có thể hiểu đó là một Sprint.

3. Sprint Execution – làm việc trong Sprint

Ví dụ & ghi nhớ nhanh về Sprint Execution

Ngay sau Sprint Planning (thường là ngày hôm sau), Sprint bắt đầu.

Trong thời gian 1–4 tuần đó:

  • Đội code, test, thiết kế giao diện, viết tài liệu “vừa đủ”…

  • Với ví dụ kế toán:

    • Thiết kế màn hình lập hoá đơn.
    • Lưu & quản lý danh sách khách hàng.
    • Xử lý thanh toán, thu tiền, xử lý thuế bán hàng, v.v.

Để một công việc được coi là “Done”, đội cần một Definition of Done (DoD) chung:

  • Ví dụ DoD cho mỗi PBI:
    • Code xong.
    • Unit test pass.
    • Đã được review.
    • Đã test tích hợp ở môi trường staging.
    • Đã có note vận hành tối thiểu.

DoD giúp đảm bảo Increment cuối Sprint luôn usable, không phải “xong trên máy dev”.

Lưu ý PMI-ACP / Scrum:
  • Sprint là timebox cố định. Trong Sprint:
    • Không nên thay đổi Sprint Goal.
    • Không “đổ thêm việc” khi Sprint đang chạy (trừ trường hợp rất đặc biệt, và đội chấp nhận).
🔍 Tự soi

Đội của bạn đã có Definition of Done rõ ràng chưa, hay mỗi người hiểu “xong” theo một kiểu khác?

4. Daily Scrum (Daily Stand-up)

Ví dụ & ghi nhớ nhanh về Daily Scrum

Trong Sprint, mỗi ngày đội có một buổi Daily Scrum (daily stand-up):

  • Timebox tối đa 15 phút.

  • Cả đội (Developers) đứng thành vòng tròn (đứng để talk ngắn, không sa đà).

  • Mỗi người lần lượt trả lời 3 câu hỏi:

    1. Hôm qua mình đã làm gì (kể từ lần họp trước)?
    2. Hôm nay mình sẽ làm gì?
    3. Có vướng mắc / impediment gì đang cản trở không?

Ví dụ:

  • Bạn A:

    • Hôm qua: Hoàn thiện giao diện tạo hoá đơn.
    • Hôm nay: Nối logic lưu hoá đơn vào database.
    • Vướng mắc: Chưa rõ cách tính & tự áp thuế bán hàng.

  • Bạn B:

    • Hôm qua: Thiết kế bảng dữ liệu khách hàng.
    • Hôm nay: Tạo migration & seed data mẫu.
    • Vướng mắc: Tạm thời không.
Điểm quan trọng:
  • Daily Scrum không phải buổi họp “báo cáo cho sếp”.
  • Không giải quyết vấn đề ngay trong 15 phút; chỉ nêu vướng mắc.
    • Sau meeting, ai liên quan thì tách ra bàn sâu.
🔍 Tự soi

Daily hiện tại của bạn mang cảm giác cả đội đang cùng lập kế hoạch 24h tới, hay giống một buổi báo cáo cho sếp?

5. Sprint Review – khách hàng “sờ” vào sản phẩm

Ví dụ & ghi nhớ nhanh về Sprint Review

Khi hết Sprint (ví dụ sau 4 tuần), đội đã hoàn tất Accounts Receivable (và đáp ứng DoD cho những hạng mục đã chọn).

Giờ là lúc mời Product Owner và stakeholders vào Sprint Review:

  • Đội demo những gì đã hoàn thành:
    • Tạo hoá đơn.
    • Gửi hoá đơn.
    • Nhập thanh toán.
    • Xem một vài báo cáo cơ bản.
  • Khách hàng tự tay dùng:
    • Thử tạo một hoá đơn.
    • Thử nhập một thanh toán.
    • Xem dữ liệu hiển thị thế nào.

Tại đây, khách hàng đưa ra:

  • Chỗ nào họ thích.
  • Chỗ nào chưa ổn / cần sửa.
  • Những ý tưởng mới (ví dụ: muốn thêm chiết khấu, muốn filter báo cáo tốt hơn).

🔁 Kết quả Sprint Review thường là feedback mới + yêu cầu mới, được PO đưa lại vào Product Backlog và sắp xếp theo giá trị.

🔍 Tự soi

Sau mỗi “sprint”, khách hàng/stakeholder của bạn có được tự tay dùng sản phẩm thật không, hay chỉ xem slide & báo cáo?

6. Sprint Retrospective – đội soi lại chính mình

Ví dụ & ghi nhớ nhanh về Sprint Retrospective

Sau Sprint Review, khách hàng về, chỉ còn đội Scrum ở lại làm Sprint Retrospective.

Mục tiêu: cải tiến cách làm việc của đội, không phải đánh giá cá nhân.

Câu hỏi điển hình:

  • Điều gì đã làm tốt trong Sprint này? (cần giữ lại / làm nhiều hơn)
  • Điều gì chưa tốt? (cần giảm bớt / dừng)
  • Có điều gì muốn thử nghiệm ở Sprint tới?

Ví dụ cách “retro đời thường”:

“Trong cuộc sống của mình, mình nên bớt ăn fast food (McDonald’s) và ăn nhiều rau quả hơn.”

Retrospective cũng vậy, chỉ là áp dụng cho:

  • Cách team ước lượng.
  • Cách họp Daily Scrum.
  • Cách giao tiếp với PO.
  • Cách quản lý kỹ thuật, nợ kỹ thuật, v.v.

Quan trọng:

  • Chỉ cần 1–2 cải tiến nhỏ cụ thể để mang sang Sprint tiếp theo (ví dụ: giới hạn WIP trong cột “Doing”, rút Daily Scrum xuống 10 phút, chuẩn hoá cách viết acceptance criteria…).
🔍 Tự soi

Gần đây mỗi Sprint, đội của bạn có thực sự chọn được ít nhất 1 cải tiến nhỏ, cụ thể để thử ở Sprint tiếp theo không?

7. Increment & Release – “potentially releasable”

Ví dụ & ghi nhớ nhanh về Increment & Release

Kết thúc mỗi Sprint, đội có một Increment:

Increment = tổng tất cả Product Backlog Items đã “Done” (thoả DoD), tích luỹ qua các Sprint, nằm dưới một Definition of Done chung.

Increment này được gọi là “potentially shippable / releasable” vì:

  • Về mặt kỹ thuật, nó đã usable (đã đáp ứng DoD).
  • Product Owner có thể quyết định:
    • Release ngay (ví dụ: cả module Accounts Receivable đã xong trọn vẹn, khách dùng được).
    • Hoặc đợi thêm vài Sprint để ghép thêm tính năng cho bản release có nhiều giá trị hơn.

Ví dụ:

  • Nếu mới chỉ có danh sách khách hàng, chưa lập được hoá đơn, thì Increment:
    • vẫn usable theo DoD (code/test/triển khai chuẩn),
    • nhưng chưa tạo đủ giá trị business để PO muốn release ra người dùng.

Release:

  • thường là khi đã tích luỹ đủ increment để tạo thành một bản phát hành có ý nghĩa,
  • có thể sau 1 hoặc nhiều Sprint, tuỳ bối cảnh.
🔍 Tự soi

Tổ chức của bạn đang release theo kiểu từng increment nhỏ, đều đặn, hay vẫn là big-bang vài tháng/lần?

Tóm tắt 1 slide – Scrum Process​

  • Bắt đầu từ Product Backlog do Product Owner sắp xếp theo giá trị.
  • Sprint Planning → đội kéo việc từ đỉnh Product Backlog vào Sprint Backlog + đặt Sprint Goal.
  • Trong Sprint (1–4 tuần) → đội làm việc, mỗi ngày có Daily Scrum 15', đảm bảo từng item đạt DoD.
  • Cuối Sprint → Sprint Review (inspect Increment với khách hàng) + Sprint Retrospective (inspect & adapt process).
  • Mỗi Sprint → ít nhất một Increment “Done”, potentially releasable; nhiều Increment → Release cho người dùng.

Vòng lặp Sprint tiếp theo & Product Backlog “không đáy”​

Ví dụ & ghi nhớ nhanh về vòng lặp Sprint & Product Backlog “không đáy”

Quay lại câu chuyện:

  • Product Backlog ban đầu có 5 mục.
  • Sprint 1: đội làm xong Accounts Receivable (1 mục).
  • Trong khi đội đang làm, khách hàng nghĩ thêm:
    • Inventory Management
    • Inventory Reports
      → giờ Product Backlog không phải còn 4, mà là 6.

Đây là điểm quan trọng:

🔁 Product Backlog là danh sách sống

Product Backlog là danh sách sống. Trong khi đội làm, PO liên tục thêm, xóa, chỉnh lại thứ tự, dựa trên feedback và nhu cầu mới.

Sprint 2:

  • Đội quay lại Product Backlog, nhìn từ trên xuống.
  • Thấy Accounts Payable và Payroll đều tương đối nhỏ → quyết định làm cả hai trong Sprint tới.
  • Lặp lại: Sprint Planning → Sprint → Daily Scrum → Sprint Review → Retrospective → Increment → Backlog.
Sprint 1 → chỉ làm (1) Accounts Receivable
Sprint 2 → làm (2) Accounts Payable + (3) Payroll
Sprint 3 → Bank Reconciliation + một phần Reports
...

Sau mỗi vòng:

  • Sản phẩm dày dần lên (ngày càng nhiều chức năng hữu dụng).
  • Khách hàng nhận được giá trị sớm (đã có thể dùng Accounts Receivable ngay từ Sprint đầu).
  • Đội học thêm về domain & kỹ thuật, cải tiến cách làm việc của chính mình.

Minh hoạ ASCII – Scrum Process​

Scrum flow (ASCII)
Ideas / Needs
      ↓
Product Owner → Product Backlog (ordered by value)
      ↓
Sprint Planning → Sprint Backlog + Sprint Goal
      ↓
   Sprint (1–4 weeks)
      ↳ Daily Scrum (15')
      ↓
Sprint Review (inspect Increment with customer)
      ↓
Sprint Retrospective (inspect & adapt process)
      ↓
Increment (Done, potentially releasable)
      ↺ Feedback & new ideas → back to Product Backlog

Thuật ngữ Scrum trong bài (cheat sheet ôn thi 📚)​

Thuật ngữTóm tắt (theo PMI-ACP/Scrum)
Product OwnerĐại diện khách hàng / business; sở hữu & ưu tiên Product Backlog; tối đa hoá giá trị.
Product BacklogDanh sách toàn bộ yêu cầu cho sản phẩm; sắp xếp theo giá trị; luôn sống, luôn thay đổi.
SprintTimebox 1–4 tuần; tạo ra một Increment “Done” và Sprint Goal rõ ràng.
Sprint GoalMục tiêu của Sprint, trả lời “Sprint này chúng ta đang cố đạt điều gì?”; hướng dẫn mọi quyết định trong Sprint.
Sprint PlanningCuộc họp đầu Sprint nơi đội chọn việc từ đỉnh Product Backlog và xây Sprint Backlog để đạt Sprint Goal.
Sprint BacklogDanh sách việc đội cam kết làm trong Sprint để đạt Sprint Goal; thuộc quyền sở hữu của Developers.
Daily Scrum (Daily Stand-up)15 phút mỗi ngày; đội đồng bộ công việc và impediments; không là buổi báo cáo cho sếp.
Sprint ReviewCuối Sprint; stakeholders inspect Increment và đưa feedback; thường tạo yêu cầu mới vào Product Backlog.
Sprint RetrospectiveCuối Sprint; đội inspect & adapt cách làm việc (lessons learned, cải tiến).
Definition of Done (DoD)Bộ tiêu chuẩn để một item được coi là “Done” (code, test, tích hợp…); áp dụng cho mọi PBI/Increment.
IncrementTổng tất cả items đã “Done” trong các Sprint; mỗi Sprint phải tạo ra ít nhất 1 Increment usable theo DoD.
ReleaseMột hoặc nhiều Increment được triển khai cho người dùng/production.
VelocityĐo năng lực hoàn thành việc của đội mỗi Sprint (chỉ dùng nội bộ đội để forecast).

Blueprint tie-ins (ECO 2025)​

Advanced – Liên kết Scrum Process với ECO 2025
Bước ScrumMindsetLeadershipProductDelivery
Product Backlog & POTư duy value-driven, minh bạch yêu cầuPO đưa quyết định dựa trên giá trị & feedbackQuản lý backlog, roadmap, outcomeChuẩn bị nền tảng cho incremental delivery
Sprint & Sprint PlanningEmpiricism, timeboxing, focusTeam empowerment, servant leadershipSprint Goal gắn với outcome rõ ràngIncremental delivery theo Sprint
Daily ScrumInspect & adapt hàng ngàyTự quản, tự điều chỉnh kế hoạchCăn chỉnh công việc gần nhất với Sprint GoalTheo dõi tiến độ, xử lý impediments sớm
Sprint ReviewFeedback sớm, co-creation với kháchThu hút stakeholders vào quá trình họcThích nghi Product Backlog theo giá trị mớiKiểm tra giá trị đã giao qua Increment
Sprint RetrospectiveKaizen, continuous improvementTạo môi trường an toàn để cải tiếnNâng cao khả năng đáp ứng nhu cầu tương laiCải thiện flow & chất lượng delivery qua từng Sprint
Increment & ReleaseTư duy sản phẩm “luôn usable”Ra quyết định phát hành có trách nhiệmQuản lý roadmap release theo giá trịGiao giá trị theo từng đợt, giảm risk big-bang

Exam patterns & traps (Scrum Process)​

  • Product Backlog:

    • Do Product Owner sở hữu & ưu tiên, không phải Project Manager.
    • Luôn có thể thêm/bớt/sửa ưu tiên, kể cả khi dự án đang chạy.

  • Sprint Planning & Sprint Backlog:

    • Đội tự chọn lượng việc phù hợp với capacity và velocity.
    • Chỉ lấy từ đỉnh Product Backlog → bảo toàn giá trị.
    • Output chính: Sprint Goal + Sprint Backlog.

  • Daily Scrum:

    • Timebox 15 phút; team-to-team communication.
    • Không phải nơi giải quyết chi tiết mọi vấn đề.

  • Sprint Review vs Retrospective:

    • Review: tập trung vào product (Increment) với khách hàng/stakeholders.
    • Retro: tập trung vào process/team (cải tiến nội bộ).

  • Increment vs Release:

    • Mỗi Sprint → ít nhất một Increment usable (thoả DoD).
    • Release có thể sau 1 hoặc nhiều Sprint.

  • Value & Incremental Delivery:

    • Scrum luôn cố gắng giao phần giá trị cao nhất trước (ví dụ: Accounts Receivable).
    • So với dự án truyền thống, khách hàng thấy giá trị sớm hơn nhiều (Accounts Receivable sau ~4 tuần).

Lộ trình học 30 phút & câu hỏi tự soi​

  1. 5’ – Đọc TL;DR + sơ đồ ASCII.
  2. 8’ – Đọc kỹ các bước 1–7, tập trung vào flow chứ chưa cần thuộc từ vựng.
  3. 7’ – Lấy một dự án bạn biết (kể cả life-project) và thử vẽ lại Scrum Process cho chính dự án đó.
  4. 5’ – Đọc bảng thuật ngữ và highlight những chỗ bạn hay nhầm (Review vs Retro, Increment vs Release, Sprint vs Iteration…).
  5. 5’ – Làm mini-mock dưới đây, ghi lại 1–2 chỗ mình sai.

Gợi ý câu hỏi tự soi (cho người đang đi làm):

  • Đội hiện tại có demo sản phẩm thật cho khách mỗi Sprint không, hay chỉ demo trên slide?
  • Daily Scrum của bạn đang là cuộc họp của đội, hay là buổi báo cáo cho sếp?
  • Đội đã có một Definition of Done rõ ràng chưa, hay mỗi người hiểu “xong” một kiểu?

Checklist – Scrum Process (VI)

Tiến độ: 0/5 (0%)

Mini-mock – Scrum Process

Loading questions…

Bước tiếp theo:
Agile Values • Different Agile Methods • Agile vs Traditional

Liên hệ & cập nhật

Không spam. Bạn có thể huỷ đăng ký bất cứ lúc nào.