ASM Agile Scrum Master Exam Topics and Questions

This topic sets the conceptual floor for everything else on the exam. Before the exam tests your Scrum mechanics, it checks whether you understand why Agile exists at all. The trap here is treating this as background reading you can skim. The questions are precise about how Agile achieves predictability alongside flexibility, and they expect you to tell frameworks apart rather than lump them together.

– The Agile mindset and what it actually delivers

The exam is not interested in a recitation of the Agile Manifesto. What it wants is an understanding of the reasoning behind iterative delivery: why short cycles produce more predictable outcomes than long-range plans, and how continuous improvement is built into the rhythm of work rather than bolted on at the end. Predictability and flexibility are often presented as opposites, but Agile achieves both by limiting the scope of each commitment. Knowing how to explain that trade-off in concrete terms is what this section rewards. Continuous improvement specifically means defined inspect-and-adapt moments, not a general attitude of trying harder. If you cannot describe what triggers a team to change its process, you will lose marks on scenario items that seem to be about something else entirely.

– Telling the frameworks apart

Crystal, XP, DSDM, LeSS, SAFe, and Kanban each appear in the syllabus by name, and the exam expects you to differentiate them, not describe them at length. The useful distinction for each one is the problem it was designed to solve and the context it fits best. XP is engineering-discipline-heavy; Kanban is flow-based and makes no commitments to iterations; DSDM is contract-friendly and governance-heavy; LeSS and SAFe both address scaling but with very different structural assumptions; Crystal scales by team size and project risk. You do not need deep expertise in any of them. You do need to know enough to rule out the wrong one when a scenario describes a specific organisational constraint. One or two distinguishing facts per framework is enough to answer these items correctly.

How Agile Way of Thinking is tested

At 10% of the exam, this topic contributes a small but non-trivial share of marks. Items here tend to be conceptual: a short scenario followed by a question about which principle applies or which framework fits. The demand is discrimination, not recall. Candidates who have memorised definitions without understanding the reasoning behind them will find that two or three options look equally valid. The items reward the ability to connect a stated business constraint to the right Agile response. Where candidates lose marks most often is on the framework-differentiation items. Reading the scenario too quickly and defaulting to Scrum when the context actually describes a Kanban or SAFe environment is a common error. The continuous-improvement items are a second trap: candidates who treat improvement as an attitude rather than a structured practice tend to select options that sound reasonable but describe ad hoc behaviour rather than a defined inspect-and-adapt cycle.

From the mindset layer, the exam moves to the most heavily weighted topic: what the Scrum Master actually does. At 28%, this is where the exam is won or lost. The questions are scenario-based and deliberately uncomfortable. They describe a team in difficulty and ask what the Scrum Master should do next. Knowing the theory is necessary but not sufficient. You need to know how the role is bounded, because the exam regularly tests where the Scrum Master's accountability ends.

– The scope of the Scrum Master role

The Scrum Master is accountable for the effectiveness of the Scrum framework, not for the product and not for the team's technical decisions. That boundary is the single most tested idea in this topic. Items will place you in a scenario where acting outside that boundary looks helpful, and the exam rewards staying within it. The specific tasks that belong to the Scrum Master include facilitating Scrum events, removing impediments that the team cannot remove themselves, and coaching the team on self-management. The word 'coaching' is precise here: a Scrum Master coaches rather than directs, and items will distinguish between those two modes. Knowing which tools support facilitation, such as visual management boards and retrospective formats, matters because the exam asks about them in the context of a specific team problem, not in the abstract.

– Facilitating, coaching, and clearing the path

Roadblock removal is a practical skill the exam tests through scenario questions. The key distinction is between an impediment the team can address on their own and one that requires the Scrum Master to act outside the team. Candidates who default to the Scrum Master solving everything will pick the wrong option repeatedly. Coaching and training the team means building capability over time, not providing answers in the moment. Items in this area often describe a Scrum Master who jumps in too quickly, and the stronger option is the one that preserves the team's ability to solve problems themselves. This is a pattern worth internalising before the exam.

– Accountabilities across the whole Scrum framework

The Scrum Guide defines three accountabilities: Scrum Master, Product Owner, and Developers. The exam expects you to know all three well enough to spot when a scenario has placed a responsibility in the wrong hands. Product Owners own the backlog and the product goal; Developers own the sprint backlog and the plan for the sprint; the Scrum Master owns neither of those things but is accountable for everyone understanding the framework. Confusion between the Product Owner's backlog authority and the Scrum Master's facilitation role is one of the most reliable sources of wrong answers in this topic. Items will describe a situation and ask who should act. The answer turns on which accountability is at stake, not on who is most convenient or most senior.

How Scrum Master accountability is tested

This topic accounts for more than a quarter of the exam, and almost every item is a scenario. You will read a description of a team situation and choose the most appropriate Scrum Master response. The items are written to make boundary violations look reasonable. An option that has the Scrum Master taking over a problem the team should own will be worded to sound decisive and helpful. Items reward the response that stays within the Scrum Master's accountability and builds team capability rather than replacing it. The second major trap is confusing the three accountabilities under pressure. When a scenario involves a backlog dispute or a sprint goal conflict, candidates who have not drawn a clean line between Product Owner authority and Scrum Master facilitation will lose marks consistently. Work through as many scenario items as you can find in this area before the exam, because pattern recognition across different situations is what the weight of this topic demands.

This is the largest topic on the exam by a clear margin. It covers the practical mechanics of running a Scrum team from backlog to delivery: writing work items, estimating them, planning sprints, tracking progress, and keeping stakeholders informed. The breadth is real. Candidates who are strong on Scrum theory but have not worked with backlogs, burn-down charts, or velocity in practice will find multiple sub-areas where their knowledge has gaps.

– Backlogs, user stories, and the definition of done

The product backlog and sprint backlog serve different purposes, and the exam tests whether you know which rules apply to each. Product backlog items can be large and loosely defined; sprint backlog items must be small enough to complete within the sprint. User stories are the most common format for product backlog items, and the exam expects you to know what makes one well-written: a clear user, a clear need, and a clear reason, with acceptance criteria that are testable. The definition of done is separate from acceptance criteria, and that distinction matters. The definition of done is a shared standard for what 'complete' means for any increment; acceptance criteria are specific to a single item. Confusing the two is a reliable source of lost marks. Adding items to the backlog is the Product Owner's authority, but the Scrum Master facilitates the process of refinement.

– Planning at every level

The exam covers planning at three levels: portfolio, product roadmap, and sprint. Portfolio and roadmap planning appear in the syllabus because the Scrum Master needs to understand how sprint-level decisions connect to longer-horizon commitments. Sprint planning has specific accountabilities: the Product Owner brings the goal and the priority order; the Developers commit to what they can deliver; the Scrum Master facilitates the event and ensures it stays within its timebox. Items in this area test whether you know who does what inside sprint planning, not just that sprint planning happens. A Scrum Master who directs the Developers' capacity estimates or overrides the Product Owner's priorities is the wrong option, even when the scenario makes it look efficient.

– Estimation techniques and where they go wrong

Story points, ideal hours, and ideal days are three different estimation units, and the exam expects you to understand what each one measures and when each one misleads. Velocity is derived from story points over completed sprints and is used for forecasting, not for setting targets. The most common estimation errors tested are anchoring (one person's estimate pulling everyone else's), using velocity as a performance metric rather than a planning tool, and treating estimates as commitments. Items will describe an estimation session and ask you to identify what went wrong. The answer usually turns on one of those three failure modes. Recognising them in a scenario description rather than in a textbook definition is the skill the exam is assessing.

– Tracking progress and managing issues

Information radiators make progress visible to the whole team and to stakeholders without requiring a meeting. The burn-down chart is the most commonly tested: candidates need to know how to read one, what a flat line or an upward trend indicates, and what the Scrum Master's response should be. Velocity tracking over multiple sprints reveals patterns that a single sprint cannot. Impediments that affect progress need to be identified, categorised by whether they are internal or external to the team, and acted on at the right level. Issues and bugs have their own management path: they enter the backlog, get prioritised, and are communicated to stakeholders in a way that is transparent without being alarmist. Items in this area test the interpretation step, not just the mechanics.

How Agile Estimating, Planning, Monitoring and Control is tested

At 33%, this topic will determine your result more than any other. The items spread across all four sub-areas, so a gap in any one of them shows up in your score. Estimation items tend to be scenario-based: a team is doing something specific and you identify the error or recommend the next step. Tracking items often present a described chart state and ask what it means or what action follows. Planning items test role boundaries the same way the Scrum Master accountability topic does, but now in the specific context of sprint planning events. The places candidates lose marks most often are estimation errors (confusing velocity as a target rather than a forecast) and definition-of-done versus acceptance-criteria confusion. Both appear regularly. Working under timed conditions matters here because the volume of reading in scenario items is higher than in the earlier topics, and running out of time is a real risk if you have not practised pacing.

After the mechanics of running a single Scrum team, the exam turns to what happens when that single-team model is not enough or not appropriate. This topic asks you to think about Scrum at scale, about the limits of Agile, and about the tooling that supports adoption. It is a smaller slice of the exam, but the scaling content in particular catches candidates who have only ever worked in or studied single-team Scrum.

– Scaling Scrum and the Nexus framework

When multiple Scrum teams work on the same product, the product backlog remains a single artefact. That is the starting point for all scaling questions: one backlog, multiple teams, one integrated increment. Nexus is the scaling framework the syllabus names explicitly, and the exam expects you to understand its core structure. Nexus adds an integration layer between teams: a Nexus Integration Team that includes a Scrum Master, a Product Owner, and Developers whose job is to resolve cross-team dependencies and ensure the integrated increment meets the definition of done. Items on this sub-topic will describe a multi-team situation and ask how backlog management or integration should work. The answer almost always turns on whether the teams are treating the backlog as shared or as divided, and whether integration is happening continuously or only at the end.

– When Agile fits and when it does not, plus supporting tools

The exam does test the limits of Agile, and that is unusual enough to catch candidates off guard. Some project contexts are poor fits: highly regulated environments with fixed deliverables, contracts that prohibit iterative delivery, or domains where requirements are fully known and stable from the start. Knowing when Agile is the wrong choice is as examinable as knowing when it is the right one. Small team size is a genuine Agile advantage, and the exam asks you to explain why rather than just assert it: smaller teams have lower communication overhead, clearer accountability, and faster decision cycles. On tooling, the exam is not asking you to evaluate specific products. It is asking you to identify what category of support a given team problem needs, such as backlog management, dependency visualisation, or integration tracking, and to match it to the right kind of tool.

How Complex Projects is tested

At 12%, this topic is not where the exam is decided, but it is where well-prepared candidates pick up marks that others drop. Scaling items are the most distinctive: they describe a multi-team environment and test whether you apply single-team Scrum rules or scaling-specific ones. The trap is defaulting to standard Scrum answers when the scenario has explicitly introduced a second or third team. Nexus-specific roles and integration responsibilities are the details that separate the correct option from a plausible-sounding one. The suitability items reward a clear-eyed view of where Agile struggles, not an advocacy position. Candidates who have internalised Agile as always the right answer will pick the wrong option when the scenario describes a context where it genuinely is not. Tooling items are the most straightforward in this topic: they reward functional understanding of what tools are for, not product knowledge.

The final topic shifts from how Scrum works to how organisations get there. Transition is where theory meets organisational friction, and the exam reflects that. At 17%, this topic is substantial enough to matter. The questions are less about Scrum mechanics and more about change management, team structure, and cultural readiness. Candidates who have led or lived through an Agile transition will find this familiar; those who have not need to think carefully about where transitions fail.

– Managing the transition to Scrum

When an organisation moves to Scrum, some project management activities do not disappear. They transfer, and they transfer to specific accountabilities within Scrum. The Scrum Master takes on facilitation and impediment removal; the Product Owner takes on backlog management and stakeholder communication around the product. The exam tests whether you can map a traditional project management activity to its Scrum equivalent, and whether you know when something simply no longer fits. Transitions fail in predictable ways: teams that keep a project manager in the room who makes decisions the Developers should be making, Product Owners who defer backlog authority back to a committee, Scrum Masters who act as team leads. Identifying those failure modes in a scenario is the main demand of this sub-area. Resistance to change is a related item type: the exam expects a coaching response from the Scrum Master, not a directive one.

– Self-management, cross-functionality, and cultural readiness

Self-management means the Developers decide how to do the work, not just that they have some autonomy. The exam is precise about this: a team that waits for the Scrum Master to assign tasks is not self-managing, even if the Scrum Master is polite about it. Cross-functional means the team collectively holds all the skills needed to deliver a done increment without depending on people outside the team. Items in this area describe a team setup and ask whether it meets those definitions. The cultural changes required before Agile adoption are the hardest sub-topic to answer well because they are the least mechanical. The exam is looking for recognition that Agile requires a shift in how authority, failure, and experimentation are treated at an organisational level, not just a change in meeting structure or job titles. Candidates who frame adoption as a process change rather than a cultural one will find the options in this area poorly calibrated to their thinking.

How Adopting Agile is tested

Items in this topic are scenario-based and often describe a transition that is going wrong. The exam rewards diagnosis before prescription: identifying what the actual problem is in the scenario before selecting the action. Candidates who jump to a solution without reading the failure mode carefully will pick an option that addresses the symptom rather than the cause. Resistance to change items test the Scrum Master's coaching stance. The stronger option is almost always the one that surfaces the concern and addresses it through conversation rather than the one that overrides or escalates. Self-management items are precise: an option that gives the team more information or removes a structural barrier rewards better than one that gives the team a decision the Scrum Master makes on their behalf. Cultural readiness items are the broadest and the hardest to prepare for mechanically. Reading several transition scenarios before the exam, and practising the diagnosis step, is more effective than memorising a list of cultural prerequisites.