The Complete Scrum Guide: Framework, Roles, Events & Artifacts
The Complete Scrum Guide
If you need a quick definition for a term, see /management/scrum-glossary/.
Scrum is a lightweight framework that helps people, teams, and organizations generate value through adaptive solutions for complex problems. It is iterative and incremental, founded on empiricism.
Empirical Pillars of Scrum
| Pillar | Description |
|---|---|
| Transparency | The emergent process and work must be visible to those performing and receiving the work |
| Inspection | Scrum artifacts’ progress toward agreed goals must be inspected frequently and diligently to detect potentially undesirable variances or problems |
| Adaptation | If any aspects of a process deviate outside acceptable limits or if the resulting product is unacceptable, the process or materials must be adjusted |
Scrum Values
| Value | Description |
|---|---|
| Commitment | Team members personally commit to achieving the goals of the Scrum Team |
| Focus | Everyone focuses on the work of the Sprint and the goals of the Scrum Team |
| Openness | The Scrum Team and stakeholders agree to be open about all work and challenges |
| Respect | Team members respect each other as capable, independent people |
| Courage | Team members have courage to do the right thing and work on tough problems |
Scrum Team Roles
The Scrum Team is a cohesive unit of self-managing professionals focused on one objective at a time: the Product Goal. Composed of 1 Scrum Master, 1 Product Owner, and Developers. Typically 10 or fewer people.
Product Owner
The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team.
Key Responsibilities:
- Owns the Product Backlog - Maintains and prioritizes all product requirements
- Represents stakeholders - Acts as the voice of everyone with a stake in the project
- Defines product features - Elicits and documents product requirements
- Manages the release plan - Determines when releases happen
- Accountable for ROI - Responsible for return on investment
- Accepts/rejects stories - Decides if work meets acceptance criteria
- Communicates the vision - Ensures everyone understands the product direction
- Defines “Done” - Helps establish the Definition of Done
- Can cancel a Sprint - Has authority to cancel if the Sprint Goal becomes obsolete
Single Wringable Neck: The Product Owner is ultimately accountable for the product’s success!
Scrum Master
The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide within the team and the organization.
Key Responsibilities:
- Owns the Scrum process - Ensures everyone plays by the rules
- Removes impediments - Clears obstacles blocking the team’s progress
- Facilitates communication - Enables collaboration and open communication
- Shields the team - Protects from external interference
- Maintains visibility - Creates transparency, measurement, and accountability
- Servant leader - Leads by serving and empowering the team
- Strong facilitator - Guides meetings and discussions effectively
- Conducts retrospectives - Leads continuous improvement efforts
What the Scrum Master is NOT:
- ❌ Not a project manager
- ❌ Not the team’s boss
- ❌ Not a task assigner
Developers (Team Members)
Developers are people in the Scrum Team who are committed to creating any aspect of a usable Increment each Sprint.
Key Characteristics:
- Cross-functional - Has all skills necessary to create value each Sprint
- Self-organizing - Internally decides who does what, when, and how
- Self-managing - No sub-teams or hierarchies
- Accountable for quality - Responsible for the technical quality of the product
- Committed - Dedicated to creating a usable Increment each Sprint
Key Responsibilities:
- Deliver working software - Creates “Done” increments each Sprint
- Plan and re-plan - Adapts plans as needed during the Sprint
- Technical implementation - Implements User Stories
- Maintain the Sprint Backlog - Tracks and updates their work
- Conduct Sprint Review - Presents completed work to stakeholders
- Inspect & Adapt - Continuously improves their work
Team Structure:
| Aspect | Guideline |
|---|---|
| Size | 5-9 people (typically 10 or fewer including PO and SM) |
| Roles | No set project roles within the team |
| Skills | Cross-functional, able to deliver end-to-end |
| Organization | Self-organizing and self-managing |
Who Does What Summary
| Role | Owns | Accountable For |
|---|---|---|
| Product Owner | Product Backlog | Product value, ROI |
| Scrum Master | Scrum Process | Team effectiveness, Scrum implementation |
| Developers | Sprint Backlog | Increment quality, delivery |
Scrum Events
All Scrum events are time-boxed and provide structured opportunities for Inspection & Adaptation.
The Sprint
The Sprint is the heartbeat of Scrum - a fixed-length container event that includes all other Scrum events and all the work.
| Aspect | Description |
|---|---|
| Duration | 1-4 weeks (2 weeks most common) |
| Consistency | Length remains consistent across sprints |
| Goal | Each Sprint creates a Done Increment that achieves a Sprint Goal |
| Changes | No changes that endanger the Sprint Goal |
| Risk | Shorter sprints limit risk of cost and effort |
At the end of any given Sprint, the Product Owner can initiate a Release.
Sprint Planning
Sprint Planning initiates the Sprint by laying out the work to be performed and determining the Sprint Goal.
| Aspect | Value |
|---|---|
| When | Day 1 of Sprint |
| Duration | Up to 8 hours (for 4-week Sprint) |
| Participants | Scrum Team (PO, SM, Developers) |
| Output | Sprint Backlog |
Three Key Topics:
- Why is this Sprint valuable? - Defines the Sprint Goal, Product Owner proposes how to increase value
- What can be Done this Sprint? - Team selects items from Product Backlog that can be completed
- How will the chosen work get done? - Team breaks items into tasks, creates actionable plan
Two-Part Structure:
First Half:
- Product Owner presents User Stories
- Team selects items they commit to completing
- Discussion of Product Backlog priorities
Second Half:
- Team solely decides how to build
- Tasks created and assigned
- Sprint Backlog produced
- PO available for questions
Daily Scrum (Daily Standup)
A short daily meeting to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary.
| Aspect | Value |
|---|---|
| When | Every working day, same time and place |
| Duration | 15 minutes or less |
| Participants | Developers (others may attend silently) |
| Output | Sprint Backlog adjustments |
Three Questions:
- What have you done since last Daily Scrum?
- What will you do before the next Daily Scrum?
- What obstacles are impeding your work?
Key Points:
- Team members report to each other, not to the Scrum Master
- Opportunity to synchronize work
- Creates actionable plan for next day
- Identifies impediments for the Scrum Master to remove
The Daily Scrum is for the Developers. Others may attend but should remain silent.
Sprint Review
An event held at the end of the Sprint to inspect the outcome with key stakeholders and determine future adaptations.
| Aspect | Value |
|---|---|
| When | End of Sprint (before Retrospective) |
| Duration | Up to 4 hours (for 4-week Sprint) |
| Participants | Scrum Team + Key Stakeholders |
| Output | Product Backlog adjustments |
What Happens:
- Team presents “Done” work to Product Owner and stakeholders
- Functionality not “Done” is NOT shown
- Feedback is generated
- Product Backlog may be reprioritized
- Collaborate on what to do next
- Inspect progress toward the Product Goal
This is NOT just a demo - it’s an inspection and adaptation event.
Sprint Retrospective
The last event of the Sprint held to plan ways to increase quality and effectiveness in upcoming Sprints.
| Aspect | Value |
|---|---|
| When | End of Sprint (after Review) |
| Duration | Up to 3 hours (for 4-week Sprint) |
| Participants | Scrum Team |
| Output | Impactful improvements |
Topics Discussed:
- What went well during the Sprint?
- What problems were encountered?
- How were those problems solved (or not)?
- How can we improve effectiveness?
Focus:
- Maintain the good - Capture positive practices as best practices
- Get rid of the bad - Identify challenges and develop improvement strategies
- Plan improvements - Create actionable items for next Sprint
Output: Impactful improvements to be addressed as soon as possible. May be added to the next Sprint’s Backlog.
Events Summary Table
| Event | Duration* | Participants | Key Output |
|---|---|---|---|
| Sprint | 2-4 weeks | Everyone | Done Increment |
| Sprint Planning | 8 hours | Scrum Team | Sprint Backlog |
| Daily Scrum | 15 minutes | Developers | Plan adjustments |
| Sprint Review | 4 hours | Team + Stakeholders | Backlog adjustments |
| Sprint Retrospective | 3 hours | Scrum Team | Improvements |
*Timeboxes shown are for a 4-week Sprint. Shorter Sprints have proportionally shorter events.
Scrum Artifacts
Scrum artifacts represent work or value and provide transparency and opportunities for inspection and adaptation. Each artifact has a commitment that brings focus.
Product Backlog
An emergent, ordered list of what is needed to improve the product.
| Aspect | Description |
|---|---|
| Owner | Product Owner |
| Commitment | Product Goal |
| Nature | Dynamic, always changing |
| Order | Prioritized by Business Value |
What It Contains:
- ✅ All desired product features
- ✅ Bugs and defects
- ✅ Non-functional requirements
- ✅ Technical debt items
- ✅ User Stories
Key Points:
- Single source of work for the Scrum Team
- Items can be added by anyone at anytime
- Each item should have a business value assigned
- May change due to changes in business, market, or technology
- Product Owner is responsible for prioritizing
Refinement: The activity in which the Product Owner and Developers add detail to the Product Backlog. Items that can be Done in one Sprint are deemed “Ready” for selection in Sprint Planning.
Sprint Backlog
A plan by and for the Developers on what work they plan to accomplish during the Sprint to achieve the Sprint Goal.
| Aspect | Description |
|---|---|
| Owner | Developers |
| Commitment | Sprint Goal |
| Created | During Sprint Planning |
| Updated | Throughout the Sprint |
What It Contains:
- Sprint Goal (why) - The single objective for the Sprint
- Selected Product Backlog Items (what) - Items chosen for the Sprint
- Actionable Plan (how) - Tasks for delivering the Increment
Key Points:
- Contains all committed User Stories for the current Sprint
- Stories broken down into Tasks by the team
- All items should be developed, tested, documented, and integrated
- A forecast by the Developers about what will be in the next Increment
- Makes work in the Sprint transparent
- Modified during the Sprint as more becomes known
Product Increment
A concrete stepping stone toward the Product Goal. It is not just what you did last Sprint—it is the whole product.
| Aspect | Description |
|---|---|
| Owner | Scrum Team |
| Commitment | Definition of Done |
| When | Created every Sprint |
| State | Usable and inspectable |
Key Points:
- A body of inspectable, usable, and Done work
- Sum of all Product Backlog items Done during a Sprint AND increments of previous Sprints
- Must meet the Definition of Done
- Work not meeting Definition of Done is returned to the Product Backlog
“DONE” = Potentially Shippable!
Commitments
Each artifact has a commitment that brings transparency and focus.
Product Goal
Commitment for: Product Backlog
| Aspect | Description |
|---|---|
| Definition | Describes a future state of the product |
| Purpose | Serves as a target for the Scrum Team to plan against |
| Scope | Single long-term objective |
| Active Goals | Only ONE Product Goal is active at a time |
The Increment is a step towards a Product Goal.
Sprint Goal
Commitment for: Sprint Backlog
| Aspect | Description |
|---|---|
| Definition | The single objective for the Sprint |
| Created | During Sprint Planning |
| Creator | The Scrum Team |
| Purpose | Provides focus, flexibility, and purpose |
Every Sprint MUST have a Sprint Goal!
A good Sprint Goal explains why the work in the Sprint Backlog is valuable.
Definition of Done
Commitment for: Product Increment
| Aspect | Description |
|---|---|
| Definition | Formal description of the state of the Increment when it meets quality measures |
| Created by | The Scrum Team |
| Purpose | Provides transparency on quality |
Work is not part of an Increment unless it meets the Definition of Done.
User Stories & Estimation
User Stories
A very high-level definition of what the customer wants the system to do.
Story Format:
As a <role> I want to <action> so that <value>
Example:
As a user, I want to print a recipe so that I can cook it.
Good Stories Should Be (INVEST)
| Letter | Attribute | Description |
|---|---|---|
| I | Independent | Not dependent on other stories |
| N | Negotiable | Details can be discussed |
| V | Valuable | Provides value to stakeholders |
| E | Estimatable | Can be sized |
| S | Small | Can be completed in one Sprint |
| T | Testable | Clear acceptance criteria |
Related Acronyms
SMART Requirements: Simple, Measurable, Achievable, Realistic, Traceable
TECH Tasks: Time-boxed, Everybody (can pick it up), Complete, Human-readable
Story Points
A relative measure of complexity for a story.
| Aspect | Description |
|---|---|
| Scale | Usually Fibonacci: 1, 2, 3, 5, 8, 13 |
| Type | Relative measure (not hours) |
| Purpose | Initial estimation of effort |
Example:
- “Send to a Friend” feature = 2 Story Points
- “Shopping Cart” feature = 9 Story Points
Velocity
The rate at which a team converts items to “Done” in a single Sprint. Usually calculated in Story Points. Used for forecasting and planning.
Team Capacity
Capacity = # Teammates × (Productive Hours × Sprint Days)
Example:
- Team size: 4
- Productive hours/day: 5
- Sprint length: 30 days
- Capacity = 4 × (5 × 30) = 600 hours
Account for vacation time during the Sprint!
Supporting Tools
Burndown Chart
A chart showing how much work remains in a Sprint. Calculated in hours remaining, maintained by Scrum Master daily.
Burn Up Chart
Demonstrates visually how many points the team got “Done”.
Task Board
A visible board containing Sprint goals, backlog items, tasks (To Do, In Progress, Done), and daily Sprint Burndown Chart. Scrum meetings are best held around the task board. Visible to everyone!
Artifacts Summary
| Artifact | Owner | Commitment | Contains |
|---|---|---|---|
| Product Backlog | Product Owner | Product Goal | All desired work |
| Sprint Backlog | Developers | Sprint Goal | Work for this Sprint |
| Increment | Scrum Team | Definition of Done | Working product |
Visibility + Flexibility = Scrum