Part 2: Scrum Framework - Roles, Ceremonies, and Artifacts
Part of the Agile Development 101 Series
My Introduction to Scrum
"We're going agile!" my manager announced. What followed was a confusing mix of new terminology - sprints, standups, retrospectives, backlogs. I had no idea what any of it meant or how it would change my daily work.
Fast forward to today, and Scrum has become second nature. I've participated in hundreds of sprints, facilitated dozens of retrospectives, and seen how this framework transforms chaotic development into structured delivery. In this article, I'll share what Scrum actually is and how I've applied it in real projects.
What is Scrum?
Scrum is a framework for managing work, with emphasis on software development. It's:
Iterative: Work is divided into time-boxed iterations called sprints
Incremental: Each sprint delivers working software
Empirical: Decisions are based on observation and experimentation
Think of Scrum as the rules of a game. Just like basketball has specific roles, plays, and rules, Scrum has roles, ceremonies, and artifacts that structure team collaboration.
Why "Scrum"?
The name comes from rugby, where a scrum is a formation where teams work together to move the ball forward. In software, Scrum teams work together to move features forward.
The Scrum Framework at a Glance
Here's a visual representation of how Scrum works:
The Three Roles in Scrum
Scrum defines three roles, each with distinct responsibilities. I've played two of these roles and worked closely with all three.
1. Product Owner (PO)
Responsibility: Maximize the value of the product and the work of the development team.
What they actually do:
In my projects, the Product Owner:
Maintains and prioritizes the product backlog
Defines user stories and acceptance criteria
Makes decisions about what to build and when
Accepts or rejects completed work
Represents stakeholder interests
My experience working with POs:
The best product owners I've worked with:
Are available for questions during the sprint
Provide clear acceptance criteria upfront
Trust the team on technical decisions
Can make decisions without endless meetings
The worst:
Are too busy to engage with the team
Change priorities mid-sprint constantly
Micromanage implementation details
Can't make decisions without involving five other stakeholders
Example: In one project, our PO attended daily standups and was available on Slack throughout the day. When we had questions about a feature, we got answers in minutes, not days. This responsiveness kept development flowing smoothly.
2. Scrum Master (SM)
Responsibility: Ensure the team follows Scrum practices and remove impediments.
What they actually do:
Scrum Masters I've worked with:
Facilitate Scrum ceremonies (planning, standups, reviews, retrospectives)
Remove blockers that impede team progress
Shield the team from distractions and interruptions
Coach the team on Scrum practices
Foster continuous improvement
My experience:
I served as Scrum Master for a small team, and I learned that it's not about control - it's about service. I focused on:
Making sure everyone could speak in ceremonies
Following up on impediments raised in standups
Protecting sprint commitments from scope creep
Creating a safe environment for retrospectives
Example: During one sprint, our team was blocked by a slow code review process from another team. As Scrum Master, I escalated this to management and helped establish an SLA for cross-team reviews. The impediment was removed, not by magic, but by addressing root causes.
Important: Scrum Master is not a project manager. They don't assign tasks or manage people. They facilitate and serve.
3. Development Team
Responsibility: Deliver potentially shippable increments of product each sprint.
Characteristics of effective development teams I've been part of:
Self-organizing: The team decides how to accomplish work, not a manager
Cross-functional: The team has all skills needed (frontend, backend, testing, etc.)
Collaborative: Team members help each other
Accountable: The team collectively owns success and failure
Size: Scrum recommends 3-9 members. I've found 5-7 to be ideal. Too small means limited skills and capacity; too large means communication overhead.
My experience:
As a developer, I appreciated:
Having autonomy to choose technical approaches
Collaborating with teammates on design decisions
Collective code ownership (not "my code" vs "your code")
Shared responsibility for sprint goals
Example: When a story was harder than expected, instead of one person struggling, we'd swarm on it - pair programming, mob programming, or dividing it into parallel tasks. The sprint goal mattered more than individual assignments.
The Five Scrum Ceremonies (Events)
Scrum defines five recurring events. Here's how I've experienced each:
1. Sprint Planning
When: At the start of each sprint Duration: Typically 2-4 hours for a 2-week sprint Participants: Entire Scrum team
Purpose: Determine what work will be done in the sprint and how.
My typical sprint planning flow:
Product Owner presents priorities: Top items from the product backlog
Team asks questions: Clarify requirements and acceptance criteria
Team estimates capacity: How much work can we realistically commit to?
Team selects work: Pull items into sprint backlog
Team breaks down work: Decompose stories into tasks
Tools I use: Jira for backlog management, Confluence for notes, Miro for collaborative planning
Example:
Common pitfalls I've observed:
Planning too much work (teams rarely complete 100% of commitments initially)
Not clarifying acceptance criteria (leads to rework)
Spending too long on planning (paralysis by analysis)
Not involving the whole team (some voices get lost)
What works:
Start with a clear sprint goal
Focus on the "what" and "why," let the team figure out "how"
Keep it timeboxed
Revisit velocity from previous sprints
2. Daily Scrum (Standup)
When: Every day, same time and place Duration: 15 minutes maximum Participants: Development team (PO and SM can attend but shouldn't dominate)
Purpose: Synchronize activities and create a plan for the next 24 hours.
The three questions:
Each team member answers:
What did I do yesterday?
What will I do today?
Are there any impediments in my way?
My experience:
I've tried standups at different times:
9:00 AM: Good for setting the day's direction
4:00 PM: Good for reflecting, but people rush to leave
10:00 AM: My favorite - gives time for morning focus, still plenty of day left
Example standup update:
Common anti-patterns:
Standup becomes a status report to the Scrum Master (should be peer-to-peer)
Goes over 15 minutes with detailed discussions (take those offline)
People not paying attention when others speak
Missing standups regularly
What works:
Stand up (really, physically stand - meetings stay shorter)
Use a timer
Park detailed discussions for after
Keep it focused on coordination, not reporting
Tools: We use Slack for standup when remote, with a bot that prompts everyone.
3. Sprint Review (Demo)
When: At the end of each sprint Duration: 1-2 hours for a 2-week sprint Participants: Scrum team + stakeholders
Purpose: Demonstrate completed work and gather feedback.
My typical sprint review:
Product Owner restates sprint goal: Remind everyone what we aimed for
Team demonstrates working software: Show completed stories in staging/production
Stakeholders provide feedback: What works? What doesn't? What's missing?
Product Owner adjusts backlog: Based on feedback and learnings
Example agenda:
Common pitfalls:
Demonstrating code instead of working features (stakeholders don't care about code)
No actual demo, just slide presentations
Only developers attend (missing stakeholder feedback)
Taking feedback as criticism (it's valuable learning)
What works:
Demo in production or production-like environment
Focus on user value, not technical details
Encourage honest feedback
Keep it conversational, not formal
4. Sprint Retrospective (Retro)
When: After Sprint Review, before next Sprint Planning Duration: 1-1.5 hours for a 2-week sprint Participants: Scrum team only (no stakeholders)
Purpose: Reflect on the sprint and identify improvements.
Why I value retros:
This is where continuous improvement happens. The best teams I've been on treat retros as sacred - a safe space to discuss what's working and what isn't.
Common retro formats I've used:
Start/Stop/Continue
Start: What should we start doing?
Stop: What should we stop doing?
Continue: What's working well?
Went Well / Needs Improvement
Went Well: Celebrate successes
Needs Improvement: Identify problems
Action Items: Concrete steps to improve
4 Ls
Liked: What did you like?
Learned: What did you learn?
Lacked: What was missing?
Longed For: What did you wish for?
Example retro outcomes:
Common pitfalls:
Same people dominating discussions
Identifying problems but no action items
Action items from previous retros never followed up
Finger-pointing instead of team reflection
Skipping retros when "things are fine"
What works:
Rotate retro facilitator
Use different formats to keep it fresh
Create psychological safety (no blame)
Track action items and review them next retro
Even good sprints have room for improvement
Tools I use: Miro or Mural for virtual retros, sticky notes for in-person
5. Backlog Refinement (Grooming)
When: Mid-sprint, ongoing Duration: 1-2 hours per sprint Participants: Product Owner + some/all developers
Purpose: Prepare backlog items for future sprints.
What happens during refinement:
Breaking down large stories into smaller ones
Adding acceptance criteria
Estimating story points
Clarifying requirements
Removing obsolete items
My approach:
I prefer continuous refinement throughout the sprint rather than one big session. This keeps stories fresh and reduces sprint planning time.
Example:
Common pitfalls:
Refining too far ahead (requirements change)
Not refining enough (sprint planning becomes marathon)
Only PO attends (team doesn't understand context)
What works:
Refine 1-2 sprints ahead
Include technical perspectives
Make it collaborative
Focus on clarity, not perfection
The Three Scrum Artifacts
Scrum defines three artifacts - tangible outputs that provide transparency.
1. Product Backlog
What it is: An ordered list of everything that might be needed in the product.
Characteristics:
Dynamic: Constantly evolving
Prioritized: Most valuable items at the top
Estimated: Stories have relative size estimates
Detailed Appropriately: Near-term items detailed, future items vague
My product backlog structure (in Jira):
Backlog prioritization techniques I've used:
MoSCoW:
Must have
Should have
Could have
Won't have (this time)
Value vs. Effort:
High value, low effort = Do first
High value, high effort = Plan carefully
Low value, high effort = Don't do
WSJF (Weighted Shortest Job First):
Business value / Size
Higher score = higher priority
Example prioritization decision:
2. Sprint Backlog
What it is: The subset of the product backlog selected for this sprint, plus a plan for delivering them.
Characteristics:
Committed: Team commits to these items
Visible: Everyone can see it (usually a Scrum board)
Updated Daily: As team makes progress
My sprint board (Jira/GitHub Projects):
Each story card shows:
Title
Assignee(s)
Story points
Acceptance criteria
Related pull requests
WIP (Work in Progress) limits: I prefer limiting WIP to encourage finishing over starting. For a 5-person team:
To Do: No limit
In Progress: Max 5 (one per person)
Review: Max 3
Done: No limit
3. Product Increment
What it is: The sum of all product backlog items completed during this sprint plus increments from previous sprints.
Characteristics:
Working: Functionally complete
Tested: Meets quality standards
Potentially Shippable: Could be released if desired
Definition of Done (DoD):
Every team should define what "Done" means. Here's mine:
Without a clear DoD, "done" becomes subjective and quality suffers.
Example: After Sprint 23, our increment included:
PDF export API (backend)
PDF export button (frontend)
Branded PDF templates
Automated tests for PDF generation
This increment was potentially shippable - we could deploy it to production if desired.
Sprint Metrics I Track
Velocity
What it is: The sum of story points completed per sprint.
How I use it: To predict capacity for future sprints.
Example:
Important: Velocity is for team planning, not performance measurement. Don't compare velocities across teams or use it as a productivity metric.
Burndown Chart
What it is: A chart showing remaining work over time in a sprint.
Ideal: Steady downward trend Reality: Often messy, with work discovered mid-sprint
I don't obsess over burndown charts, but if we're consistently not burning down work, it signals planning or execution issues.
Sprint Goal Achievement
What it is: Did we meet the sprint goal?
Better than: Did we complete all stories?
Example:
Common Scrum Challenges and Solutions
Challenge 1: Scope Creep During Sprint
Problem: New urgent work gets added mid-sprint.
My solution:
Protect sprint commitments - new work goes into backlog
If truly urgent, swap out equal-sized work (don't just add)
Track interruptions and address root causes in retros
Challenge 2: Stories Not Done by Sprint End
Problem: Work spills over to next sprint.
My solution:
Improve estimation through refinement
Break stories into smaller pieces
Address blockers faster in daily standups
Build in buffer (don't commit to 100% capacity)
Challenge 3: Unengaged Stakeholders
Problem: Key stakeholders don't attend sprint reviews.
My solution:
Schedule reviews at convenient times
Keep demos concise and engaging
Share demo recordings for those who can't attend
Demonstrate business value, not just features
Challenge 4: Ceremonial Fatigue
Problem: Team feels meetings are a waste of time.
My solution:
Keep ceremonies timeboxed strictly
Make them valuable (don't go through motions)
Rotate facilitators for freshness
Skip ceremonies when genuinely not needed (but rarely)
Challenge 5: Distributed Teams
Problem: Team members in different time zones or locations.
My solution:
Use video for all ceremonies (not just audio)
Leverage async tools (Slack, Jira comments)
Record sprint reviews for those who can't attend live
Overlap work hours for real-time collaboration
Scrum in Practice: A Sprint Lifecycle
Let me walk through a typical sprint from my experience:
Week 1, Monday - Sprint Planning (9 AM - 11 AM)
PO presents top priority: "Implement user notification settings"
Team asks questions about requirements
We estimate stories using planning poker
Pull 18 points into sprint (our average velocity)
Break down stories into technical tasks
Sprint goal: "Users can configure their notification preferences"
Week 1, Daily Standups (10 AM, 15 min)
Share progress on notification settings backend
Raise blocker: need design mockups for frontend
SM follows up with design team
Week 1, Thursday - Backlog Refinement (2 PM - 3 PM)
Refine stories for next sprint
Add acceptance criteria to reporting features
Estimate new stories from product roadmap
Week 2, Daily Standups
Frontend and backend integration happening
Some stories done, moved to review column
Testing in progress
Week 2, Thursday - Sprint Review (2 PM - 3 PM)
Demo notification settings in staging
Stakeholders provide feedback: "Can we add email preview?"
PO adds new story to backlog for next sprint
16/18 points completed, sprint goal achieved
Week 2, Thursday - Sprint Retrospective (3:30 PM - 4:30 PM)
What went well: Good collaboration, met sprint goal
What needs improvement: Design dependencies slow us down
Action: Include designer in sprint planning next time
Week 2, Friday - Sprint ends, new sprint planning begins Monday
Tools I Use for Scrum
Jira
What I use it for:
Product backlog management
Sprint planning and tracking
Burndown charts and velocity tracking
Scrum board visualization
Setup examples:
GitHub Projects
What I use it for:
Lightweight sprint tracking
Linking stories to pull requests
Kanban-style boards
Why I like it: Tight integration with code repositories.
Confluence
What I use it for:
Sprint retrospective notes
Product roadmap documentation
Architecture decision records
Team knowledge base
Slack
What I use it for:
Daily standup updates (async mode)
Quick clarifications during sprint
Stakeholder communication
Miro/Mural
What I use it for:
Virtual sprint retrospectives
User story mapping
Collaborative refinement sessions
Adapting Scrum to Your Context
Scrum is a framework, not a rigid methodology. I've adapted it based on:
Team Size
Small teams (3-4): Combined Scrum Master and developer roles
Larger teams (8+): Split into multiple scrum teams
Sprint Length
1 week: For fast-moving startups (my preferred when possible)
2 weeks: Standard, works well for most teams
3-4 weeks: For teams with longer integration cycles
Remote vs. Co-located
Remote: More async communication, recorded demos
Hybrid: Flexibility in ceremony format
Co-located: Physical boards, in-person ceremonies
Common Scrum Anti-Patterns
Things I've seen that don't work:
Scrum but no retrospectives: You miss the improvement loop
Scrum Master as project manager: Kills self-organization
Product Owner absent: Team has no direction
No Definition of Done: Quality suffers
Sprint planning without refinement: Planning takes forever
Skipping standups: Team loses synchronization
Adding work mid-sprint freely: Sprint commitments meaningless
Conclusion
Scrum provides structure and rhythm to agile development. After dozens of sprints, I've learned that:
The framework works when:
Roles are clear and respected
Ceremonies are valued, not just tolerated
Artifacts provide transparency
Team embraces empiricism and adaptation
The framework fails when:
It's followed mechanically without understanding
Management uses it for command and control
Team doesn't actually commit to sprint goals
No one has authority to remove impediments
Scrum isn't magic - it's a disciplined approach to iterative development. In the next article, we'll explore Kanban and other agile frameworks, and when to use each.
Key Takeaways
Three roles: Product Owner, Scrum Master, Development Team - each essential
Five ceremonies: Planning, Standup, Review, Retrospective, Refinement
Three artifacts: Product Backlog, Sprint Backlog, Product Increment
Sprints are timeboxed: Usually 1-4 weeks
Sprint goal matters: More than individual stories
Empiricism is key: Inspect and adapt
Customize appropriately: Adapt Scrum to your context
Additional Resources
Scrum Guide - Official Scrum definition
"Scrum: The Art of Doing Twice the Work in Half the Time" by Jeff Sutherland
Scrum.org - Training and certifications
My Jira setup: [Internal wiki link]
Previous: Part 1 - Introduction to Agile Next: Part 3 - Kanban and Other Frameworks
This article is part of the Agile Development 101 series. Check out the series overview for more content.
Last updated