Scrum Framework: Sprints, Roles and Ceremonies
Scrum is the world's most popular Agile framework, used by 70% of teams adopting agile methodologies. Created by Ken Schwaber and Jeff Sutherland in the early 1990s, Scrum provides a lightweight structure for managing complex projects in an iterative and incremental way.
🎯 What You'll Learn
- The 3 Scrum roles: Product Owner, Scrum Master, Development Team
- The 5 Scrum ceremonies (events) in detail
- The 3 artifacts: Product Backlog, Sprint Backlog, Increment
- The complete Sprint cycle with timeline
- Definition of Done and Acceptance Criteria
- Common anti-patterns and how to avoid them
- Scrum at Scale: SAFe, LeSS, Nexus
What is Scrum?
Scrum is an empirical framework based on three pillars:
🏛️ The 3 Pillars of Scrum
- Transparency: All aspects of the process are visible to everyone
- Inspection: Frequent verification of progress towards goals
- Adaptation: Process adjustments based on results
Scrum Structure
SCRUM FRAMEWORK
├── 3 ROLES
│ ├── Product Owner
│ ├── Scrum Master
│ └── Development Team
├── 5 EVENTS (Ceremonies)
│ ├── Sprint
│ ├── Sprint Planning
│ ├── Daily Scrum
│ ├── Sprint Review
│ └── Sprint Retrospective
└── 3 ARTIFACTS
├── Product Backlog
├── Sprint Backlog
└── IncrementThe 3 Scrum Roles
1. Product Owner (PO)
The Product Owner is the "product owner", responsible for maximizing the value of the team's work.
🎯 Product Owner Responsibilities
- Product vision: Define and communicate the product vision
- Product Backlog management: Create, order and maintain the backlog
- Prioritization: Decide what's most important (ROI-driven)
- Work acceptance: Approve/reject completed user stories
- Stakeholder engagement: Interface between team and customer/business
- Decision maker: Has final say on "what" to build (not "how")
✅ Effective PO
- Available to team daily
- Quick decisions
- Clear product vision
- Knows business domain
- Empowered (has authority)
- Collaborative with team
❌ Ineffective PO
- Absent/unavailable
- Slow or indecisive
- PO "by committee"
- Doesn't know business
- Just proxy, no authority
- Micromanages team
2. Scrum Master
The Scrum Master is the servant leader who helps the team and organization adopt Scrum effectively.
🛡️ Scrum Master Responsibilities
Service to Development Team:
- Coaching on self-organization and cross-functionality
- Removing impediments (blockers)
- Facilitating Scrum events
- Protecting team from external distractions
Service to Product Owner:
- Help effectively manage the Product Backlog
- Facilitate collaboration with team
- Coaching on Agile practices
Service to Organization:
- Guide Scrum adoption in the org
- Increase team productivity
- Work with other Scrum Masters
⚠️ Scrum Master is NOT:
- ❌ Project Manager (Scrum has no PM!)
- ❌ Team Lead or Manager
- ❌ Team secretary
- ❌ Responsible for delivery
- ❌ Technical lead
The Scrum Master is a facilitator and coach, not a manager with authority over the team.
3. Development Team
The Development Team is a group of professionals who work together to deliver a "Done" increment of the product at the end of each Sprint.
👥 Development Team Characteristics
- Self-organizing: Decides autonomously how to accomplish work
- Cross-functional: Has all skills needed (dev, test, design, etc.)
- No sub-teams: No separate "frontend" or "backend" teams
- No titles: Everyone is a "Developer" (no internal hierarchy)
- Accountable as team: Success and failure are collective
- Optimal size: 3-9 people (ideal: 5-7)
Why 3-9 People?
👥 TEAM SIZE ANALYSIS
< 3 people
├─ ❌ Too small
├─ Missing necessary skills
├─ Vulnerability (absences impact heavily)
└─ Little knowledge exchange
3-5 people
├─ ✅ Easy communication
├─ ✅ High decision speed
└─ ⚠️ Limited skill coverage
6-9 people
├─ ✅ Optimal balance
├─ ✅ Diverse competencies
├─ ✅ Resilience to absences
└─ ⚠️ Communication requires more effort
> 9 people
├─ ❌ Too large
├─ Complex communication (N*(N-1)/2)
├─ High coordinating overhead
└─ Consider splitting into 2 teamsThe 5 Scrum Ceremonies
1. Sprint (Timeboxed Container)
The Sprint is the heart of Scrum: a time-boxed cycle of 1-4 weeks (most common: 2 weeks) during which a "Done" product increment is created.
📅 Sprint Rules
- Fixed duration: Always the same length for all sprints
- Sprint Goal: Clear and shared objective
- No changes: Scope doesn't change during sprint (focus)
- Quality: Definition of Done is not compromised
- Cancellation: Only PO can cancel a sprint (rare!)
2. Sprint Planning
Time-box: Maximum 8 hours for 1-month sprint (proportional for shorter sprints).
Participants: Entire Scrum Team (PO, SM, Dev Team).
Sprint Planning - 2 Parts
🔵 PART 1: WHAT? (What will we do?)
Duration: ~50% of time (e.g: 2 hours for 2-week sprint)
1. Product Owner presents top priority backlog items
2. Team asks questions to understand requirements
3. Team selects items for sprint (pull, not push!)
4. Sprint Goal is defined
└─ Ex: "Implement complete checkout flow"
Output: Sprint Backlog (list of selected user stories)
---
🔵 PART 2: HOW? (How will we accomplish it?)
Duration: ~50% of time
1. Team breaks down each user story into technical tasks
2. Estimate effort in hours for each task
3. Identify dependencies and risks
4. Validate capacity (historical velocity)
5. Team commitment
Output: Detailed Sprint Backlog with tasks
---
📊 CAPACITY PLANNING
Team of 5 people, 2-week sprint:
- 5 people × 10 days = 50 theoretical person-days
- -20% for meetings, support, unexpected = 40 effective days
- Historical velocity: 30 story points
- → Commitment: ~25-30 story points (conservative)3. Daily Scrum (Standup)
Time-box: 15 minutes (fixed!).
Participants: Development Team (mandatory), SM facilitates, PO optional.
When: Same time, same place, every day.
🗣️ The 3 Classic Questions
Each team member answers:
- What did I do yesterday that helped the team toward the Sprint Goal?
- What will I do today to help the team toward the Sprint Goal?
- Do I have impediments blocking me or the team?
❌ Daily Scrum Anti-Patterns
- Status report to manager: It's not hierarchical reporting!
- Extended problem-solving: Daily is for sync, not solving problems (after meeting)
- Duration > 15 min: Time-box is sacred, discussions outside daily
- Only Scrum Master talks: Should be team conversation
- People standing/sitting: Standing meeting helps keep it brief
4. Sprint Review
Time-box: Maximum 4 hours for 1-month sprint (e.g: 2 hours for 2-week sprint).
Participants: Scrum Team + Stakeholders + Customer.
🎬 Sprint Review Agenda
- Opening (5 min): PO recalls Sprint Goal and what was planned
- Demo (60%): Team shows working software (live demo, no slides!)
- Only "Done" features according to DoD
- Staging/production-like environment
- Interactive: stakeholders try the product
- Feedback (30%): Stakeholders provide input
- What works well?
- What's missing or needs changing?
- New ideas emerged
- Product Backlog update (10%): PO updates backlog with insights
Demo Script Example
Sprint Review - Sprint 14 - E-commerce Checkout
✅ COMPLETED (Demo order):
1. User Story: "Add payment method selection"
└─ Demo: Credit card, PayPal, Apple Pay
2. User Story: "Implement address autocomplete"
└─ Demo: Google Places API integration
3. User Story: "Order confirmation email"
└─ Demo: Email template with order details
❌ NOT COMPLETED (transparency!):
4. User Story: "Coupon code validation"
└─ Reason: API integration more complex, rollover to next sprint
🔄 FEEDBACK COLLECTED:
- Stakeholder: "Add shipping estimation before checkout"
- PO: Added to backlog, high priority
- Marketing: "Email template needs company branding"
- PO: Created new story for next sprint5. Sprint Retrospective
Time-box: Maximum 3 hours for 1-month sprint (e.g: 1.5 hours for 2-week sprint).
Participants: Only Scrum Team (PO, SM, Dev Team). No external stakeholders!
When: After Sprint Review, before next Planning.
🔄 Retrospective Objective
Inspect & Adapt the work process (not the product). Focus on:
- What went well? (Keep doing)
- What went wrong? (Stop doing)
- What can we improve? (Start doing)
Retrospective Techniques
🎯 TECHNIQUE 1: Start-Stop-Continue
┌─────────────┬─────────────┬─────────────┐
│ START │ STOP │ CONTINUE │
├─────────────┼─────────────┼─────────────┤
│ Pair │ Working │ Code │
│ programming │ overtime │ reviews │
│ │ │ │
│ Automated │ Skipping │ Daily │
│ tests │ retrospect. │ standups │
└─────────────┴─────────────┴─────────────┘
🎯 TECHNIQUE 2: Happiness Radar
Team rates (1-5) different categories:
- Collaboration: ⭐⭐⭐⭐⭐ (Excellent!)
- Technical quality: ⭐⭐⭐ (Needs improvement)
- Work-life balance: ⭐⭐ (RED FLAG!)
- Sprint goal clarity: ⭐⭐⭐⭐
🎯 TECHNIQUE 3: Sailboat Retrospective
⛵ Goal (island): Where do we want to reach?
🌊 Winds: What pushes us forward?
⚓ Anchors: What holds us back?
🪨 Rocks: Risks to avoid?
OUTPUT: 1-3 concrete ACTION ITEMS
✅ Action: "Introduce TDD from next sprint"
Owner: Entire team
Due: Sprint 15
Success: 50% new code has tests first🛡️ Retrospective Rules
- Safe space: What's said in retro, stays in retro
- No blame: Focus on process, not people
- Honesty: Speak up! This is the time to improve
- Action-oriented: Not just complaints, also solutions
- Follow-up: Review previous sprint's action items
The 3 Scrum Artifacts
1. Product Backlog
Ordered and dynamic list of all work needed for the product. Owned by Product Owner.
📚 Product Backlog Characteristics
- Ordered (not prioritized): Single sequence, top = next sprint
- Emergent: Evolves continuously, never "complete"
- Detailed appropriately: Top items detailed, bottom vague
- Estimated: Story points or other relative metric
- Transparent: Visible to everyone
Product Backlog Example
PRODUCT BACKLOG - E-commerce Platform
Ordered by value/priority (top = next)
Pos | ID | User Story | Points | Status
----|-----|---------------------------------------|--------|--------
1 | 123 | Guest checkout without registration | 8 | Ready
2 | 124 | Save payment methods for future | 5 | Ready
3 | 125 | Product recommendations AI | 13 | Ready
4 | 126 | Multi-currency support | 20 | Refining
5 | 127 | Wishlist sharing social | 8 | Refining
6 | 128 | Advanced search filters | 13 | Refining
...
20 | 145 | Dark mode UI | ? | Idea
21 | 146 | Voice search | ? | Idea
READY = Acceptance criteria defined, DoD clear, impediments removed
REFINING = In discussion, needs more details
IDEA = High-level, to be elaborated in future2. Sprint Backlog
Subset of Product Backlog selected for current Sprint + plan to deliver it. Owned by Development Team.
📋 Sprint Backlog Content
- Selected user stories
- Detailed technical tasks
- Sprint Goal
- Implementation plan
- Real-time status of each task
🔄 Updates
- Updated by team daily
- New tasks can emerge
- Only team can modify it
- Visible on board (physical/digital)
- Burndown chart derives from it
3. Increment
The sum of all Product Backlog items completed during a Sprint + value of increments from all previous Sprints. Must be "Done" according to Definition of Done.
✅ Definition of Done (DoD)
Shared and clear criteria for when work is considered complete. Non-negotiable!
Definition of Done Example
📋 DEFINITION OF DONE (Team Level)
A user story is "DONE" when:
✅ DEVELOPMENT
├─ Code written following coding standards
├─ Code committed to feature branch
├─ Code review approved (2+ reviewers)
└─ Merged to main branch
✅ TESTING
├─ Unit tests written (coverage ≥ 80%)
├─ Integration tests passed
├─ Regression tests passed
├─ Manual exploratory testing completed
└─ No P0/P1 bugs open
✅ DOCUMENTATION
├─ Inline code comments for complex logic
├─ API documentation updated
├─ README updated (if necessary)
└─ User documentation written (if user-facing feature)
✅ QUALITY
├─ Linter passed (zero warnings)
├─ Security scan passed
├─ Performance benchmarks ok
└─ Accessibility checks passed (WCAG 2.1 AA)
✅ DEPLOYMENT
├─ Deployed to staging environment
├─ Smoke tests on staging passed
├─ Product Owner accepted (demo)
└─ Ready for production deployment
---
DoD can have 3 levels:
1. Task DoD: Single task completed
2. Story DoD: User story completed (above)
3. Release DoD: Releasable increment to productionComplete Sprint Flow
2-Week Sprint Timeline (Example)
SPRINT 14 - Goal: "Implement complete checkout flow"
📅 MONDAY WEEK 1 (Day 1)
├─ 09:00-13:00: Sprint Planning
│ ├─ Part 1 (WHAT): PO presents, team selects stories (20 pts)
│ └─ Part 2 (HOW): Breakdown into tasks, capacity planning
└─ 14:00-18:00: Development starts
📅 TUE-FRI WEEK 1 (Days 2-5)
├─ 09:00-09:15: Daily Scrum (every day)
├─ 09:15-18:00: Development + Testing
└─ Continuous: Code review, pair programming
📅 WEDNESDAY WEEK 1 (Mid-Sprint)
└─ 15:00-16:00: Backlog Refinement (optional)
└─ Prepare stories for next sprint
📅 MON-THU WEEK 2 (Days 6-9)
├─ 09:00-09:15: Daily Scrum
├─ Development + Integration
└─ Bug fixing and polish
📅 FRIDAY WEEK 2 (Day 10)
├─ 09:00-09:15: Daily Scrum (last!)
├─ 09:15-13:00: Final testing and demo prep
├─ 14:00-16:00: Sprint Review
│ └─ Demo to stakeholders, feedback collection
├─ 16:15-17:45: Sprint Retrospective
│ └─ Inspect & adapt process
└─ 17:45-18:00: Celebration! 🎉
🔵 MONDAY WEEK 3
└─ Sprint 15 starts...Common Scrum Anti-Patterns
🚫 Mistakes to Avoid
1. Scrum But
Symptom: "We do Scrum but... [exception]"
- "Scrum but without Daily Scrum" → Not Scrum
- "Scrum but without Retrospective" → You'll never improve
- "Scrum but PO not available" → Team constantly blocked
2. Sprint as Mini-Waterfall
Problem: All phases sequentially in sprint
❌ BAD: Sprint = Design → Dev → Test → Deploy (waterfall!)
✅ GOOD: Sprint = Iterate on features, each feature Done completely3. Absent or Vague Sprint Goal
Problem: Sprint is just "task list" without coherent goal
- ❌ BAD: "Complete stories 45, 46, 47, 48"
- ✅ GOOD: "Enable users to complete purchase without registration"
4. Velocity as Fixed Commitment
Problem: Management uses velocity to pressure team
- Velocity is a planning metric, not a target to reach!
- Team under pressure inflates estimates → velocity loses meaning
5. Product Owner Proxy
Problem: PO has no authority, must always "ask"
- Slow decisions
- Team blocked
- Solution: Empower the PO or change person
Scrum at Scale
When organization has many Scrum teams, frameworks are needed to coordinate. The 3 main ones:
🏢 SAFe (Scaled Agile Framework)
- Most popular framework for enterprise
- 4 levels: Team, Program, Large Solution, Portfolio
- Program Increment (PI) of 8-12 weeks
- Agile Release Train (ART): 50-125 people
- Pro: Structured, documented, suitable for large orgs
- Contra: Heavy, less agile than pure Scrum
🪜 LeSS (Large-Scale Scrum)
- Scrum extended to multiple teams (2-8 teams)
- 1 Product Owner for all teams
- 1 shared Product Backlog
- Synchronized sprints
- Overall cross-team Retrospective
- Pro: Maintains Scrum simplicity
- Contra: Requires high Agile maturity
🔗 Nexus
- Scrum.org framework for 3-9 teams
- Nexus Integration Team coordinates
- Nexus Sprint Planning, Review, Retrospective
- Focus on continuous integration
- Pro: Official from Scrum.org
- Contra: Limited to ~100 people
Useful Scrum Metrics
📊 Process Metrics
- Velocity: Story points/sprint
- Sprint Burndown: Remaining work
- Release Burnup: Progress toward release
- Cycle Time: Time story → done
🎯 Quality Metrics
- Defect Rate: Bugs per sprint
- Code Coverage: % tested code
- Technical Debt: Refactoring effort
- Team Happiness: Quarterly survey
Conclusions
Scrum provides a simple but powerful structure for Agile development. The key to success is rigorous adoption of the framework (no Scrum But!) combined with continuous inspection and adaptation.
💡 Key Takeaways
- Scrum has 3 roles, 5 events, 3 artifacts - all essential
- Product Owner maximizes value, Scrum Master facilitates, Dev Team delivers
- Sprint is time-boxed cycle (1-4 weeks) with clear goal
- Definition of Done is non-negotiable quality criterion
- Retrospective is the engine of continuous improvement
- Transparency, Inspection, Adaptation are the 3 pillars
- Scrum at Scale requires additional frameworks (SAFe, LeSS, Nexus)
📚 Next Article
In the next article we'll explore Kanban Method: the continuous flow system with WIP limits, Kanban board, flow metrics (Lead Time, Cycle Time) and comparison with Scrum.