What is Scrum?
A lightweight framework for solving complex problems
The Simple Definition
Scrum is a framework β a set of rules and roles β that helps teams work together to build something valuable, step by step. It is especially useful when the work is complex and things can change along the way.
Think of opening a restaurant
You don't build the full restaurant at once. You start with a basic menu, serve customers, gather feedback, and improve week by week. Scrum works exactly like this β build a little, release it, learn, and improve continuously.
Scrum in 4 Steps (Repeated Forever)
The whole of Scrum comes down to this loop:
Sprint 1: Build the login screen β show it to users β users say "add Google sign-in" β Sprint 2 adds Google sign-in β repeat until the app is complete.
Scrum Theory
The three pillars that hold Scrum together
Scrum is built on Empiricism (learn from experience) and Lean Thinking (cut waste, focus on essentials). These give rise to three pillars:
Transparency
Everyone can see the work, the plan, and the progress. Nothing is hidden.
Inspection
Regularly check if the work is going in the right direction.
Adaptation
When something is off, change course quickly before it gets worse.
Transparency: The task board is visible to all β doctors, developers, managers.
Inspection: Every week the team reviews if the app is working correctly for nurses.
Adaptation: Nurses say the font is too small β the team immediately increases font size next Sprint.
Scrum Values
The 5 values that make a Scrum Team truly work
πͺ Commitment
Everyone on the team commits to the Sprint Goal and to helping each other succeed.
A developer is stuck. Another developer, even though they're busy, stops and helps them finish β because the team is committed to the goal together, not just individually.
π― Focus
The team focuses on the Sprint work only, not random tasks or distractions from outside.
A manager asks a developer to fix an unrelated bug mid-Sprint. The Scrum Master blocks this: "That goes into the Product Backlog for the next Sprint. Right now we stay focused."
π€ Openness
The team is honest about their progress and any problems. No hiding issues.
A developer says in the Daily Scrum: "I'm blocked β I underestimated this task. It will take 3 more days." This openness lets the team adjust the plan before it's too late.
π Respect
Team members treat each other as capable adults who know their craft.
The Product Owner doesn't tell developers HOW to write code β they trust them. Developers don't question business priorities β they trust the Product Owner.
π¦ Courage
The team speaks up about hard truths, says no when needed, and tackles the toughest problems.
The team tells the CEO: "This feature cannot be built in 2 weeks. It will take 6 weeks. We will not promise what we cannot deliver." That takes courage β and it's the right thing to do.
The Scrum Team
3 roles, no hierarchy β everyone serves the Product Goal
A Scrum Team is small (typically 10 or fewer people), cross-functional (has all skills needed), and self-managing (decides how to do their own work). There are no sub-teams or managers inside the Scrum Team.
A Scrum Team is like a football squad
Goalkeeper, defenders, attackers β all different skills β but one goal. The coach (Scrum Master) doesn't play, but removes obstacles and coaches. The manager (Product Owner) decides strategy. The players (Developers) decide how to execute on the field.
Product Owner
The Product Owner decides what gets built and in what order. They are the voice of the customer and the business inside the team. There is only ONE Product Owner, not a committee.
- Creates and manages the Product Backlog (the list of all work to be done)
- Decides which features are most important and orders the backlog accordingly
- Defines the Product Goal β the big objective the product is working toward
- Communicates clearly with stakeholders about what is being built and why
The Product Owner listens to customers who say checkout is too slow. They add "speed up checkout" to the top of the Product Backlog so the team works on it next Sprint. They do NOT tell the developers how to speed it up β that's the team's job.
Developers
Developers are everyone who actually creates the product β programmers, designers, testers, writers, etc. (Not just software developers!) They decide how to get the work done.
- Create the Sprint Backlog β a plan for what they'll build this Sprint
- Build working, high-quality Increments every Sprint
- Adapt their daily plan to meet the Sprint Goal
- Hold themselves accountable as professionals
Developers include: 2 backend engineers, 1 frontend engineer, 1 UX designer, 1 QA tester. Together they have all the skills to deliver a complete, working feature. Nobody outside the team tells them which technology to use or how to structure their code.
Scrum Master
The Scrum Master is a servant-leader who makes sure Scrum is followed correctly. They don't manage the team β they coach them, remove blockers, and protect the team from distractions.
- Coaches the team in Scrum practices and self-management
- Removes impediments (blockers) that slow the team down
- Facilitates all Scrum events (keeps them timeboxed and productive)
- Protects the team from outside interruptions
- Trains the organization on how Scrum works
A developer needs access to a production database to test a feature, but the IT security team is taking 2 weeks to approve it. The Scrum Master escalates this to management, gets a temporary solution in place within 1 day, and the Sprint stays on track.
Scrum Events
5 formal events β all inside a Sprint
π The Sprint β The Container
Monday Week 1: Sprint Planning (4 hrs) β Team picks features to build
TueβThu Week 1 & Week 2: Daily Scrum (15 min each day) + actual building
Thursday Week 2: Sprint Review (2 hrs) β Show stakeholders what was built
Friday Week 2: Sprint Retrospective (1.5 hrs) β Discuss how to improve
Monday Week 3: New Sprint begins!
π Sprint Planning
The whole Scrum Team meets at the start of each Sprint to decide what to build and how to build it. Three key questions are answered:
- Why is this Sprint valuable? β Creates the Sprint Goal
- What can be done? β Team picks items from the Product Backlog
- How will the work get done? β Developers break work into daily tasks
Why: "This Sprint we will allow users to pay by credit card" (Sprint Goal)
What: Add payment form, integrate Stripe API, add email receipt
How: Developer A does backend, Developer B does UI, QA tests on Day 8
βοΈ Daily Scrum
A 15-minute daily check-in for Developers only. Same time, same place, every working day. The goal is to inspect progress toward the Sprint Goal and adapt the plan for the next 24 hours.
What did I do yesterday toward the Sprint Goal?
What will I do today toward the Sprint Goal?
Are there any blockers in my way?
Dev A: "Finished the payment form UI. Today I'll connect it to the Stripe API. No blockers."
Dev B: "Stripe API keeps returning errors. Blocked β need help from A after this meeting."
QA: "Will start writing test cases today. No blockers."
π Sprint Review
The team presents the working Increment to stakeholders (managers, customers, users). This is a working session, not just a demo. The Product Backlog is updated based on the feedback.
The team demos the new checkout flow to the CEO and 3 customers. Customers love it but say: "We also want PayPal as an option." The Product Owner adds "Add PayPal" to the Product Backlog for a future Sprint.
π¬ Sprint Retrospective
The last event of the Sprint. The Scrum Team (without stakeholders) reflects on how they worked β not what they built. They inspect processes, tools, relationships, and their Definition of Done to become more effective.
β
What went well this Sprint?
β What didn't go well?
π§ What will we change next Sprint?
β
Went well: Daily Scrums were short and focused
β Didn't go well: Code reviews took 3 days β slowed everyone down
π§ Change: Each PR must be reviewed within 4 hours β we add this as a team rule
Scrum Artifacts
3 visible documents that make work transparent
Scrum Artifacts represent work or value. They ensure everyone has the same information to make good decisions. Each artifact has a commitment β a specific goal that gives it purpose and keeps the team focused.
π Product Backlog
Commitment: Product GoalThe Product Backlog is the single master list of everything that could be done to improve the product. It is ordered by priority β most important at the top. It is never "done" β it keeps growing and changing as the product evolves.
The Product Goal is the big long-term objective. Everything in the Product Backlog should contribute to reaching this goal. The team works toward one Product Goal at a time.
1. (High Priority) User can create a task β currently being worked on
2. User can set due dates on tasks
3. User can share tasks with teammates
4. Dark mode
5. Export tasks to CSV
6. Voice input for tasks
...(50 more items)
Product Goal: "Become the #1 task app for remote teams"
Product Backlog = Your Shopping List
When you go shopping, you have a list of everything you need. The most important items are at the top. You can add or remove items anytime. You don't buy everything in one trip β you prioritize.
π Sprint Backlog
Commitment: Sprint GoalThe Sprint Backlog is the team's plan for the current Sprint. It contains: the Sprint Goal (WHY), the items chosen from the Product Backlog (WHAT), and the detailed tasks (HOW). It is created by Developers and updated daily.
One clear objective for the Sprint. It gives the team focus and flexibility. If unexpected work comes up, the team can adjust the scope β but NOT the Sprint Goal.
Sprint Goal: "Users can sign up and log in securely"
Items (from Product Backlog):
β
Build sign-up form
β
Implement email verification
β
Build login page
β
Add "forgot password" flow
Tasks (created by Developers):
β’ Design mockup for sign-up form (4h)
β’ Write API for user registration (8h)
β’ Write unit tests for auth (6h)
β’ QA testing (4h)
Sprint Backlog = Your Weekly To-Do List
From your big shopping list (Product Backlog), you pick what you'll buy THIS week. Then you also plan which shops to visit and at what time. That's your Sprint Backlog for the week.
π Increment
Commitment: Definition of DoneAn Increment is a real, working, usable piece of the product delivered at the end of each Sprint. Every new Increment adds to all previous ones. An Increment must meet the Definition of Done to count β no half-finished work.
A shared checklist of quality standards that every Increment must meet before it is considered "done." It creates a shared understanding and prevents teams from calling something "done" when it's actually only half-finished.
A feature is "Done" when:
β‘ Code is written and reviewed by a peer
β‘ Unit tests are written and passing
β‘ Feature works in mobile AND desktop browsers
β‘ Deployed to staging environment
β‘ Product Owner has accepted it
β‘ Documentation is updated
If even ONE box is unchecked β it is NOT done, it goes back to the Product Backlog.
After Sprint 3, the Increment includes everything built so far:
Sprint 1: β
User registration
Sprint 2: β
User login + password reset
Sprint 3: β
User profile page
The full Increment = a working app where users can register, log in, and edit their profile. A real user could use it today.
Increment = A Floor of a Building
Each Sprint adds a new floor. Each floor is complete β you could live on it. You don't add the roof before all the floors are done. At any point, what you have is usable.
Quick Cheat Sheet
Everything at a glance
| Item | What it is | One-liner |
|---|---|---|
| Sprint | Event (container) | 1β4 week work cycle |
| Sprint Planning | Event | Decide what to build this Sprint |
| Daily Scrum | Event | 15-min daily sync for Developers |
| Sprint Review | Event | Show stakeholders what was built |
| Sprint Retrospective | Event | Improve how the team works |
| Product Owner | Role | Decides WHAT gets built |
| Developers | Role | Decides HOW it gets built |
| Scrum Master | Role | Removes blockers, coaches Scrum |
| Product Backlog | Artifact | Full list of all work, ordered by priority |
| Sprint Backlog | Artifact | Plan for THIS Sprint only |
| Increment | Artifact | Working product delivered each Sprint |