EXIN Agile Scrum Master flashcards

EXIN Agile Scrum Master · Build recall with a focused review session.

41 cards. Read the term and the definition here. The deck at the top of this page is optional.

Empirical Process Control: Scrum's foundation: decisions are based on observation and experience rather than upfront prediction. It requires transparency of work and status, frequent inspection of artifacts, and adaptation when inspection reveals deviation.
Agile Manifesto Four Values: Individuals and interactions over processes and tools; working software over comprehensive documentation; customer collaboration over contract negotiation; responding to change over following a plan. The right-hand items still have value.
Five Scrum Values: Commitment, Focus, Openness, Respect, and Courage. They describe how the Scrum Team behaves toward goals, work, each other, and stakeholders, and they underpin trust, which makes empirical control possible.
Iterative versus Incremental: Iterative means repeating cycles to refine understanding and solution; incremental means delivering usable pieces that accumulate into a complete product. Scrum is both: each Sprint produces a done Increment while refining the Product Backlog.
When Scrum Fits: Scrum suits complex work where requirements and technology are not fully understood and emerge through experience. Predictive approaches fit better when scope is stable and the solution is well known.
Scrum Values versus Practices: Values are behavioral commitments that make the framework work; practices are concrete techniques a team chooses. Scrum mandates the framework elements but deliberately leaves engineering practices and tools to the team's judgment.
Product Owner Accountability: One person accountable for maximizing product value by ordering the Product Backlog and making its items clear. The Product Owner may delegate work but never the accountability, and is never a committee.
Scrum Master Accountability: Accountable for the Scrum Team's effectiveness: coaching the team, ensuring Scrum is understood and enacted, removing impediments, and helping the organization adopt Scrum. The role carries no command authority over Developers.
Developers Accountability: Developers create the Increment each Sprint. They own the Sprint Backlog, self-manage who does what and how, hold each other accountable as professionals, and help define and uphold the Definition of Done.
Self-Managing Scrum Team: A team of ten or fewer people, cross-functional in skills, that decides internally how to convert backlog items into value. No sub-teams or hierarchy exist; specialist titles do not create authority over others.
Scrum Master Servant Leadership: The Scrum Master leads by serving: coaching rather than directing, removing impediments, facilitating events, and helping the team and organization improve. The Scrum Master does not assign tasks or approve work.
Combining PO and SM Roles: Holding both accountabilities in one person creates a conflict between value focus and process coaching, and removes a check. It may work briefly in a very small setting but is not recommended.
Three Scrum Artifacts: Product Backlog, Sprint Backlog, and Increment. Each has a commitment: the Product Goal for the Product Backlog, the Sprint Goal for the Sprint Backlog, and the Definition of Done for the Increment.
Sprint Timebox: A Sprint is fixed at one month or less. Length stays constant to build a rhythm; scope may be clarified with the Product Owner but no change may endanger the Sprint Goal, and quality never decreases.
Sprint Planning Output: Sprint Planning answers why the Sprint is valuable, what can be done, and how. Its output is the Sprint Goal plus the Sprint Backlog, which the Developers own and update during the Sprint.
Daily Scrum Purpose: A 15-minute event for Developers to inspect progress toward the Sprint Goal and adapt the Sprint Backlog. It is not a status report; the Scrum Master and Product Owner attend only if they help.
Sprint Review Purpose: A working session, timeboxed to four hours for a one-month Sprint, where the Scrum Team and stakeholders inspect the Increment and adapt the Product Backlog. It is not a gate or a one-way demo.
Sprint Retrospective Purpose: A timeboxed event, at most three hours for a one-month Sprint, where the team inspects how the Sprint went and identifies improvements. It closes the Sprint and should yield at least one actionable change.
Definition of Done: A formal description of the quality state required for an Increment. Work that does not meet it cannot be released or counted in the Increment and returns to the Product Backlog for later.
Event Timebox Rule: Every Scrum event has a maximum duration and may be shortened but never extended. Sprint Planning is at most eight hours, Daily Scrum fifteen minutes, Review four hours, and Retrospective three hours for a one-month Sprint.
Backlog Refinement: Ongoing activity of breaking down and clarifying Product Backlog items for future Sprints. It is not a formal Scrum event and typically consumes no more than ten percent of team capacity.
Sprint Goal: A single objective for the Sprint that gives the team focus and coherence. It is created during Sprint Planning and may be adjusted if the work turns out differently, but it guides what the team commits to.
Coaching Stance: Ask before telling. The Scrum Master uses open questions so the team reaches its own conclusions and keeps ownership. Advice is offered when the team lacks information, not as a default.
Diverge Then Converge: A facilitation pattern: first generate options broadly using brainstorming or silent writing, then narrow with dot voting or fist of five. Skipping divergence narrows too early; skipping convergence leaves no decision.
Retrospective Five Stages: Set the stage, gather data, generate insights, decide what to do, and close. The decision stage converts insight into owned actions; omitting it leaves the team with observations but no change.
Impediment Escalation Rule: The team resolves impediments within its authority; the Scrum Master escalates only those beyond it and tracks them visibly. Escalating everything creates dependency; escalating nothing leaves blockers unresolved.
Fist of Five: A quick convergence technique where each participant shows zero to five fingers to signal support for a proposal. It surfaces disagreement fast and lets the facilitator probe low scores before deciding.
Coaching Effectiveness Signals: Observable evidence the Scrum Master is effective: events start and end on time, Developers self-select work, impediments trend down, and the team raises problems openly rather than hiding them.
Nexus Scaling Framework: A scaling approach for roughly three to nine Scrum Teams working on one product. It adds a Nexus Integration Team accountable for integration and continuous delivery of a single integrated Increment.
LeSS Scaling Framework: Large-Scale Scrum keeps one Product Owner, one Product Backlog, and one Definition of Done across multiple teams, extending single-team Scrum rather than layering new processes on top of it.
PI Planning: A SAFe synchronization event where teams on a program align on objectives for a planning interval. It addresses cross-team dependencies and is the main coordination mechanism in that framework.
Velocity Misuse: Velocity is a planning aid for one team's forecast. Comparing velocity across teams or using it as a productivity target is invalid because estimation scales and item sizes differ between teams.
Scaling Prerequisite: Fix single-team basics before scaling. Scaling amplifies existing dysfunction: unclear ownership, weak Definition of Done, and hidden dependencies multiply rather than resolve across teams.
Agile Adoption Stages: Awareness, pilot, expansion, and institutionalization. Each stage requires different sponsorship and metrics; skipping the pilot and mandating adoption organization-wide usually produces compliance without behavior change.
Funding Persistent Teams: Instead of approving one-off project business cases, the organization funds stable teams and reviews value at fixed intervals. This reduces handoffs, preserves knowledge, and aligns budgeting with product flow.
Agile in Name Only: An antipattern where ceremonies exist but behavior does not change: daily standups as status reports, Scrum Master as project manager, and Product Owner as a proxy for a distant decision committee.
Outcomes over Output: Measure customer value, cycle time, and quality signals rather than story points completed or hours logged. Output metrics reward activity; outcome metrics reveal whether the product actually improved.
Psychological Safety for Improvement: Continuous improvement requires people to surface problems without punishment. If leadership penalizes bad news, teams hide impediments, inspection reveals nothing real, and adaptation stops.
Value Stream Organization: Structure teams around the flow that delivers customer value rather than around technical components. Value-stream teams reduce handoffs and dependencies compared with component teams that must integrate across boundaries.
Improvement Experiment Discipline: Limit Retrospective output to one or two experiments per Sprint, each with an owner and a review date. Many unowned actions dilute effort; few owned ones produce measurable change.
Dependency Visibility: Cross-team dependencies add delay, so make them visible on a board and minimize their number. Each dependency implies a coordination meeting and a waiting state in the flow of work.