Scrum — Cheat Sheet

Tags: scrum, agile, sprint, kanban, project-management, software-engineering

Level: intermediate

TL;DR: Scrum is an iterative Agile framework structured around fixed-length Sprints, 3 specific roles, 5 events, and 3 key artifacts with their commitments.

Key concepts

Scrum is an empirical process control framework based on transparency, inspection, and adaptation.

Product Owner maximizes product value and manages the prioritized Product Backlog.

Scrum Master serves as a servant-leader, removing impediments and coaching team processes.

Developers build cross-functional, self-organizing increments of usable product each Sprint.

Sprints are fixed-length iterations of one month or less, typically two weeks.

Sprint Planning defines what can be delivered and how that work will be achieved.

Daily Scrum is a 15-minute time-boxed event for Developers to synchronize progress and adjust the plan.

Sprint Review inspects the Increment with stakeholders and adapts the Product Backlog.

Sprint Retrospective inspects team collaboration, processes, and tools to identify actionable improvements.

Artifact commitments ensure focus: Product Goal for Backlog, Sprint Goal for Sprint Backlog, and Definition of Done for Increment.

Typical questions and ready answers

Q: How do you handle an urgent scope change requested in the middle of a Sprint?R: I assess the impact with the Product Owner; if it threatens the Sprint Goal, we negotiate deferring it to the next Sprint Backlog, or the PO decides whether to abort the Sprint if the goal becomes obsolete.

Q: What is the fundamental difference between the Sprint Review and the Sprint Retrospective?R: The Review inspects the tangible product increment and market feedback with stakeholders, whereas the Retrospective focuses internally on team dynamics, workflow, tooling, and continuous process improvements.

Q: What does the Definition of Done mean to you as an engineer?R: It is our shared checklist ensuring an Increment is truly shippable, covering unit tests, code reviews, integration testing, documentation, and deployment readiness before closing a ticket.

Q: How do you address a story that cannot be finished before the Sprint ends?R: We split it or keep it incomplete, do not claim partial story points, return the unfinished portion to the Product Backlog, and re-estimate during the next planning.

Pitfalls and common mistakes

Turning Daily Scrum into a status report to management rather than a peer-level synchronization for Developers.

Carrying over incomplete stories automatically without re-evaluating priorities or re-estimating remaining effort.

Modifying the Sprint Goal constantly mid-Sprint to accommodate ad-hoc requests.

Conflating Story Points with direct hours instead of using them for relative complexity and effort estimation.

Neglecting the Definition of Done, resulting in mounting technical debt hidden behind closed tickets.

Using Retrospectives solely as complaint sessions without defining clear, measurable action items.

Snippets and commands

# Typical Git branch naming aligned with Scrum user stories
git checkout -b feature/SCRUM-102-oauth2-login
git checkout -b bugfix/SCRUM-105-token-refresh-leak

Markdown

<!-- Standard User Story template -->
As a [user persona],
I want to [perform an action],
So that [achieve a business benefit].

Acceptance Criteria:
- Given [precondition], when [action], then [outcome].

To review

[x] Three Scrum roles: Product Owner, Scrum Master, Developers

[x] Five Scrum events: Sprint, Planning, Daily, Review, Retrospective

[x] Three Scrum artifacts: Product Backlog, Sprint Backlog, Increment

[ ] Relative estimation techniques: Planning Poker, Fibonacci sequence, T-shirt sizing

[ ] Burndown vs Burnup charts for tracking velocity and scope creep

[ ] Handling cross-team dependencies via Scrum of Scrums or Nexus

References

Scrum Guide by Ken Schwaber and Jeff Sutherland

Agile Manifesto (Four Core Values and Twelve Principles)