scrum
Scrum
A lightweight framework for delivering complex products through iterative, incremental work. Scrum is founded on empiricism (knowledge from experience) and lean thinking (reduce waste, focus on essentials). Teams work in fixed-length iterations called Sprints, inspecting and adapting continuously.
Three Pillars
| Pillar | Meaning |
|---|---|
| Transparency | The process and work must be visible to those performing and receiving the work |
| Inspection | Scrum artifacts and progress must be inspected frequently to detect problems |
| Adaptation | When inspection reveals deviation, adjust immediately |
Five Values
Commitment, Focus, Openness, Respect, Courage. The Scrum Team commits to achieving goals, focuses on Sprint work, is open about challenges, respects each other as capable people, and has courage to do the right thing.
Sprint Goal
The Sprint Goal is the single objective for the Sprint. It is the commitment of the Sprint Backlog. The Sprint Goal provides focus and coherence, encouraging the Scrum Team to work together rather than on separate initiatives.
Quick Template (Focus / Impact / Confirmation)
Our focus is on [outcome].
We believe it delivers [impact] to [stakeholder/customer].
This will be confirmed when [measurable event happens].
Example: "Our focus is on sending a basic notification email containing a report link. We believe it delivers confidence to our finance team. This will be confirmed when we have an email in an inbox with a working link."
SMART Criteria
| Criterion | Applied to Sprint Goals |
|---|---|
| Specific | Define exactly what the team will achieve, not a vague direction |
| Measurable | Include a way to confirm completion objectively |
| Achievable | The team can realistically deliver within the Sprint timebox |
| Relevant | Connects to the Product Goal and delivers stakeholder value |
| Time-bound | Bounded by the Sprint duration |
Anti-Patterns
| Anti-Pattern | Problem | Fix |
|---|---|---|
| Task list disguised as goal | "Complete stories #101, #102, #103" provides no strategic focus | State the outcome those stories achieve |
| Vague aspiration | "Improve the system" gives no direction or measurable outcome | Be specific: what improves, for whom, how will you know |
| Multiple unrelated objectives | "Build auth AND redesign dashboard" splits focus | Pick one objective; if truly independent, they belong in separate sprints |
| Dictated by PO alone | Team has no ownership or buy-in | Craft the goal collaboratively during Sprint Planning |
| Never referenced after planning | Goal becomes forgotten wallpaper | Reference the goal daily in the Daily Scrum |
| Too ambitious | Team cannot deliver, loses motivation | Base on actual velocity and capacity |
See Sprint Goals Reference for 5 complete templates with examples and the FOCUS evaluation checklist.
Scrum Events
All events are timeboxed. Shorter Sprints use proportionally shorter event timeboxes. Every event is an opportunity to inspect and adapt.
| Event | Timebox (1-month Sprint) | Purpose | Key Output |
|---|---|---|---|
| Sprint | Max 1 month | Container for all work and events | Usable Increment |
| Sprint Planning | Max 8 hours | Define the Sprint Goal and Sprint Backlog | Sprint Goal + selected backlog items + delivery plan |
| Daily Scrum | 15 minutes | Inspect progress toward Sprint Goal | Actionable plan for next 24 hours |
| Sprint Review | Max 4 hours | Inspect the Increment and adapt the Product Backlog | Feedback, updated Product Backlog |
| Sprint Retrospective | Max 3 hours | Inspect the team's process and plan improvements | Improvement actions for next Sprint |
Sprint Planning: Three Topics
- Why is this Sprint valuable? -- Product Owner proposes how to increase value; team defines Sprint Goal
- What can be done this Sprint? -- Developers select Product Backlog items based on capacity and velocity
- How will the chosen work get done? -- Developers decompose items into tasks (typically one day or less)
See Scrum Events Reference for detailed facilitation guidance, formats, and tips.
Scrum Roles
| Role | Accountability | Key Responsibilities |
|---|---|---|
| Scrum Master | Scrum framework effectiveness | Facilitates events, removes impediments, coaches team and organization on Scrum |
| Product Owner | Product value maximization | Manages Product Backlog, communicates Product Goal, ensures backlog transparency |
| Developers | Creating a usable Increment each Sprint | Self-managing, cross-functional, accountable for quality and Definition of Done |
The Scrum Team is a small, cohesive unit (typically 10 or fewer people) with no sub-teams or hierarchies. Everyone is accountable for creating a valuable, useful Increment every Sprint.
See Scrum Roles Reference for detailed responsibilities and facilitation techniques.
Scrum Artifacts
Each artifact contains a commitment that provides transparency and focus:
| Artifact | Commitment | Purpose |
|---|---|---|
| Product Backlog | Product Goal | Ordered list of everything needed to improve the product |
| Sprint Backlog | Sprint Goal | Selected items + Sprint Goal + delivery plan |
| Increment | Definition of Done | Concrete stepping stone toward the Product Goal |
Definition of Done
A formal description of the state of the Increment when it meets quality standards. If a Product Backlog item does not meet the Definition of Done, it cannot be released or presented at the Sprint Review. It returns to the Product Backlog for future consideration.
The Definition of Done creates transparency by giving everyone a shared understanding of what "complete" means. It is a minimum quality bar -- individual items may have additional acceptance criteria.
Sprint Goal Quality Checklist
Before committing to a Sprint Goal, verify:
- Single objective: one clear outcome, not a list of tasks
- Outcome-oriented: describes what the team achieves, not what they do
- Measurable: includes a way to confirm completion
- Achievable: realistic given team capacity and velocity
- Valuable: connects to the Product Goal and matters to stakeholders
- Collaboratively crafted: team contributed, not just the PO
- Visible: will be referenced daily and displayed prominently
- Flexible execution: the goal is fixed but the work to achieve it can adapt
Integration with Team Roles
| Situation | Recommended Skill |
|---|---|
| Writing user stories with acceptance criteria | Install knowledge-virtuoso from krzysztofsurdy/code-virtuoso for testing patterns |
| Planning API work in a sprint | Install knowledge-virtuoso from krzysztofsurdy/code-virtuoso for API design principles |
| Sprint involves architecture decisions | Install knowledge-virtuoso from krzysztofsurdy/code-virtuoso for clean architecture guidance |
| Sprint retrospective reveals code quality issues | Install knowledge-virtuoso from krzysztofsurdy/code-virtuoso for refactoring techniques |
More from krzysztofsurdy/code-virtuoso
symfony-upgrade
Symfony framework version upgrade guide using the deprecation-first approach. Use when the user asks to upgrade Symfony to a new minor or major version, fix deprecation warnings, update Symfony recipes, check bundle compatibility, migrate between LTS versions, or plan a Symfony version migration strategy. Covers PHPUnit Bridge deprecation tracking, recipe updates, bundle compatibility checks, version-specific breaking changes, and the changelog-first upgrade workflow.
90symfony-components
Comprehensive reference for all 38 Symfony framework components with PHP 8.3+ and Symfony 7.x patterns. Use when the user asks to implement, configure, or troubleshoot any Symfony component including HttpFoundation, HttpKernel, DependencyInjection, Form, Validator, Cache, Messenger, Console, EventDispatcher, Workflow, Serializer, Security, Routing, Twig, Doctrine integration, or any other Symfony component. Covers APIs, configuration, best practices, and common pitfalls.
83solid
SOLID principles for object-oriented design with multi-language examples (PHP, Java, Python, TypeScript, C++). Use when the user asks to review SOLID compliance, fix a SOLID violation, evaluate class design, reduce coupling, improve extensibility, or apply Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, or Dependency Inversion principles. Covers motivation, violation detection, refactoring fixes, and real-world trade-offs for each principle.
47agentic-rules-writer
Interactive tool to generate tailored rules and instruction files for any AI coding agent. Use when the user asks to set up agent rules, configure Claude Code instructions, create Cursor rules, write Windsurf rules, generate Copilot instructions, or establish consistent AI coding standards for a team. Supports 13+ agents (Claude Code, Cursor, Windsurf, Copilot, Gemini, Codex, Cline, OpenCode, Continue, Trae, Roo Code, Amp) with global, team-shared, and dev-specific scopes. Defers to the `using-ecosystem` meta-skill for ecosystem discovery (skills, agents, recommendations) and runs an interactive questionnaire for workflow preferences.
47refactoring
Comprehensive skill for 89 refactoring techniques and 22 code smells with practical examples. Use when the user asks to refactor code, detect code smells, improve code quality, reduce complexity, or clean up technical debt. Covers composing methods, moving features between objects, organizing data, simplifying conditionals and method calls, dealing with generalization, and detecting smells across bloaters, OO abusers, change preventers, dispensables, and couplers with before/after comparisons and step-by-step mechanics.
42design-patterns
Comprehensive skill for all 26 Gang of Four design patterns with practical implementations and real-world examples. Use when the user asks to apply a design pattern, refactor code using patterns, choose between competing patterns, or review existing pattern usage. Covers creational (Abstract Factory, Builder, Factory Method, Prototype, Singleton, Object Pool), structural (Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy, Private Class Data), and behavioral patterns (Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method, Visitor, Null Object) with real-world examples, trade-offs, and anti-patterns.
41