EXIN Agile Scrum Master key terms

A management approach built on transparency, inspection and adaptation, used when work is too complex to plan fully in advance. Decisions rely on observed results rather than prediction, and each cycle of work updates the plan.

The first pillar of empiricism: everyone involved shares a common, visible understanding of the work, its status and the artefacts. Without it, inspection misleads and adaptation makes things worse.

The second pillar of empiricism: frequent, purposeful examination of artefacts and progress against a goal. Inspection is only useful when the work is genuinely transparent and the inspector has the skill to interpret it.

The third pillar of empiricism: adjusting process, product or plan as soon as inspection reveals deviation or a better option. Deferring adjustment increases risk and reduces the value delivered.

A shared, explicit checklist describing what it means for an Increment to be complete. It makes transparency possible, prevents undone work from counting as finished, and is applied to every Product Backlog item.

A long-term, measurable objective describing the future state of the product that the Scrum Team works toward. It gives the Product Backlog a focus and lives in the backlog as a commitment.

A single objective for one Sprint that gives the Development Team a shared focus and justifies the Sprint's contents. It is agreed during Sprint Planning and may be renegotiated with the Product Owner as learning occurs.

An ordered, emergent list of everything that could improve the product, owned by the Product Owner. Items are refined and reordered continuously, with the most valuable and clearest at the top for near-term delivery.

The set of Product Backlog items selected for a Sprint, together with the plan for delivering them and the Sprint Goal. It is a living plan updated daily by the Development Team as work progresses.

The sum of the completed, usable Product Backlog items produced during a Sprint. Each Increment must meet the Definition of Done and be potentially releasable, adding to all previous Increments.

The ongoing activity of breaking down, clarifying, estimating and reordering Product Backlog items so that upcoming work is ready. It is not a formal Scrum event but consumes a deliberate share of team capacity.

The single accountable role for maximising product value, owning and ordering the Product Backlog, and representing stakeholder needs. The Product Owner decides what to build and how success is measured, and may delegate work but not accountability.

The role accountable for the Scrum Team's effectiveness, teaching Scrum, removing impediments and coaching the team and organisation toward self-management. The Scrum Master is a servant leader, not a project manager or task assigner.

The group of professionals inside the Scrum Team who turn Product Backlog items into a usable Increment. They self-organise, hold all the skills needed to deliver, and are collectively accountable for the work of each Sprint.

The whole unit comprising the Product Owner, Scrum Master and Development Team, typically ten or fewer people. It is cross-functional and self-managing, with no sub-teams or hierarchy beyond the three accountabilities.

A leadership stance in which the Scrum Master serves the team's needs first, removing obstacles, protecting focus and enabling growth, rather than directing work. Authority is used to enable self-management, not to command.

A questioning, non-directive way of helping people find their own solutions and build capability over time. In Scrum it is a core Scrum Master behaviour, distinct from mentoring, teaching or telling.

Designing and guiding group interactions so that participants reach shared outcomes and decisions efficiently. A facilitator manages process, keeps the space safe for dissent and avoids imposing content on the group.

Anything blocking or slowing the team's progress that the team cannot resolve itself. The Scrum Master's job is to help surface impediments and drive their removal, escalating beyond the team where necessary.

The team's authority and responsibility to decide internally how to do the work and who does what, within agreed boundaries. It replaces external task assignment and is a precondition for real commitment.

A fixed-length iteration of one to four weeks in which a usable Increment is created. Its length is constant to build rhythm, and scope may be clarified with the Product Owner while the Sprint Goal stays stable.

The event that opens a Sprint, where the team agrees why the Sprint matters, what can be delivered and how. It produces the Sprint Goal and Sprint Backlog and is timeboxed to roughly eight hours for a one-month Sprint.

A fifteen-minute event for the Development Team, held at the same time and place each working day, to inspect progress toward the Sprint Goal and adapt the plan. It is not a status report to a manager.

A working session at the end of a Sprint where the team and stakeholders inspect the Increment against the Sprint Goal and adapt the Product Backlog. It is a collaboration to gather feedback, not a formal sign-off gate.

A timeboxed event after the Sprint Review where the team inspects how it worked and identifies improvements to adopt next Sprint. It closes the Sprint and produces at least one concrete, owned action.

A fixed maximum duration for an event or activity that is not extended; if the purpose is met early, the event ends early. Timeboxes create focus and make the cost of ceremony predictable.

A team-specific measure of how much backlog work is completed per Sprint, usually in story points. It supports forecasting and Sprint Planning but must never be used to compare teams or as a performance target.

A relative, unitless estimate of the size and complexity of a backlog item, independent of clock time. Relative sizing exposes uncertainty and supports shared understanding more than false precision.

A graph showing remaining work against time within a Sprint or release, used to make progress visible. It is a transparency tool for the team, not a compliance instrument for managers.

Anyone outside the Scrum Team with an interest in the product, such as customers, users, sponsors or support staff. Stakeholders contribute feedback at the Sprint Review and through the Product Owner, not by directing the team.

A physical or digital visualisation of the Sprint Backlog, often showing workflow columns and work in progress. It supports daily self-management and makes bottlenecks and blockers immediately visible.

A scaling technique in which representatives from several Scrum Teams meet regularly to coordinate dependencies and integration. It complements, but does not replace, each team's own Daily Scrum and backlog.

Applying Scrum across multiple teams working on one product, adding coordination structures and shared backlogs. Scaling frameworks are optional patterns; the underlying Scrum accountabilities and empiricism must remain intact.

The ongoing habit of making small, evidence-based changes to process and product rather than waiting for a large transformation. In Scrum it is driven mainly by the Sprint Retrospective and reinforced by the Scrum Master.

A Japanese term meaning change for the better, describing small incremental improvements made continuously by the people doing the work. It aligns closely with the improvement focus of the Sprint Retrospective.

A 2001 statement of four values and twelve principles for software development, prioritising individuals, working software, customer collaboration and response to change. It is the philosophical foundation beneath Scrum's practices.

Ending a Sprint early when its Sprint Goal becomes obsolete, a decision reserved to the Product Owner. Completed items are reviewed, incomplete ones return to the Product Backlog, and a new Sprint Planning follows.