ASF EXIN Agile Scrum Foundation Exam Topics and Questions

This is where the exam establishes whether you understand Agile as a way of working, not just as a label. Ten percent of the marks sit here, and they tend to trip up candidates who have memorised Agile vocabulary without absorbing the reasoning behind it. The Manifesto's four values and twelve principles are fair game, but so are the distinctions between Agile frameworks. Know why Agile exists before you learn what it contains.

– Mindset, values and the Manifesto

The Agile Manifesto is short enough to memorise, but the exam does not reward memorisation alone. What matters is understanding the trade-offs each value describes: individuals and interactions are preferred over processes and tools, but processes still exist. Working software is valued over comprehensive documentation, but documentation is not banned. That asymmetry is the point. Items will ask you to identify which Manifesto value or principle applies in a given situation, so you need to be able to reason from the values outward to a scenario, not just recite them in order. Predictability and flexibility are often presented as opposites in traditional project thinking. Agile's claim is that short feedback loops give you both: you commit only to what you can see clearly, and you adapt as the picture changes. Being able to explain that mechanism, rather than just assert it, is what the exam rewards.

– Agile beyond Scrum

Scrum is the dominant framework on this exam, but the syllabus explicitly asks you to recognise other Agile methods and practices. Kanban, Extreme Programming, Lean, and SAFe each have a distinct character. You are not expected to be a practitioner of any of them, but you should be able to distinguish their core ideas from Scrum's. The exam will place a method name or practice in front of you and expect you to assign it correctly. Confusing Kanban's flow-based approach with Scrum's sprint-based rhythm, for example, is a common source of lost marks. Think of this sub-topic as a map: you need to know where each method sits relative to the others, even if you have only walked the Scrum territory in depth.

How Agile Way of Thinking is tested

At ten percent of the exam, this topic produces a small but meaningful cluster of items. They tend to be scenario-based: a team is behaving in a certain way, and you are asked whether that behaviour reflects Agile thinking. The trap is that many plausible-sounding options describe practices that look Agile but contradict a specific Manifesto value or principle. Items reward the ability to apply a value to an unfamiliar situation rather than recall a definition. A second pattern involves distinguishing Scrum from other Agile methods. The item will describe a practice, and you must place it correctly. Candidates lose marks here by treating all Agile methods as interchangeable. The other common mistake is misreading the predictability-versus-flexibility question: Agile does not sacrifice predictability, it achieves it differently. Items that hinge on that distinction reward candidates who understand the mechanism, not those who have only absorbed the marketing version of the idea.

More than half the exam lives here. If Agile Way of Thinking sets the context, Scrum Practices is where the marks are actually won or lost. The topic spans roles, events, backlogs, and goals, and the items within it are precise: a single misunderstood accountability or a blurred boundary between two events can cost you several questions at once. Broad familiarity is not enough. You need to know where each Scrum element begins, ends, and hands off to the next.

– Roles and accountabilities

Scrum has three accountabilities: Product Owner, Scrum Master, and Developers. The exam tests the boundaries between them with some consistency. The Product Owner owns the product backlog and the ordering of its items; that authority does not belong to the team or to any external stakeholder. The Scrum Master serves the team and the organisation by enabling Scrum, not by directing the work. The Developers are self-managing: they decide how to do the work, not just how much. The traditional project manager role is explicitly absent from Scrum, and the exam will present scenarios where someone is performing project-manager-like behaviour and ask you to assess it. Items reward recognising that this behaviour may be a Scrum anti-pattern, even when it looks efficient. Mixing up who holds which accountability is one of the most reliable ways to drop marks in this section.

– Events and timeboxes

Every Scrum event is timeboxed, and that constraint is not incidental: it forces decisions rather than deferring them. The Sprint is the container for all other events. The Daily Scrum is a planning event for the Developers, not a status report for the Scrum Master or Product Owner. The Sprint Review is an inspection of the increment and an opportunity to adapt the product backlog; it is not a sign-off ceremony. The Sprint Retrospective inspects the team's process and produces actionable improvements. The exam frequently tests whether candidates understand the purpose of each event rather than just its name. Confusing the Sprint Review with the Retrospective is a persistent error. Knowing which event produces which output, and who participates in each, keeps you on the right side of those items.

– Backlogs and backlog refinement

The product backlog is an ordered list, and ordering is the Product Owner's call. The sprint backlog is the Developers' plan for the sprint: it belongs to them. Refinement is an ongoing activity, not a single event, and it results in backlog items that are sufficiently understood and sized to be pulled into a sprint. Good user stories follow a recognisable structure and carry acceptance criteria that make done determinable. The exam will ask you to identify whether a given backlog item is well-formed, and it will ask you to distinguish product backlog from sprint backlog in terms of ownership and content. Understanding how items are ordered by value, risk, and dependency, rather than by date requested or requester seniority, is the kind of nuance that separates correct answers from attractive distractors.

– Goals and the Definition of Done

Scrum uses three goal constructs: the product goal, the sprint goal, and the Definition of Done. Each operates at a different horizon. The product goal is the long-term objective the team works toward; the sprint goal commits the team to a specific outcome within one sprint; the Definition of Done is the quality standard that every increment must meet before it can be released. The exam treats these as distinct and testable. A common mistake is treating the Definition of Done as a checklist that varies by story: it applies to the whole increment and is non-negotiable within a sprint. Items reward understanding that the sprint goal gives the team flexibility in how they achieve it, while the Definition of Done gives stakeholders confidence that what is delivered is genuinely complete.

How Scrum Practices is tested

With 56 percent of the exam weight, this topic generates the majority of your items. The questions are scenario-driven: a situation is described, and you must identify which Scrum role, event, or artefact applies. The difficulty is that distractors are usually plausible. A Scrum Master who steps in to resolve a team conflict looks helpful; the item rewards recognising whether that behaviour serves or undermines self-management. Similarly, items about events often hinge on purpose rather than mechanics. Candidates who can name all five events but cannot articulate what each one is designed to produce will consistently choose the second-best option. The Definition of Done and the distinction between product and sprint backlog are reliably tested and reliably mishandled. Backlog ordering items reward understanding that value and risk drive sequencing, not arrival order. The single biggest mark-saver in this topic is precision: read each scenario for exactly which accountability or artefact is in play before committing to an answer.

After the depth of Scrum Practices, this topic narrows the focus to two concrete skills: planning a sprint and sizing the work inside it. Seventeen percent of the exam sits here, and the items are more calculation-adjacent than anywhere else on the paper. You will not be asked to do arithmetic under exam conditions, but you will need to understand what velocity means, why story points behave differently from hours, and what sprint planning is actually trying to produce. Candidates who treat estimation as a soft topic tend to lose marks they did not expect to.

– Sprint planning mechanics

Sprint planning answers two questions: what can be delivered this sprint, and how will the team do it? The Product Owner brings the ordered backlog and the sprint goal candidate; the Developers assess what they can realistically take on given their velocity and capacity. Sprint duration is a decision the team makes, not a default setting. Longer sprints reduce planning overhead but increase the risk of delivering something that has drifted from stakeholder expectations. Shorter sprints tighten the feedback loop but demand more ceremony relative to delivery time. The exam tests whether you understand those trade-offs rather than expecting you to prescribe a single correct duration. Items reward the ability to connect sprint length to the nature of the work and the team's need for feedback.

– Estimation techniques and units

Planning poker, triangulation, and affinity estimation are the three techniques the syllabus names. Each is a way of reaching a shared team estimate without anchoring on the first number someone says aloud. The exam will ask you to recognise what each technique involves and when it is appropriate. Story points, ideal days, and ideal hours are the units that estimation produces. Story points are relative and team-specific: a three-point story for one team may represent very different effort from a three-point story for another. Ideal days and ideal hours assume uninterrupted focus time, which almost never exists, so they require adjustment. Velocity is the team's historical throughput in the units they use; it is observed, not set. Items reward understanding that velocity is a planning input, not a performance target, and that it is only meaningful within the team that generated it.

How Scrum Planning and Estimation is tested

At seventeen percent, this topic is the second-largest contributor to your score. Items split roughly between planning and estimation, with estimation carrying the subtler traps. The planning items tend to be scenario-based: a team is setting up a sprint or choosing a sprint length, and you must assess the decision. Items reward recognising the connection between sprint duration and risk exposure. The estimation items are where candidates most often lose marks. The most common error is treating velocity as a commitment or a benchmark rather than a historical average. A second error is conflating story points with time units: items that hinge on the relative, team-specific nature of story points will reliably catch candidates who have not fully made that distinction. Technique recognition items, covering planning poker, triangulation, and affinity estimation, tend to be more straightforward, but only if you have spent time with all three. Skipping the less familiar techniques on the assumption they will not appear is a reliable way to drop marks.

Planning and estimation tell the team what to attempt. Monitoring tells them, and everyone around them, how the attempt is going. At ten percent of the exam, this topic is often underestimated: candidates assume it is purely visual and therefore straightforward. The items here test whether you understand why a given visualisation tool exists and what decisions it is meant to support, not just what it looks like. The distinction between different monitoring approaches is sharper than it first appears.

How Monitoring Scrum Projects is tested

Ten percent of the exam comes from this topic, and the items are almost always purpose-driven rather than definition-driven. A scenario will describe a team's situation and ask which monitoring approach or visualisation serves it best. Items reward understanding that information radiators exist to make progress visible to anyone who walks past, without requiring a meeting or a report. The Kanban board is the most frequently tested tool: candidates are expected to know how work flows across its columns and what a blocked item signals to the team. The common trap is treating all visualisation tools as equivalent. They are not: each one answers a different question about the work. Candidates who can only describe what a tool looks like, rather than what question it answers, will consistently choose the second-best option. The other mark-loss pattern is confusing monitoring with reporting: Scrum monitoring is continuous and team-owned, not periodic and manager-directed.

This final topic sits at seven percent of the exam, the smallest slice on the paper. Do not ignore it on that basis: a handful of items answered correctly can be the difference between a pass and a fail at the margin. The territory here is Scrum operating outside its default conditions: large and complex projects, distributed teams, and contract structures that have to accommodate iterative delivery. None of these require deep specialist knowledge, but each demands that you apply Scrum thinking to a less familiar context.

How Advanced Scrum Concepts is tested

Seven percent means a small number of items, but they carry real weight for candidates sitting close to the pass mark. The items here are recognition-based: a situation is described involving multiple teams, a virtual working arrangement, or a contracting challenge, and you must identify the Scrum-consistent response. Scaling items reward knowing that Scrum's core accountabilities and events remain intact when you scale; the complexity is in coordination, not in replacing the framework. Virtual team items reward recognising the communication and trust challenges that distance introduces, and how Scrum's inspect-and-adapt cadence addresses them. Contract items are the least intuitive for many candidates: traditional fixed-scope contracts conflict with Agile's iterative nature, and the exam tests whether you can identify why and what alternatives exist. The trap across all three areas is reaching for a solution that looks practical but abandons Scrum principles. Items reward staying inside the framework, even when the scenario makes that feel awkward.