Product6 min read

Agile & Scrum

Deliver software in short cycles with Scrum - sprints, backlog refinement, standups, reviews, and retrospectives that keep teams aligned and continuously improving.

AgileScrumSprintKanbanRetrospective

skill: Agile & Scrum category: Product tags: [Agile, Scrum, Sprint, Kanban, Retrospective] readingTime: 6

Scrum is a framework, not a religion. The purpose is frequent delivery and continuous improvement - not the ceremonies themselves. If a ceremony doesn't produce value, change it or drop it. The biggest Scrum failure is 'zombie Scrum' - going through the motions without inspecting or adapting anything.

Workflow

Run effective sprint planningSprint planning aligns the team on what to build and why in this sprint - without it, engineers work on different things with unclear priorities.
Run async standups with brief dailiesA 15-minute daily standup surfacing blockers is valuable; a 45-minute status report meeting is waste. The daily is for the team, not management.
Conduct backlog refinement (grooming)Stories that hit sprint planning without acceptance criteria and size estimates create confusion and scope creep. Refinement prevents this.
Run sprint reviews and retrospectivesReview shows stakeholders what was built and collects feedback; retrospective improves the team's process - both are 'inspect and adapt' moments.
Measure team velocity and healthVelocity (story points completed per sprint) is a planning tool, not a performance metric. Using it for performance creates gaming and inflated estimates.

Output Format

Scrum cadence: 2-week sprints, planning → standups → refinement → review → retrospective, with measurable team health metrics.

2-Week Sprint:
  Day 1: Sprint planning (2h)
  Day 1-9: Daily standup (15min), development
  Day 8: Backlog refinement (1h)
  Day 10: Sprint review (1h) + Retrospective (1h)

Health metrics:
  Velocity: 35-45 points/sprint (stable)
  Sprint goal hit: 85%
  Carryover: < 10%

Examples

Input

Output

Edge Cases & Gotchas

Sprint scope changes mid-sprint - Urgent issues arise during a sprint. Document the scope change, remove equivalent work from the sprint, and note the reason. Chronic mid-sprint changes signal backlog readiness issues.
Team size too large for Scrum - Scrum works best for 5-9 people. Larger teams need multiple Scrum teams (SAFe, LeSS) or different structures. A 15-person Scrum team produces planning meetings that last all day.
Remote team standup fatigue - Daily video standups across time zones burn out remote teams. Use async standups (Geekbot) with weekly video for deeper discussion.
Scrum without product clarity - Scrum is a delivery framework, not a discovery framework. Without a clear problem to solve, Scrum just efficiently delivers the wrong thing. Pair with continuous discovery habits.

When to Break These Rules

Use Kanban instead of Scrum for support-heavy teams or ops teams where work arrives continuously and fixed sprint cycles don't fit - Kanban's flow-based approach is more natural.
Use Shape Up (Basecamp) for product teams that need 6-week uninterrupted cycles with full ownership - it eliminates daily standups and sprint ceremonies in favor of focused bets.

Reference Files

https://scrumguides.org/scrum-guide.html
https://basecamp.com/shapeup