Overview
Advanced Scrum Concepts is the eighth SMPC learning-objective area. Unlike the earlier areas, most of this content is not in the Scrum Guide. It covers complementary practices that Scrum Teams often use inside the framework, drawn from the Agile Glossary that CertiProf cites and from partner course outlines. These include user stories written to the INVEST criteria, relative estimation with Planning Poker and story points, velocity and burndown charts for forecasting, Kanban boards and work-in-progress limits, the minimum viable product, and Scrum of Scrums as a way to coordinate several teams.
The key exam skill is knowing two things about each practice: what it is for, and that it is optional. Scrum is purposefully incomplete, so a team may use these practices, but none of them replaces an accountability, event, artifact or commitment. Scaling frameworks such as SAFe or LeSS are not part of SMPC content; scaling sits in a separate CertiProf credential.
How it's tested
Questions describe a practice and ask its purpose, or show a team misusing it and ask for the best response. Expect INVEST letter recall, Planning Poker mechanics, velocity misuse, Kanban metrics such as WIP limits, MVP definitions and the role of a Scrum of Scrums. Several items test whether a practice is mandatory in Scrum.
-
Purpose of a practice
A technique such as Planning Poker or a WIP limit is named, and you choose what it is designed to achieve.
-
Misused metric
Management compares velocity between teams or sets velocity targets, and you identify the problem and the Scrum Master's response.
-
Optional or required
You decide whether a practice such as user stories or story points is part of Scrum's immutable core.
A director ranks three Scrum Teams by velocity and asks the slowest to match the fastest. The tempting answer is to help the slow team raise its points. Velocity is a team-specific measure based on its own relative estimates, so comparing teams is meaningless and invites point inflation. The Scrum Master should explain this and steer the conversation toward delivered value and Sprint Goal achievement.
Topics 6
Official topics from the CertiProf outline, in outline order.
8.1 User stories and the INVEST modelA common format for Product Backlog items and criteria for good ones.
- What it means
- A user story describes a need from a user's point of view, often in the form: as a type of user, I want some goal so that some reason. INVEST is a checklist for good stories: Independent, Negotiable, Valuable, Estimable, Small and Testable.
- What to understand
- User stories are one way to express Product Backlog items; the Scrum Guide does not require them. Stories are deliberately short and act as a placeholder for conversation, often summarized as card, conversation and confirmation. Acceptance criteria clarify when a story satisfies the user, while the Definition of Done applies to all work. Large stories, often called epics, are split during refinement until they fit within a Sprint.
- How it shows up
- Expect INVEST letter recall and questions on what makes a backlog item ready for a Sprint.
- Common confusion
- Confusing acceptance criteria for one story with the Definition of Done that applies to every item.
8.2 Estimation and Planning PokerRelative sizing with story points using a consensus game.
- What it means
- Planning Poker is a consensus-based technique in which Developers privately choose a card, often from a modified Fibonacci sequence, to estimate an item's relative size, then reveal cards together and discuss differences.
- What to understand
- Revealing at the same time avoids anchoring on the first opinion. The highest and lowest estimators explain their reasoning, and the group re-votes until it converges. Story points measure relative effort, complexity and uncertainty rather than hours. Only the Developers who will do the work estimate; the Product Owner answers questions, and the Scrum Master may facilitate. Other techniques include T-shirt sizes and affinity estimation.
- How it shows up
- Items ask who estimates, why cards are revealed together and what story points represent.
- Common confusion
- Treating story points as hours or allowing the Product Owner to set the estimate.
8.3 Velocity and progress trackingMeasuring a team's completed work to support forecasting.
- What it means
- Velocity is the amount of work, often in story points, that a team completes to its Definition of Done in a Sprint. Burndown and burnup charts show remaining or completed work over time.
- What to understand
- Velocity helps a team forecast how much it might take into a Sprint and how long a set of backlog items might take. It is specific to one team and its own estimation scale, so comparing teams is meaningless. Only Done work counts. The 2020 Scrum Guide notes that practices such as burndowns, burnups and cumulative flows have proven useful for forecasting, but they do not replace empiricism; only what has already happened may be used for forward-looking decisions.
- How it shows up
- Expect velocity misuse scenarios and questions on which work counts toward velocity.
- Common confusion
- Counting partially done items or using velocity as a productivity target.
8.4 Kanban in ScrumVisualizing flow and limiting work in progress within the Sprint.
- What it means
- Kanban is a flow-based method that visualizes work on a board, limits work in progress (WIP) and manages flow. Scrum Teams often use a Kanban board to make the Sprint Backlog visible.
- What to understand
- WIP limits reduce task switching and expose bottlenecks, which supports lean thinking. Flow metrics include cycle time, lead time, throughput and work item age. A Kanban board inside Scrum complements the events and artifacts; it does not replace Sprints, the Sprint Goal or the Retrospective. Pure Kanban teams do not use fixed iterations, which is a key difference from Scrum.
- How it shows up
- Questions ask what WIP limits achieve or whether a board can replace Scrum events.
- Common confusion
- Believing Kanban means abandoning Sprints while still calling the process Scrum.
8.5 Minimum viable product (MVP)The smallest product version that tests a key assumption.
- What it means
- A minimum viable product is the smallest version of a product that allows a team to collect the maximum amount of validated learning about customers with the least effort.
- What to understand
- An MVP tests a hypothesis about value with real users before larger investment. It supports empiricism and the Product Owner's accountability for maximizing value. MVP is not the same as a Sprint's Increment, though an Increment may serve as one; nor is it a low-quality prototype, since what is released must still meet the Definition of Done. A related idea, the minimum marketable product, is the smallest version that can be sold.
- How it shows up
- Expect definition items and questions about why a Product Owner would release an MVP early.
- Common confusion
- Treating an MVP as an excuse to skip quality or as the first full release.
8.6 Scrum of ScrumsA coordination practice for several Scrum Teams on one product.
- What it means
- A Scrum of Scrums is a meeting where representatives from several Scrum Teams working on the same product coordinate dependencies, integration issues and impediments that cross team boundaries.
- What to understand
- It is a complementary practice, not a Scrum Guide event. Representatives are usually Developers who can speak to technical dependencies, though Scrum Masters often facilitate. The 2020 Guide's rules for multiple teams still apply: one Product Goal, one Product Backlog, one Product Owner and a shared Definition of Done. Larger scaling frameworks exist, but the SMPC syllabus does not cover them; CertiProf addresses scaling in its separate Scaled Scrum certificate.
- How it shows up
- Questions ask what a Scrum of Scrums is for or whether it is a required event.
- Common confusion
- Assuming SAFe, LeSS or Scrum@Scale content is tested on the SMPC.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
INVEST
Independent, Negotiable, Valuable, Estimable, Small, Testable.
- Remember
- A quality checklist for stories.
- Tested as
- Letter recall items.
- Trap
- Reading E as Efficient.
-
User story format
As a user, I want a goal so that a reason.
- Remember
- Optional; not required by Scrum.
- Tested as
- Optional-or-required questions.
- Trap
- Calling stories a Scrum artifact.
-
Acceptance criteria
Conditions one story must meet to satisfy the user.
- Remember
- Differ from the Definition of Done.
- Tested as
- Quality questions.
- Trap
- Merging the two concepts.
-
Planning Poker
Simultaneous card reveal, discussion and re-vote.
- Remember
- Avoids anchoring.
- Tested as
- Mechanics questions.
- Trap
- Letting the senior Developer decide.
-
Story points
Relative measure of effort, complexity and uncertainty.
- Remember
- Not hours.
- Tested as
- Estimation questions.
- Trap
- Converting points to days.
-
Velocity
Done work per Sprint for one team.
- Remember
- Forecasting aid only.
- Tested as
- Misuse scenarios.
- Trap
- Comparing teams by velocity.
-
Burndown chart
Remaining work over time.
- Remember
- Optional practice, not an artifact.
- Tested as
- Tracking questions.
- Trap
- Listing it among Scrum artifacts.
-
WIP limit
Cap on items in a workflow stage.
- Remember
- Improves flow and exposes bottlenecks.
- Tested as
- Kanban questions.
- Trap
- Raising limits to look busy.
-
MVP
Smallest product that yields validated learning.
- Remember
- Released items still meet the Definition of Done.
- Tested as
- Definition and value questions.
- Trap
- Treating it as low quality.
-
Scrum of Scrums
Cross-team coordination meeting.
- Remember
- Not a Scrum Guide event.
- Tested as
- Multi-team scenarios.
- Trap
- Calling it mandatory.
-
Epic
A large story split during refinement.
- Remember
- Must be broken down to fit a Sprint.
- Tested as
- Readiness questions.
- Trap
- Pulling an epic straight into a Sprint.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Scrum vs. Kanban
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Scrum | Fixed-length Sprints with defined accountabilities | Cadence-based delivery and events | Dropping Sprints and still calling it Scrum |
| Kanban | Continuous flow with WIP limits | No required iterations or roles | Thinking it forbids planning |
| Kanban inside Scrum | Board and WIP limits within Sprints | Complements, does not replace, the events | Using it to skip the Retrospective |
Acceptance criteria vs. Definition of Done
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Acceptance criteria | Conditions for one backlog item | Item-specific, written with the Product Owner | Applying them to every item |
| Definition of Done | Quality standard for the Increment | Applies to all work | Replacing it with per-story criteria |
Estimation units
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Story points | Relative size including complexity and uncertainty | Team-specific scale | Comparing across teams |
| Hours | Absolute time estimate | Easy to misuse as a commitment | Thinking Scrum requires hours |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Velocity league table
- What candidates pick
- Ranking teams by velocity.
- Why it looks right
- Numbers look objective.
- Why it's wrong
- Velocity uses each team's own relative scale, so cross-team comparison is meaningless and encourages inflated estimates.
Clue to watch for A manager comparing teams.
-
Counting partial work
- What candidates pick
- Adding points for nearly finished items.
- Why it looks right
- The effort was spent.
- Why it's wrong
- Only items meeting the Definition of Done count toward velocity.
Clue to watch for Phrases like 80% complete.
-
Product Owner estimates
- What candidates pick
- The Product Owner assigning points to save time.
- Why it looks right
- They wrote the item.
- Why it's wrong
- Sizing belongs to the Developers who will do the work.
Clue to watch for Who estimates questions.
-
Kanban replaces Sprints
- What candidates pick
- Switching to continuous flow but keeping the Scrum label.
- Why it looks right
- Flow looks more efficient.
- Why it's wrong
- Kanban practices can complement Scrum, but removing Sprints means the process is no longer Scrum.
Clue to watch for A team dropping its Sprint cadence.
-
Scaling framework in SMPC
- What candidates pick
- Choosing an answer that requires SAFe or LeSS knowledge.
- Why it looks right
- Many Scrum Masters work in scaled settings.
- Why it's wrong
- The SMPC syllabus covers Scrum of Scrums at most; scaling frameworks belong to separate certifications.
Clue to watch for Options naming release trains or LeSS Huge.
Answer framework
Use these steps when a question involves a complementary practice rather than a core Scrum rule.
- Decide whether the practice is part of Scrum's core or a complementary technique such as stories, points, burn charts, Kanban, MVP or Scrum of Scrums.
- State the practice's real purpose, for example avoiding anchoring in Planning Poker or exposing bottlenecks with a work-in-progress limit.
- Check who should use or own it: Developers estimate and track their own work, and the Product Owner uses forecasts for product decisions.
- Reject any use that turns a team-specific measure into a cross-team comparison, a performance target or an excuse to lower quality.
- Confirm that the practice does not replace an accountability, event, artifact or commitment, because that would mean the process is no longer Scrum.
Practice question
Want more like this? The SMPC practice test has questions for every domain.
Checklist
0 of 12
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Because this area comes mostly from outside the Scrum Guide, use your course material or the Agile Glossary as the main source, and keep the Scrum Guide nearby to check that no practice contradicts it. Make one card per practice with three lines: what it is, what it is for, and how it is commonly misused.
Focus first on estimation and velocity, which generate the most scenario questions. Run a small Planning Poker session with friends or colleagues on everyday tasks to feel how simultaneous reveals change the discussion. Then rehearse why velocity is a team planning aid and never a comparison score.
Next, learn INVEST letter by letter and the difference between acceptance criteria and the Definition of Done. Finish with Kanban flow concepts, the MVP definition and Scrum of Scrums. Do not spend time on SAFe, LeSS or Scrum@Scale for this exam; CertiProf covers scaling in a separate credential and the SMPC syllabus does not include those frameworks.
FAQ
What share of SMPC questions come from Advanced Scrum Concepts?
CertiProf does not publish a share for Advanced Scrum Concepts. Most of it sits outside the Scrum Guide, so this guide estimates only about three of the 40 questions as an editorial planning figure.
Does the SMPC test SAFe, LeSS or Scrum@Scale?
No. CertiProf's SMPC pages and partner syllabi do not list scaling frameworks. Scrum of Scrums appears in some outlines, and broader scaling is covered by CertiProf's separate Scaled Scrum certificate.
Are user stories required in Scrum?
No. They are a popular way to write Product Backlog items, but the Scrum Guide does not prescribe any format.
What does INVEST stand for?
It stands for Independent, Negotiable, Valuable, Estimable, Small and Testable, a checklist for well-formed user stories.
Can velocity be used to compare teams?
No. Each team estimates on its own relative scale, so velocity is only meaningful for that team's forecasting.
Is a Scrum of Scrums a Scrum event?
No. It is a complementary coordination practice for multiple teams; the Scrum Guide defines only five events.
Other Agile & Scrum certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 8 knowledge
Use a short SMPC quiz on INVEST, Planning Poker, velocity and Kanban to separate optional practices from core Scrum rules.