Scrum & Agile Vocabulary

Sprint Retrospective: a Scrum ceremony held after the Sprint Review and before the next Sprint Planning. Purpose: the team inspects itself — processes, tools, interactions, practices — and creates an actionable improvement plan. Standard question framework: "What went well? What didn't go well? What will we improve?" Retrospective format vocabulary: Start / Stop / Continue — what to add, remove, or keep. 4Ls — Liked, Learned, Lacked, Longed For. Mad / Sad / Glad — emotional retrospective. Sailboat / Speedboat — wind (helps), anchors (blocks), rocks (risks). Dot voting — each person places a limited number of dots on items they find most important. Action items — specific, owned improvements the team commits to. Timebox — retrospective is timeboxed to 3 hours for a 1-month Sprint (shorter for shorter Sprints). Scrum Guide principle: "The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done." In conversation: "Our retros were too polite — we switched to anonymous sticky notes and the real issues started surfacing."

Velocity: the sum of story points of all completed (Done) user stories in a sprint. Used as a forecasting tool — "if our velocity is 40 points, we shouldn't plan more than ~40 points next sprint." Estimation and planning vocabulary: Story points — a relative measure of effort, complexity, and uncertainty. Not tied to hours. Planning Poker — estimation technique using modified Fibonacci cards (1, 2, 3, 5, 8, 13, 20, 40, 100); team votes simultaneously to avoid anchoring. T-shirt sizing — XS, S, M, L, XL estimates; quick relative sizing for a backlog. Relative estimation — estimating one story relative to another ("this is twice as complex as that one"). Capacity — total available person-hours in a sprint (accounting for meetings, leave, etc.); different from velocity. Sprint burndown chart — chart showing remaining story points day-by-day during a sprint; ideal line vs actual. Release burnup chart — shows progress toward a release goal over multiple sprints. Common mistake: treating story points as hours leads to micro-management. In conversation: "After three sprints we had stable velocity at 38 points — we stopped saying yes to last-minute additions that would push us to 55."

Definition of Done (DoD): a formal list of criteria that every product increment must satisfy to be considered "Done." It creates a shared standard across the team and ensures quality consistency. DoD vs Acceptance Criteria distinction (crucial!): Definition of Done — applies to ALL stories; team-level quality standard (e.g., "code reviewed, tests passing, docs updated"). Acceptance Criteria — specific to ONE story; written by the Product Owner; describes the feature's expected behaviour ("given X, when Y, then Z"). Other definitions vocabulary: Definition of Ready (DoR) — criteria that must be met before a story enters a sprint: estimated, acceptance criteria written, dependencies identified, feasible within one sprint. INVEST criteria for user stories: Independent, Negotiable, Valuable, Estimable, Small, Testable. Done Increment — the Scrum term for the potentially shippable product increment at the end of a sprint. Common Scrum mistake: having separate DoDs per team in a scaled environment; the Scrum Guide recommends a single DoD at the product level. In conversation: "We added 'security scan passing' to our DoD after an incident — now it's baked in, not an optional afterthought."

Servant-leader: a leadership philosophy central to the Scrum Master role. The SM leads by serving — removing obstacles, coaching, facilitating, and enabling the team to self-organise rather than directing their work. Scrum Master responsibilities vocabulary: Impediment removal — identifying and eliminating blockers (technical, organisational, procedural) that slow the team. Shield the team — protecting the sprint from scope changes, interruptions, and external requests mid-sprint. Facilitation — guiding ceremonies (Daily Scrum, Planning, Review, Retro) without dominating them. Coaching — teaching Agile/Scrum principles over time; SM pushes team toward self-management. Supporting the PO — helping with backlog refinement, helping clarify which techniques are effective. Self-organising team — the team decides how best to accomplish the sprint goal without being told how. Scrum values: Commitment, Focus, Openness, Respect, Courage. Scaled Scrum roles: RTE (Release Train Engineer) — SM equivalent in SAFe; Chapter Lead — in Spotify model. In conversation: "The team became much more self-sufficient once I stopped answering 'who does what' — I just asked 'who can take this?'."

Backlog Refinement (formerly "Backlog Grooming"): an ongoing process where the team collaborates with the PO to review and improve backlog items — adding detail, removing obsolete items, splitting epics into stories, and estimating. It ensures the top items are Ready for sprint planning. Backlog vocabulary: Epic — a large user story that must be split into smaller stories before sprint work. User Story — a feature described from the end user's perspective: "As a [user], I want [action] so that [benefit]." Task — a sub-unit of work within a user story (e.g., "Write unit tests", "Update API docs"). Backlog grooming — older term for backlog refinement; still widely used in practice. Priority — the PO controls priority; highest priority items should be most detailed. DEEP backlog — Detailed appropriately, Estimated, Emergent (can change), Prioritised. spike — a time-boxed research/investigation task to reduce uncertainty about a story or technical approach. Icebox — items deprioritised indefinitely; often archived. Recommended time: Scrum Guide suggests no more than 10% of team capacity on refinement. In conversation: "We started doing 30-minute refinement sessions twice a week — sprint planning went from 4 hours to 90 minutes."

This scenario illustrates a crucial part of Agile. Adding a new item to the backlog is just the beginning; it needs refinement – which includes defining acceptance criteria and assessing its fit within the team's capacity. This process ensures clarity and prevents wasted effort.

This question tests understanding of feedback within a code review context. David isn't just offering an opinion; he's making a concrete request for improved testing practices. Option A misinterprets this as a general lack of testing while options C and D conflate opinion with actionable instruction.

This exercise focuses on Agile terminology within a common communication channel. 'Two-week sprints' is a core concept in Scrum. The question tests whether the user understands that this refers to the standard sprint duration and not an indication of desired outcomes.

This scenario assesses understanding of standup best practices. The key here is that John's statement reflects Agile principles – transparency (sharing what he's working on) and self-organization (identifying the need for further investigation). Option A misunderstands the purpose of a standup.

This question focuses on effective communication in a PR context. A good PR description should clearly state *why* the change is being made (security and compliance) and link it back to a larger epic. This ensures alignment between development and product goals.

This question tests understanding of feedback within a code review context. David isn't just offering an opinion; he's making a concrete request for improved testing practices. Option A misinterprets this as a general lack of testing while options C and D conflate opinion with actionable instruction.

This exercise focuses on Agile terminology within a common communication channel. 'Two-week sprints' is a core concept in Scrum. The question tests whether the user understands that this refers to the standard sprint duration and not an indication of desired outcomes.

This scenario assesses understanding of standup best practices. The key here is that John's statement reflects Agile principles – transparency (sharing what he's working on) and self-organization (identifying the need for further investigation). Option A misunderstands the purpose of a standup.

This question focuses on effective communication in a PR context. A good PR description should clearly state *why* the change is being made (security and compliance) and link it back to a larger epic. This ensures alignment between development and product goals.

The Definition of Done is a crucial concept in Scrum. It defines when work is truly complete – it goes beyond just deployment; it encompasses testing, stakeholder approval and alignment with sprint objectives. The Product Owner is checking to ensure the team has followed this standard, not simply that something was built.

David's comment highlights the importance of *technical excellence* within Agile. Reducing redundancy (a key aspect of technical debt) directly supports maintainability, testability, and overall code quality – all core tenets of agile development practices. Addressing technical debt proactively is a common and valuable focus.

Maria is advocating for *iterative development* and *sprint efficiency*. Breaking down large epics into smaller user stories (typically around 8 story points) allows the team to deliver value incrementally, providing more frequent feedback loops and reducing risk. This aligns with Agile's focus on adaptability.

Sarah's PR description highlights her role as a *Product Owner*. Her responsibility is to gather user needs, translate them into product requirements (user stories), and prioritize those requirements for the Development Team. She defines *what* needs to be built, not *how*.

John's statement demonstrates *active problem-solving* – a core Agile value. He's identifying a performance issue, investigating its cause (indexing), and proactively seeking solutions within the constraints of the sprint. This aligns with the team's self-organizing nature.