agile-scrum

When this skill is activated, always start your first response with the 🧢 emoji.

Agile & Scrum

Agile is an iterative approach to project delivery that focuses on delivering small, incremental pieces of value through short cycles called sprints. Scrum is the most widely adopted Agile framework, structured around defined roles (Product Owner, Scrum Master, Developers), events (Sprint Planning, Daily Standup, Sprint Review, Retrospective), and artifacts (Product Backlog, Sprint Backlog, Increment). This skill covers practical application of Scrum ceremonies, estimation techniques, velocity tracking, Kanban flow management, and continuous improvement practices.

When to use this skill

Trigger this skill when the user:

• Needs to plan a sprint or organize a sprint planning session
• Wants to run or improve retrospectives
• Asks about velocity tracking, burndown charts, or sprint metrics
• Needs to estimate stories using story points, T-shirt sizing, or planning poker
• Wants to set up or optimize a Kanban board
• Asks about backlog grooming or refinement practices
• Needs templates for user stories, acceptance criteria, or definition of done
• Wants to improve team agile processes or adopt Scrum

Do NOT trigger this skill for:

• General project management unrelated to Agile (waterfall, PRINCE2, etc.)
• Software architecture or technical design decisions (use engineering skills instead)

Key principles

1. Deliver working increments - Every sprint must produce a potentially shippable

increment. If a team consistently fails to deliver done work, the sprint length or scope is wrong. Favor smaller slices of value over large batches.

1. Inspect and adapt relentlessly - Every Scrum event is an inspection point.

Retrospectives are not optional feel-good sessions; they produce concrete action items that the team commits to in the next sprint. Measure whether actions were completed.

1. Limit work in progress - Whether using Scrum or Kanban, WIP limits are the

single most effective lever for improving flow. A team that starts fewer things finishes more things. Default WIP limit: number of developer pairs + 1.

1. Estimation is for planning, not accountability - Story points measure

complexity and uncertainty, not hours or individual performance. Never use velocity to compare teams or pressure individuals. Velocity is a planning tool, not a performance metric.

1. Transparency over perfection - Make all work visible. Hidden work-in-progress,

undisclosed blockers, and invisible technical debt destroy predictability. A board that shows reality is more valuable than one that looks clean.

Core concepts

Scrum events form a feedback loop. Sprint Planning sets the goal and selects work. Daily Standups surface blockers early. Sprint Review demonstrates the increment to stakeholders. Retrospective improves the process itself. Skipping any event breaks the feedback loop and causes drift.

The Product Backlog is a living, ordered list. It is not a dumping ground for every idea. The Product Owner continuously refines and re-prioritizes it. Items near the top are small, well-defined, and estimated. Items at the bottom are large and vague. Backlog refinement (grooming) should consume roughly 10% of the team's capacity each sprint.

Velocity is a trailing indicator. It is the sum of story points completed in a sprint. Use the average of the last 3-5 sprints for planning. Velocity naturally fluctuates; a single sprint's velocity is meaningless. Only trends over 4+ sprints reveal real changes in capacity or process.

Kanban focuses on flow, not time-boxes. Instead of sprints, Kanban uses a continuous flow with explicit WIP limits per column. The key metrics are cycle time (how long one item takes from start to done) and throughput (how many items complete per unit of time). Kanban and Scrum can coexist (Scrumban).

Common tasks

Run sprint planning

Sprint planning answers two questions: What can we deliver this sprint? How will we deliver it?

Template: Sprint Planning Agenda (2 hours for a 2-week sprint)

1. Review sprint goal (10 min) - PO proposes a sprint goal tied to a product

objective. Team discusses feasibility.

1. Select backlog items (40 min) - Team pulls items from the top of the refined

backlog until capacity is reached. Use last 3-sprint velocity average as the guide.

1. Task breakdown (50 min) - For each selected item, break it into tasks. If any

task is larger than 1 day, break it further.

1. Confirm sprint goal and commitment (10 min) - Team agrees on the sprint

backlog and goal. PO confirms priority order.

1. Identify risks and dependencies (10 min) - Flag external dependencies, PTO,

or known blockers.

Capacity adjustment: multiply velocity by (available dev-days / total dev-days)

to account for PTO, holidays, and on-call rotations.

Estimate with story points

Use the modified Fibonacci sequence: 1, 2, 3, 5, 8, 13, 21. Anything above 13 should be split before entering a sprint.

Planning Poker process:

1. PO reads the user story and acceptance criteria
2. Team asks clarifying questions (time-box: 3 min per story)
3. Everyone simultaneously reveals their estimate
4. If estimates diverge by more than 2 levels (e.g., 3 vs 13), the highest and

lowest estimators explain their reasoning

1. Re-vote. If still divergent after 2 rounds, take the higher estimate

Estimation reference table:

| Points | Complexity | Uncertainty | Example | |--------|-----------|-------------|---------| | 1 | Trivial | None | Fix a typo, update a config value | | 2 | Low | Minimal | Add a field to an existing form | | 3 | Moderate | Low | Build a new API endpoint with tests | | 5 | Significant | Some | Integrate a third-party service | | 8 | High | Moderate | Redesign a data pipeline component | | 13 | Very high | High | New feature spanning multiple services | | 21 | Epic-level | Very high | Should be broken down further |

Run a retrospective

Format: Start-Stop-Continue (45 min for a 2-week sprint)

1. Set the stage (5 min) - State the retro goal. Use a safety check (1-5 scale)

to gauge openness.

1. Gather data (15 min) - Each person writes items on sticky notes (or digital

equivalent) in three columns: Start doing, Stop doing, Continue doing.

1. Group and vote (10 min) - Cluster similar items. Dot-vote (3 dots per person)

to prioritize.

1. Generate actions (10 min) - For the top 2-3 voted items, define a specific

action with an owner and a due date. Actions must be achievable within one sprint.

1. Close (5 min) - Review action items. Check: did we complete last retro's

actions?

Alternative formats (rotate to prevent staleness):

• 4Ls: Liked, Learned, Lacked, Longed for
• Sailboat: Wind (helps), Anchor (slows), Rocks (risks), Island (goal)
• Mad-Sad-Glad: Emotional categorization for team health checks
• Timeline: Plot the sprint on a timeline marking highs and lows

Rule: never leave a retro without exactly 2-3 action items with named owners.

More than 3 dilutes focus. Zero means the retro was pointless.

Track velocity and sprint metrics

Key metrics to track each sprint:

| Metric | Formula | Healthy range | |--------|---------|---------------| | Velocity | Sum of completed story points | Stable +/- 20% over 4 sprints | | Sprint completion rate | Completed items / committed items | 80-100% | | Carry-over rate | Incomplete items / committed items | 0-20% | | Scope change rate | Added items / original committed items | 0-10% | | Bug ratio | Bugs found / stories delivered | Below 15% |

Burndown chart interpretation:

• Flat line early, cliff late - Team batching work; encourage smaller slices
• Scope creep visible - Line goes up mid-sprint; enforce sprint scope protection
• Smooth decline - Healthy flow; team is brea