Scrum Artifacts – Product Backlog, Sprint Backlog, Increment (PMI-ACP)
Scrum Artifacts – 3 “kho chứa thông tin” chính của Scrum, giúp mọi người nhìn cùng một sự thật.
Ngôn ngữ • Language
- VI
- EN
Scrum Artifacts – Product Backlog, Sprint Backlog, Increment
💡 Bài này dành cho ai?
- Bạn đã đọc Scrum Process và Scrum Activities, giờ đến lượt câu hỏi “Scrum lưu trữ thông tin ở đâu?”
- Bạn hay nghe cụm Product Backlog, Sprint Backlog, Increment, Definition of Done mà vẫn thấy lẫn lộn.
- Bạn chuẩn bị thi PMI-ACP và muốn hiểu rõ 3 Scrum Artifacts & các cam kết đi kèm theo Scrum Guide mới.
TL;DR – 3 Scrum Artifacts & 3 “commitments”
- Scrum có 3 Scrum Artifacts:
- Product Backlog – danh sách công việc được ưu tiên theo value cho toàn bộ sản phẩm; Product Owner chịu trách nhiệm.
- Sprint Backlog – phần việc được chọn từ Product Backlog để làm trong một Sprint + plan để đạt Sprint Goal; thuộc về Developers.
- Increment (Product Increment) – phần sản phẩm đã hoàn thành trong Sprint, đáp ứng Definition of Done, có thể đem đi dùng / release.
- Mỗi artifact đi kèm một commitment:
- Product Backlog → Product Goal.
- Sprint Backlog → Sprint Goal.
- Increment → Definition of Done (DoD).
- Keyword hay ra đề PMI-ACP: Product Backlog, Sprint Backlog, Increment, Product Goal, Sprint Goal, Definition of Done, refinement (grooming), transparency.
Lối tắt:ECO 2025 · 4 domain
Cho người mới bắt đầu
Nếu thấy bài dài, bạn có thể:
- Đọc phần TL;DR + bảng tóm tắt ở giữa bài.
- Đọc kỹ 3 mục: Product Backlog, Sprint Backlog, Increment.
- Cuối cùng đọc phần Exam patterns & traps để né bẫy đề.
🤭 Fun fact nhỏ về “grooming” vs “refinement”
- Ngày xưa, nhiều tài liệu dùng từ “Product Backlog Grooming”.
- Scrum Guide bản mới dùng từ “Product Backlog Refinement” để trung tính hơn.
- Trong đề thi, bạn có thể gặp cả hai:
- Hễ thấy grooming / refinement Product Backlog → hãy nghĩ đến việc thêm, bớt, làm rõ, estimate, sắp xếp lại các Product Backlog Item (PBI).
Những thứ không phải Scrum Artifact
- Burn-down chart, velocity chart, task board, test report… thường được gọi là information radiators, nhưng không phải 3 Scrum Artifacts chính thức.
- Definition of Done, Product Goal, Sprint Goal là các cam kết (commitments) gắn với artifacts, chứ không phải artifacts riêng lẻ.
1. Bức tranh tổng thể: 3 Scrum Artifacts trong Scrum
Scrum thường được tóm nhanh thành:
- 3 Roles – Product Owner, Scrum Master, Developers.
- 5 Events – Sprint + 4 buổi họp chính (Planning, Daily, Review, Retro).
- 3 Artifacts – Product Backlog, Sprint Backlog, Increment.
Trong đó:
- Artifacts giống như 3 “kho chứa thông tin” – mọi người nhìn vào để thấy cùng một sự thật về work còn lại, work đang làm, và work đã xong.
- Nếu roles là “ai làm”, events là “làm khi nào và cùng nhau như thế nào”, thì artifacts là “chúng ta đang làm cái gì và đã xong tới đâu”.
- Product Backlog – danh sách việc được ưu tiên theo value
2.1. Product Backlog là gì?
Dịch “bình dân”:
- Product Backlog = “toàn bộ danh sách việc có thể làm cho sản phẩm”, được sắp xếp theo giá trị (value).
- Đây là nơi chứa:
- Tính năng (feature),
- Nhu cầu người dùng (user story),
- Bug, nợ kỹ thuật, hoạt động nghiên cứu, spike…
Hình dung: Product Backlog là hàng đợi những thứ “có thể làm” cho sản phẩm, trong đó hàng đầu là những thứ đáng làm nhất ở thời điểm hiện tại.
2.2. Ai sở hữu Product Backlog?
- Product Owner chịu trách nhi ệm chính (accountable) về:
- Nội dung (gồm những item nào).
- Thứ tự ưu tiên (ordered by value).
- Scrum Team vẫn có thể đề xuất, thêm ý tưởng, nhưng:
- Quyết định cuối cùng về ưu tiên vẫn là Product Owner – dựa trên value, risk, dependency…
Bẫy đề: “Chỉ PO mới được chạm vào Product Backlog, team không được sửa gì” thường là diễn giải quá cứng nhắc.
Đúng hơn: PO quyết về thứ tự & nội dung, nhưng tiếp nhận input từ cả team & stakeholder.
2.3. Đặc điểm quan trọng của Product Backlog
- Được ưu tiên theo value – mục tiêu là tối đa hóa value, không chỉ “đi hết scope”.
- Dynamic / emergent – không phải danh sách cố định:
- Có thể thêm việc mới bất kỳ lúc nào.
- Có thể xoá những việc không còn value.
- Có thể sắp xếp lại thứ tự khi bối cảnh thay đổi.
- Không bao giờ “xong hẳn” – miễn sản phẩm còn sống, Product Backlog vẫn tiếp tục thay đổi.
Nếu đề thi nói “Product Backlog được frozen / khoá cứng trong dự án” → gần như chắc là sai với tinh thần Agile.
2.4. Product Backlog Refinement (grooming)
Trong thực tế, bạn sẽ hay nghe đến việc “grooming” Product Backlog – hiểu thế này cho đơn giản:
- Product Backlog Refinement = hoạt động liên tục trong Sprint để:
- Làm rõ (clarify) yêu cầu, acceptance criteria.
- Chẻ nhỏ (split) các item quá to.
- Estimate, cập nhật effort.
- Sắp xếp lại thứ tự ưu tiên.
- Tham gia:
- Product Owner + Developers là chính.
- Scrum Master hỗ trợ facilitation khi cần.
Ví dụ:
- Một feature ở đáy backlog sau khi nói chuyện với khách hàng bỗng trở nên rất giá trị → được kéo lên trên.
- Một ý tưởng cũ giờ không còn phù hợp → bị xoá khỏi backlog.
Từ “grooming” trong đề thi
- Nếu đề nhắc “grooming the Product Backlog” → hiểu là refinement.
- Đừng nghĩ đó là một “buổi họp cố định” bắt buộc mỗi Sprint; nó là hoạt động liên tục, có thể được tổ chức thành các phiên họp nhỏ.
- Sprint Backlog – việc sẽ làm trong Sprint này
3.1. Sprint Backlog là gì?
- Sprint Backlog là tập con của Product Backlog – những item được chọn để làm trong Sprint hiện tại.
- Nó luôn đi kèm:
- Một Sprint Goal rõ ràng.
- Một plan (kế hoạch) để đạt Sprint Goal – thường được bẻ nhỏ thành task, kỹ thuật, test, v.v.
Nói dễ hiểu: Product Backlog là “mọi thứ có thể làm”, còn Sprint Backlog là “những thứ team cam kết cố gắng làm trong 1 Sprint”.
3.2. Ai sở hữu Sprint Backlog?
- Developers s ở hữu Sprint Backlog:
- Họ quyết định kéo bao nhiêu việc vào Sprint dựa trên capacity & historical velocity.
- Họ là người điều chỉnh Sprint Backlog mỗi ngày dựa trên những gì học được.
- Product Owner:
- Tham gia Sprint Planning, giúp chọn việc đúng value, nhưng không ép team nhận quá sức.
Bẫy: “PO thêm việc vào Sprint Backlog giữa Sprint mà không bàn với team” → anti-pattern.
3.3. Đặc điểm Sprint Backlog
- Highly visible – nên thể hiện trên board / tool sao cho ai cũng nhìn thấy:
- Còn bao nhiêu việc.
- Đang tắc ở đâu.
- Tiến độ tới Sprint Goal thế nào.
- Forecast, không phải contract:
- Sprint Backlog là dự báo của Developers về những gì họ có thể hoàn thành.
- Họ có thể điều chỉnh task, tách / gộp việc, miễn vẫn giữ được Sprint Goal.
Product Backlog vs Sprint Backlog
- Product Backlog: dài hơi, cho toàn bộ sản phẩm; PO chịu trách nhiệm.
- Sprint Backlog: ngắn hạn cho 1 Sprint; Developers chịu trách nhiệm.
- Increment – phần sản phẩm đã “done”
4.1. Increment là gì?
- Sau mỗi Sprint, bạn có một Product Increment – phần sản phẩm đã hoàn thành, có thể đem đi dùng (potentially releasable).
- Mục tiêu:
- Giao được một thứ thật để lấy feedback.
- Giúp stakeholder sờ tận tay xem thích hay không.
Không phải Sprint nào cũng bắt buộc phải release ra production, nhưng mỗi Sprint phải tạo ra ít nhất một Increment có thể release được.
4.2. Một vài điểm dễ bị nhầm
- Có thể có nhiều Increment trong một Sprint – nhất là khi team release nhỏ, thường xuyên.
- Mỗi Increment:
- Bao gồm tất cả Increment trước đó đã hoàn thành + phần mới vừa làm.
- Phải đáp ứng Definition of Done.
- Code đang làm dở, chưa test xong, không pass DoD → chưa phải là Increment.
Increment & Definition of Done
- Nếu trong đề, team muốn “count” cả phần việc chưa test, chưa document là “done” để kịp deadline → thường là sai.
- Increment chỉ gồm những Product Backlog Item đã thoả Definition of Done – phần còn lại vẫn nằm trong Product Backlog / Sprint Backlog.
- Definition of Done, Product Goal, Sprint Goal – các cam kết đi kèm
Nội dung chuẩn Scrum nhấn mạnh rằng:
- “The product owner and team needs to agree upon the definition of done…”
- “…before the team really starts to work on the product…”
Đây là phần rất hay ra đề, nên gom lại cho dễ nhớ.
5.1. Definition of Done (DoD)
- Definition of Done = định nghĩa chung của Scrum Team về “thế nào là xong” cho một Product Backlog Item / Increment.
- Ví dụ đơn giản:
- Code xong & review xong.
- Test unit + integration pass.
- Không còn bug blocker / critical.
- Document / migration script đã được cập nhật (nếu chính sách team yêu cầu).
Tại sao DoD quan trọng?
- Giúp minh bạch chất lượng – tránh tình trạng mỗi người hiểu “xong” một kiểu.
- Giảm nợ kỹ thuật bị giấu.
- Là base để tính velocity cho các Sprint sau.
DoD là cam kết gắn với Increment – Increment chỉ được tính là đã “shipped” trong nội bộ khi đáp ứng DoD.
5.2. Product Goal – cam kết của Product Backlog
- Product Goal mô tả mục tiêu dài hơi mà sản phẩm đang hướng tới.
- Product Backlog nên được sắp xếp sao cho:
- Những PBI trên cùng đưa sản phẩm lại gần Product Goal.
- Khi Product Goal đạt được:
- Team có thể định nghĩa Product Goal mới cho giai đoạn tiếp theo.
Product Goal là commitment gắn với Product Backlog – giúp backlog không trở thành “bãi rác ý tưởng”.
5.3. Sprint Goal – cam kết của Sprint Backlog
- Sprint Goal trả lời câu hỏi:
“Sprint này có ý nghĩa gì? Nếu phải tóm trong 1–2 câu, chúng ta đang cố gắng đạt điều gì?” - Sprint Backlog (các item được chọn + plan) phục vụ cho Sprint Goal.
Sprint Goal là commitment gắn với Sprint Backlog – trong Sprint, team có thể điều chỉnh task, nhưng không nên phá vỡ Sprint Goal nếu không có lý do nghiêm trọng.
6. Bảng tóm tắt – Scrum Artifacts & commitments
| Artifact | Mô tả | Ai chịu trách nhiệm chính? | Commitment đi kèm |
|---|---|---|---|
| Product Backlog | Danh sách được ưu tiên của mọi thứ có thể làm cho sản phẩm (feature, bug, nợ kỹ thuật, research...). | Product Owner | Product Goal |
| Sprint Backlog | Các PBI được chọn cho Sprint hiện tại + plan (task) để hoàn thành. | Developers | Sprint Goal |
| Increment | Phần sản phẩm đã hoàn thành trong Sprint, đáp ứng DoD, có thể đem đi dùng / release. | Scrum Team | Definition of Done |
7. Exam patterns & traps – Scrum Artifacts
Advanced – Bẫy đề PMI-ACP về Scrum Artifacts
- Product Backlog bị “đóng băng”
- Scrum xem Product Backlog là dynamic. Đáp án nói backlog “fixed mọi thứ từ đầu dự án đến cuối” thường là anti-Agile.
- Sai owner
- Product Backlog → PO.
- Sprint Backlog → Developers.
- Increment → thuộc về cả Scrum Team, phải đáp ứng DoD.
- Câu nào “Project Manager” đứng ra control backlog trong Scrum thường là sai.
- PO tự ý chỉnh Sprint Backlog giữa Sprint
- PO có thể đề xuất, nhưng Developers mới là người quyết định Sprint Backlog thay đổi thế nào để vẫn giữ Sprint Goal.
- Đếm việc chưa Done vào Increment
- Code chưa test, chưa đáp ứng DoD không được count là Increment.
- Đề thi rất hay đưa lựa chọn “coi như done để kịp deadline” – thường là đáp án sai.
- DoD thay đổi tuỳ theo ý khách ngay giữa Sprint
- DoD có thể tiến hoá theo thời gian (giữa các Sprint) nhưng không nên thay đổi bừa bãi giữa Sprint để hợp thức hoá việc chưa xong.
8. Checklist học & tự soi
- Nhìn vào project hiện tại của bạn, thử trả lời:
- Product Backlog của bạn đang ở đâu? Ai đang thực sự “order” nó?
- Sprint Backlog hiện tại trông như thế nào? Đã rõ Sprint Goal chưa?
- Increment gần nhất có thật sự đáp ứng một DoD rõ ràng?
- Tự viết lại định nghĩa ngắn cho 3 artifacts + 3 commitments.
- Ghi 1–2 bẫy đề về Scrum Artifacts mà bạn hay nhầm.
Checklist – Scrum Artifacts (VI)
Tiến độ: 0/5 (0%)
Mini-mock – Scrum Artifacts
Loading questions…
9. Liên hệ ECO / Blueprint PMI-ACP
- Agile Principles & Mindset
- Transparency, inspect & adapt được phản ánh trực tiếp qua cách team quản lý artifacts.
- Product Backlog dynamic theo value, không phải scope cố định.
- Product / Delivery
- Product Backlog & Product Goal gắn với value-driven delivery.
- Increment + DoD thể hiện khả năng giao hàng từng bước với chất lượng ổn định.
- Team Performance
- Sprint Backlog do Developers sở hữu, thể hiện self-organization & ownership.
- Các quyết định về DoD, refinement, v.v. đều là kết quả collaboration trong Scrum Team.
- Problem Detection & Resolution / Continuous Improvement
- Việc thường xuyên refine Product Backlog, nâng chuẩn DoD giúp phát hiện & xử lý vấn đề sớm.
Khi gặp câu hỏi về danh sách công việc, “xong chưa”, timebox nào chứa gì… rất có thể đề đang test bạn về Scrum Events + Scrum Artifacts + các commitments cùng lúc.
Bài liên quan: Scrum Process
•
Scrum Roles and Responsibilities
•
Scrum Activities
Scrum Artifacts – Product Backlog, Sprint Backlog, Increment
💡 Who this article is for
- You’ve read Scrum Process and Scrum Activities, and now wonder: “Where does Scrum keep all the work and progress?”
- You’ve heard terms like Product Backlog, Sprint Backlog, Increment, Definition of Done but still mix them up.
- You’re preparing for PMI-ACP and want a clear, exam-friendly view of the 3 Scrum Artifacts and their commitments.
TL;DR – 3 Scrum Artifacts & 3 commitments
- Scrum defines 3 main Artifacts:
- Product Backlog – a value-ordered list of everything that might be needed in the product; Product Owner is accountable.
- Sprint Backlog – selected Product Backlog Items for the current Sprint + the plan to achieve the Sprint Goal; owned by Developers.
- Increment (Product Increment) – the usable portion of the product created in a Sprint that meets the Definition of Done.
- Each artifact has a commitment:
- Product Backlog → Product Goal.
- Sprint Backlog → Sprint Goal.
- Increment → Definition of Done (DoD).
- Common PMI-ACP keywords: Product Backlog, Sprint Backlog, Increment, Product Goal, Sprint Goal, Definition of Done, refinement (grooming), transparency.
Lối tắt:ECO 2025 · 4 domain
For beginners
If this feels dense:
- Read the TL;DR and the summary table.
- Focus on the 3 sections: Product Backlog, Sprint Backlog, Increment.
- Before your exam, revisit the Exam patterns & traps section.
🤭 Fun fact about “grooming” vs “refinement”
- Older materials often use the term “Product Backlog Grooming”.
- Newer Scrum Guides prefer “Product Backlog Refinement”.
- In questions, treat both “grooming” and “refinement” as the same underlying idea:
clarifying, splitting, estimating, and reordering Product Backlog Items.
Things that are not Scrum Artifacts
- Burn-down charts, velocity charts, task boards, test reports… are useful information radiators but not official Scrum Artifacts.
- Definition of Done, Product Goal, and Sprint Goal are commitments tied to artifacts, not separate artifacts.
1. Big picture: 3 Scrum Artifacts in Scrum
Scrum is often summarized as:
- 3 Roles – Product Owner, Scrum Master, Developers.
- 5 Events – the Sprint plus 4 main meetings.
- 3 Artifacts – Product Backlog, Sprint Backlog, Increment.
In this view:
- Artifacts are like 3 shared “information stores”:
one for all possible work, one for this Sprint’s work, and one for done work. - If roles are about who, and events are about when/how we collaborate, artifacts are about what we are doing and how far we’ve come.
- Product Backlog – ordered by value
2.1. What is the Product Backlog?
In simple terms:
- The Product Backlog is the ordered list of everything that might be needed in the product,
sorted by value. - It may contain:
- Features, user stories,
- Bugs and technical debt,
- Research items, spikes, experiments…
Think of it as a queue of “things we could do”, where the top items are the most valuable right now.
2.2. Who owns the Product Backlog?
- The Product Owner is accountable for:
- What is in the backlog.
- The order of items (based on value, risk, dependencies, etc.).
- The Scrum Team and stakeholders can suggest ideas, but:
- The PO makes the final decision on ordering and content.
2.3. Key characteristics
- Ordered by value – goal is maximizing value, not just burning through scope.
- Dynamic / emergent – not a frozen contract:
- New items can be added anytime.
- Items with no value can be removed.
- Ordering can change as we learn.
- Never “finally done” – as long as the product is alive, the Product Backlog keeps evolving.
2.4. Product Backlog Refinement (grooming)
- Product Backlog Refinement is an ongoing activity where:
- Items are clarified.
- Large items are split.
- Estimates are added/updated.
- Ordering is adjusted.
- Typically involves:
- Product Owner + Developers, with Scrum Master facilitating if needed.
If an exam question mentions “grooming the Product Backlog”, read it as refinement – not as a new separate Scrum Event.
- Sprint Backlog – work for this Sprint
3.1. What is the Sprint Backlog?
- The Sprint Backlog is the subset of Product Backlog Items selected for the current Sprint.
- It includes:
- The selected PBIs.
- The Sprint Goal.
- A plan (tasks, technical steps, tests…) to achieve that goal.
Short version: Product Backlog is “all possible work”, Sprint Backlog is “work we’re trying to complete this Sprint”.
3.2. Who owns the Sprint Backlog?
- Developers own the Sprint Backlog:
- They decide how much to pull, based on capacity and past performance.
- They update it daily as they learn more.
- The Product Owner:
- Helps pick the right items for value, but does not force extra work mid-Sprint.
3.3. Characteristics
- Highly visible – should be transparent to everyone (board, digital tool, etc.).
- A forecast, not a guarantee:
- It’s the team’s best forecast of what they can complete.
- They may re-plan tasks, split/merge work, as long as they still aim at the Sprint Goal.
Product Backlog vs Sprint Backlog
- Product Backlog: long-term, for the whole product; Product Owner is accountable.
- Sprint Backlog: short-term, for a single Sprint; Developers are accountable.
- Increment – what is actually “Done”
4.1. What is an Increment?
- At the end of each Sprint, you have a Product Increment – a slice of the product that is usable and potentially releasable.
- The idea:
- Build something real.
- Show it to customers/stakeholders.
- Get feedback and adjust.
4.2. Important details
- You can have multiple Increments in one Sprint if you release frequently.
- Each Increment:
- Builds on top of all previous Increments.
- Must meet the Definition of Done.
- Partially tested code that doesn’t meet DoD → is not part of the Increment yet.
- Definition of Done, Product Goal, Sprint Goal – the commitments
5.1. Definition of Done (DoD)
- The Definition of Done is the Scrum Team’s shared understanding of “what it means for work to be complete”.
- Typically includes:
- Code complete and reviewed.
- Tests passing.
- No critical defects.
- Documentation updated, if the team policy requires it.
DoD matters because it:
- Makes quality visible.
- Keeps technical debt under control.
- Provides a stable basis to measure velocity.
5.2. Product Goal
- The Product Goal is the long-term objective for the product.
- The Product Backlog is ordered to bring the product closer to this goal.
- Once the Product Goal is achieved, a new one can be set.
5.3. Sprint Goal
- The Sprint Goal explains why this Sprint is valuable in 1–2 sentences.
- The Sprint Backlog (selected items + plan) is built to support the Sprint Goal.
6. Summary table – Scrum Artifacts & commitments
| Artifact | Description | Accountable owner | Commitment |
|---|---|---|---|
| Product Backlog | Ordered list of everything that might be needed in the product. | Product Owner | Product Goal |
| Sprint Backlog | Selected PBIs for the current Sprint + plan to deliver them. | Developers | Sprint Goal |
| Increment | Usable slice of the product created in a Sprint, meeting the DoD. | Scrum Team | Definition of Done |
7. Exam patterns & traps – Scrum Artifacts
Advanced – common PMI-ACP traps
-
Frozen Product Backlog
- Scrum treats the Product Backlog as dynamic and emergent. Answers that freeze it as a fixed contract are usually wrong.
-
Wrong ownership
- Product Backlog → Product Owner.
- Sprint Backlog → Developers.
- Increment → whole Scrum Team, must meet DoD.
- “Project Manager controls the backlog” is rarely correct in Scrum questions.
-
PO changing Sprint Backlog alone
- The PO can suggest changes, but only Developers can change the Sprint Backlog as they learn more.
-
Counting unfinished work as Increment
- Work that doesn’t meet DoD is not part of the Increment yet.
- In exam options, “count half-done work as done to hit the deadline” is a red flag.
-
Randomly moving the DoD mid-Sprint
- DoD can evolve over time (across Sprints), but ad-hoc relaxing it during a Sprint just to say “we’re done” is usually an anti-pattern answer.
8. Checklist & self-reflection
- Identify your current project’s Product Backlog, Sprint Backlog, and last Increment.
- Write your own short definition of each artifact + its commitment.
- Note 1–2 exam traps on Scrum Artifacts that you personally tend to fall for.
Checklist – Scrum Artifacts (EN)
Tiến độ: 0/5 (0%)
Mini-mock – Scrum Artifacts
Loading questions…
9. Linking to ECO / Blueprint domains
- Agile Principles & Mindset
- Transparency, inspect & adapt shown through how the team manages artifacts.
- Product / Delivery
- Product Backlog + Product Goal connect to value-driven delivery.
- Increment + DoD show the ability to deliver working product at a sustainable quality bar.
- Team Performance
- Developers owning the Sprint Backlog demonstrates self-organization and ownership.
- Continuous Improvement / Problem Detection & Resolution
- Regular refinement and evolving DoD help detect and resolve issues early.
When a question mentions backlogs, “done”, or what is visible to stakeholders, it’s often testing your understanding of Scrum Events + Artifacts + commitments together.
Related articles: Scrum Process
•
Scrum Roles and Responsibilities
•
Scrum Activities