🔁

Agile & Scrum

Master iterative development, sprint ceremonies, team roles, and the frameworks that let modern teams ship value continuously.

The Agile Manifesto

Written in 2001 by 17 software practitioners, the Agile Manifesto defines 4 core values and 12 principles that changed how software is built. 84% of organizations now use Agile in some form.

👥 Individuals & Interactions

over processes and tools

A great team with poor tools outperforms a poor team with great tools. Conway's Law: your system architecture mirrors your team structure. Build cross-functional, empowered teams first.

📦 Working Software

over comprehensive documentation

Ship something real every sprint. A demo is worth a thousand meetings. The measure of progress is working software — not burndown charts or velocity metrics.

🤝 Customer Collaboration

over contract negotiation

Involve stakeholders weekly, not just at the start and end. Amazon's "working backwards" model writes the press release before writing a line of code — aligning with the customer from day one.

🔄 Responding to Change

over following a plan

Markets change, users give feedback, requirements evolve. Teams that can pivot quickly win. Spotify rebuilt their entire backend architecture mid-growth. Flexibility > rigidity.

✅ Real-World Impact Teams using Agile release 3× more frequently, have 37% fewer defects, and report 30% higher employee satisfaction compared to waterfall teams (VersionOne State of Agile Report, 2023).

The Scrum Framework

Scrum is the most popular Agile framework, used by 66% of Agile teams. It organizes work into fixed-length sprints (1–4 weeks) with clear roles, ceremonies, and artifacts.

Sprint Cycle

📋
Sprint
Planning
2–4 hrs
💻
Sprint
Execution
1–4 weeks
Daily Standups
🎯
Sprint
Review
1–2 hrs
🔄
Retro-
spective
1–1.5 hrs
🚀
Next
Sprint

Scrum Roles

👑

Product Owner

  • Owns the Product Backlog
  • Defines priorities (what to build)
  • Represents business/stakeholders
  • Accepts or rejects sprint output
  • Writes user stories with acceptance criteria
NOT a project manager — focused on value, not schedule
🧭

Scrum Master

  • Facilitates all Scrum ceremonies
  • Removes blockers (impediments)
  • Coaches team on Agile practices
  • Protects team from external interruptions
  • Helps team improve velocity sprint-over-sprint
Servant leader — not a boss or task assigner
👩‍💻

Development Team

  • Self-organizing and cross-functional
  • 3–9 people (optimal: 5–7)
  • Decides HOW to build (not what)
  • Commits to sprint backlog
  • Owns quality — testing is everyone's job
No sub-teams — everyone does whatever it takes

Sprint Ceremonies in Detail

Each ceremony has a specific purpose and time-box. Running them well is the difference between a high-performing Agile team and one that just goes through the motions.

📋 Sprint Planning

⏱ 2 hours per week of sprint👥 Whole team📅 First day of sprint

Answer two questions: (1) What can we deliver this sprint? (2) How will we do it? The team pulls stories from the top of the Product Backlog, breaks them into tasks, and commits to a Sprint Goal.

# Sprint Planning Template
Sprint Goal: Enable users to add and categorize expenses

Stories Committed:
  ✓ [5 pts] Add expense form with amount + category
  ✓ [3 pts] Edit/delete existing expenses
  ✓ [2 pts] Category filter on expense list
  ✗ [8 pts] AI category suggestion (moved to next sprint)

Team Capacity: 4 devs × 8 days × 6 hrs = 192 hrs
Committed: ~40 story points (team velocity avg: 42)

☀️ Daily Standup (15 min)

⏱ 15 minutes max👥 Dev team📅 Every day, same time

Not a status report to the Scrum Master — it's a synchronization meeting for the team. Three questions only:

# Each team member answers:
1. Yesterday:  "Finished the expense form UI, all tests passing"
2. Today:     "Starting the category filter — pair with Ali"
3. Blockers:  "Need design sign-off on the modal layout"

# Anti-patterns to avoid:
✗ Detailed technical discussions (take offline)
✗ Problem-solving during standup
✗ Reporting to SM instead of team
✗ Longer than 15 minutes

🎯 Sprint Review (Demo)

⏱ 1 hour per week of sprint👥 Team + Stakeholders📅 Last day of sprint

The team demos working software to stakeholders and gets feedback. Only completed (done-done) stories are demoed. This is where the Product Owner formally accepts or rejects stories.

🔄 Retrospective

⏱ 45 min per week of sprint👥 Dev team only📅 Last day of sprint, after review
# Start/Stop/Continue format (most common)
Start:  "Writing tests before code (TDD)"
         "Using feature flags for risky changes"

Stop:   "Merging PRs without 2 reviews"
         "Picking up new tasks mid-sprint"

Continue: "Daily pair programming sessions"
            "Documenting decisions in ADRs"

# Action items: specific, assigned, and time-boxed
Action: Set up branch protection rules by next Wednesday — assigned: Leyla

Kanban vs Scrum

Both are Agile frameworks, but they solve different problems. Scrum is prescriptive and sprint-based; Kanban is flow-based and continuous.

AspectScrumKanban
CadenceFixed sprints (1–4 weeks)Continuous flow
RolesPO, SM, Dev Team requiredNo prescribed roles
WIP LimitsSprint backlog limits workExplicit WIP limits per column
Change mid-cycle❌ Sprint scope is locked✅ Add/remove anytime
Planning meetingsSprint planning every sprintJust-in-time planning
Best forProduct development, new featuresOps, support, maintenance
MetricsVelocity, burndown chartCycle time, throughput
Real-world useSpotify feature teams, most startupsGitHub ops, Trello support teams
💡 Spotify's Squad Model Spotify uses Agile with a unique structure: Squads (like small Scrum teams, own a feature area), Tribes (collection of squads on a mission), Chapters (cross-squad guild by skill: backend, iOS), Guilds (company-wide interest groups). This lets them scale Agile to 200+ engineers without bureaucracy.
🃏

Try Planning Poker

Real-time agile estimation tool. Create a room, invite your team, and estimate story points together — instantly see consensus and disagreements.

Launch Planning Poker →