EXIN Agile Scrum Foundation key terms

A way of managing work in which decisions rest on observation of what actually happens rather than on detailed up-front prediction. It relies on transparency, inspection and adaptation, and suits complex work where requirements and techniques keep changing.

The state in which the process, its progress and its problems are visible to everyone responsible for the outcome. Without it, inspection produces misleading conclusions and adaptation becomes guesswork rather than a rational response.

Frequent examination of Scrum artifacts and progress toward agreed goals to detect unwanted variance. It must be done often enough to catch deviation early, but not so often that it disrupts the work being examined.

Adjusting the process or the product as soon as inspection shows that one or more aspects deviate beyond acceptable limits. The adjustment must happen quickly to limit further deviation and is enabled by the Scrum events.

A property of work where cause and effect are only clear in hindsight and where more planning cannot remove the uncertainty. Scrum is designed for this kind of work, in contrast to simple or merely complicated problems.

A 2001 statement of four values and twelve principles for software development, favouring individuals, working software, customer collaboration and response to change over their opposites. It is the historical foundation many agile frameworks, including Scrum, refer to.

The twelve guidelines accompanying the Agile Manifesto, covering early and continuous delivery, welcoming changing requirements, frequent delivery, self-organizing teams and regular reflection. They describe the mindset behind the practices rather than prescribing specific ceremonies.

Building a product in repeated cycles that each produce a usable increment, refining it based on feedback. It contrasts with delivering everything in one final release and makes learning possible before all requirements are fixed.

A lightweight framework in which a small team addresses complex problems adaptively while delivering valuable increments. It defines a small set of roles, events and artifacts with rules that bind them together rather than prescribing detailed techniques.

A small, cross-functional group consisting of one Product Owner, one Scrum Master and the Developers. It is self-managing, has no sub-teams or hierarchy, and collectively owns all work needed to deliver a valuable increment each Sprint.

The single person accountable for maximizing the value of the product resulting from the Scrum Team's work. This role owns and orders the Product Backlog, expresses items clearly and decides what to build next.

The person accountable for establishing Scrum as defined in the Scrum Guide and for the team's effectiveness. This role serves the team and the wider organization by coaching, removing impediments and fostering self-management rather than directing the work.

The members of the Scrum Team who create the usable increment each Sprint. They self-manage their work, turn backlog items into a product, and hold one another accountable for quality and for meeting the Sprint Goal.

A team that decides internally who does what, when and how, rather than receiving those decisions from a manager. In Scrum the team chooses how to do the work and how to collaborate, within the boundaries set by the framework and the Sprint Goal.

A style in which the person in a leadership position focuses on the needs and growth of the team, removing obstacles and enabling others to succeed. It describes how a Scrum Master supports the team rather than commanding it.

Helping people improve through questions, feedback and guided reflection rather than by giving instructions. A Scrum Master uses it to grow the team's capability and to help the organization adopt Scrum effectively.

A fixed-length period of one month or less in which the team produces a usable increment. A new Sprint starts immediately after the previous one and contains all the other Scrum events, giving the team a stable rhythm.

The event that opens a Sprint, in which the team agrees what can be delivered and how the work will be achieved. It produces the Sprint Goal, the selected backlog items and a plan for delivering them.

A short daily event for the Developers to inspect progress toward the Sprint Goal and adapt their plan for the next day's work. It is timeboxed, typically to fifteen minutes, and improves communication rather than reporting to a manager.

An event at the end of the Sprint where the team and stakeholders inspect the increment and discuss what to do next. It is a working session to gather feedback and adapt the Product Backlog, not a formal sign-off gate.

The closing event of a Sprint in which the team inspects how it worked and identifies improvements to apply in the next Sprint. It focuses on people, interactions, processes and tools rather than on the product itself.

A fixed maximum duration for an activity that is not extended when the work is unfinished. In Scrum every event is timeboxed, which creates regularity and forces focus on what matters most.

An emergent, ordered list of what is needed to improve the product, and the single source of work for the Scrum Team. Its items become more detailed as they move toward the top and are refined before a Sprint.

The set of Product Backlog items selected for a Sprint, together with the plan for delivering them and the Sprint Goal. It is a highly visible picture of the work the Developers consider necessary to meet the goal.

A concrete, usable step toward the Product Goal, produced by the team during a Sprint. It must meet the Definition of Done, and multiple increments may be created within a single Sprint.

A shared, formal description of the state an increment must reach for the team to call it complete. It makes quality expectations explicit and, when it is part of the organization's standards, all teams must follow it.

A long-term objective for the product that gives the team a target to plan against. It is described in the Product Backlog, and the team fulfils or abandons it before taking on the next one.

A single objective for a Sprint that gives the team focus and coherence, and that is committed to during Sprint Planning. It provides flexibility on the exact scope, since items may change as long as the goal is met.

A short, plain-language description of a feature told from the user's perspective, often in a who-what-why format. It is a placeholder for a conversation and is completed by acceptance criteria rather than by exhaustive detail.

The conditions a backlog item must satisfy to be accepted by the Product Owner. They clarify intent, support testing and help the team judge whether an item is truly finished.

A relative unit used to size backlog items by effort, complexity and uncertainty rather than by elapsed time. Because it is relative, points are not comparable across teams and should not be converted into hours.

A consensus technique in which team members privately choose a card showing a size estimate, reveal simultaneously, and discuss differences until agreement emerges. It reduces anchoring by opinion and surfaces differing assumptions about the work.

The amount of work a team completes per Sprint, measured in its chosen sizing unit. It is a planning aid derived from the team's own history, useful for forecasting, but it is not a performance target or a basis for comparing teams.

The ongoing activity of breaking down and clarifying Product Backlog items so they are ready for a future Sprint. It is not a fixed event; the team decides how and when to do it, often shortly before planning.

Forecasting which increments will be available at a future point, based on the ordered backlog and observed velocity. It is a rolling expectation rather than a commitment, and it is revised as new information appears.

A person or group with an interest in the product, such as customers, users, sponsors or operational colleagues. Stakeholders contribute feedback at the Sprint Review and inform priorities, while the Product Owner remains the single point of accountability.

An obstacle that blocks or slows the team's progress and that the team cannot resolve on its own. Removing or escalating such obstacles is a core part of the Scrum Master's service to the team.

A graph showing remaining work against time within a Sprint or release. It makes progress visible at a glance but depends on honest daily updates, so it should inform conversation rather than be used to pressure the team.