Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.

Characteristics:

• Lightweight framework, simple to understand
• Difficult to master
• Based on empiricism and lean thinking
• Iterative and incremental

Scrum is founded on empiricism, which asserts that knowledge comes from experience and making decisions based on what is observed.

Three Pillars:

1. Transparency - The emergent process and work must be visible
2. Inspection - The artifacts and progress must be inspected frequently
3. Adaptation - Adjust when necessary to minimize further deviations

Successful use of Scrum depends on people internalizing five values:

• Commitment - Personally commit to achieving Sprint goals
• Focus - Focus on the Sprint work to make the best possible progress
• Openness - Be open about the work and challenges
• Respect - Respect each member's capabilities and independence
• Courage - Have courage to do the right thing and work on tough problems

Scrum also follows lean thinking principles:

Principles:

• Eliminate waste - Focus on what brings value
• Amplify learning - Fast iterations and feedback
• Decide as late as possible - Keep options open
• Deliver as fast as possible - Short cycles
• Empower the team - Self-management
• Build integrity - Quality from the start
• See the whole - Systemic product vision

Scrum is specifically designed for complex problems.

Types of Work:

• Simple: Repetitive processes, known solutions
• Complicated: Requires specialized analysis, but predictable
• Complex: Uncertain, unpredictable, requires experimentation

Why Scrum for Complexity?

• Allows frequent inspection and adaptation
• Facilitates learning through experience
• Reduces risk through incremental delivery

All Scrum events are timeboxed (have a fixed maximum duration).

Maximum Durations (1-month Sprint):

• Sprint: 1 month or less
• Sprint Planning: 8 hours
• Daily Scrum: 15 minutes
• Sprint Review: 4 hours
• Sprint Retrospective: 3 hours

Why Timeboxes?

• Creates rhythm and consistency
• Avoids infinite meetings
• Forces focus and efficiency
• Proportional for shorter Sprints

A product is a vehicle of value to deliver to stakeholders.

Types of Products:

• Software or website
• Service
• Physical product
• A combination of all above

Product Goal:

• Describes a future state of the product
• The team focuses on one goal at a time
• Must be achieved before starting another
• Provides long-term direction

Multiple Increments can be created within a Sprint.

Rules:

• Each Increment must be "Done"
• All Increments are presented at Sprint Review
• Sum of Increments creates cumulative value
• An Increment can be delivered to stakeholders

Benefits:

• More frequent feedback
• Continuous value delivery
• Risk reduction

Note: The Product Owner may decide to deliver Increments immediately.

Stakeholders are people outside the Scrum Team with an interest in the product.

Engagement:

• Participate in Sprint Review
• Can provide feedback on the Increment
• Not part of team decisions
• Product Owner represents their interests

Examples:

• Customers and users
• Management and executives
• Marketing team
• Investors

Transparency in Scrum enables effective inspection and adaptation.

Common Metrics:

• Burndown Chart: Remaining work over time
• Burnup Chart: Completed work over time
• Velocity: Average work per Sprint
• Cumulative Flow: Item status in workflow

Importance:

• Help predict future delivery
• Identify problems early
• Support data-driven decisions

Note: The Scrum Guide does not require specific metrics.

Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint.

Responsibilities:

• Create a plan for the Sprint (Sprint Backlog)
• Instill quality by adhering to a Definition of Done
• Refine their plan daily (Daily Scrum)
• Hold each other accountable as professionals

Note: There are no sub-titles or hierarchies among Developers.

The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team.

Responsibilities:

• Develop and explicitly communicate the Product Goal
• Create and clearly communicate Product Backlog items
• Order Product Backlog items
• Ensure the Product Backlog is transparent and understood

Important: One person, not a committee. May represent stakeholder needs, but final decisions are theirs.

The Scrum Master is accountable for the Scrum Team's effectiveness.

Responsibilities:

• Guides the Scrum Team in effectiveness and self-management
• Removes impediments to the team's progress
• Facilitates Scrum events as needed
• Coaches the team in Scrum context

For the Organization:

• Leads and guides the organization in Scrum adoption
• Plans and advises implementations
• Helps employees understand Scrum

The Scrum Team is a cohesive unit of professionals focused on one objective.

Characteristics:

• Self-managing - Decides internally who does what, when, and how
• Cross-functional - Has all skills needed
• No hierarchies - No sub-titles or divisions

Size:

• 3-9 Developers
• 1 Product Owner
• 1 Scrum Master
• Total: 5-11 people

Scrum Guide 2020 uses "accountabilities" instead of "roles".

Why the Change?

• "Accountability" emphasizes responsibility and ownership
• Avoids confusion with traditional hierarchical titles
• Focuses on what the person is responsible for delivering

Differences:

• Traditional role: "I am a tester" (function description)
• Accountability: "I am accountable for quality" (responsibility)

Note: All Developers are equally accountable for creating the Increment.

The Product Owner is accountable for maximizing product value.

Maximization Techniques:

• Backlog Ordering: Highest value items at top
• ROI Analysis: Return on investment
• Stakeholder Validation: Frequent feedback
• Value Metrics: KPIs and OKRs

PO Decisions:

• What to build first
• What not to build
• When to release
• When to pivot

Note: The PO can delegate work, but not accountability.

The Scrum Master is a servant leader for the Scrum Team.

Leadership Style:

• Serves the team, doesn't command
• Facilitates instead of directing
• Removes impediments
• Protects the team from interruptions

What they DON'T do:

• ❌ Not a project manager
• ❌ Doesn't assign tasks
• ❌ Doesn't report status to management
• ❌ Doesn't make technical decisions

Developers should have a complementary set of skills.

Types of Skills:

• Programming: Frontend, backend, mobile
• Testing: Manual, automated, QA
• Design: UX/UI, architecture
• Analysis: Requirements, business
• DevOps: CI/CD, infrastructure

T-Shaped Professionals:

• Deep expertise in one area
• Broad knowledge across multiple areas
• Ability to collaborate on different tasks

While each role has specific accountabilities, there are shared responsibilities.

Whole Team Shares:

• Product quality: Everyone responsible
• Continuous improvement: Kaizen mindset
• Communication: Transparent and open
• Problem solving: Collaborative

Unique Accountabilities:

• PO: What and why (value)
• SM: Scrum process
• Devs: How to build

How traditional roles map to Scrum:

Common Mapping:

• Project Manager → Splits between PO and SM
• Team Lead → Senior Developer (no title)
• Business Analyst → PO or Developer
• Tester → Developer with testing skill
• Designer → Developer with design skill

Principle:

• No sub-titles among Developers
• Everyone is equally "Developer"
• Specializations are skills, not titles

The Sprint is the container for all other events. It is a fixed-length event of one month or less to create consistency.

Characteristics:

• Fixed length (typically 2-4 weeks)
• A new Sprint starts immediately after the previous one
• No changes are made that would endanger the Sprint Goal
• Quality does not decrease
• The Product Backlog is refined as needed

Cancellation: Only the Product Owner can cancel a Sprint.

Sprint Planning initiates the Sprint by laying out the work to be performed.

Duration:

Maximum of 8 hours for a one-month Sprint (proportional for shorter Sprints).

Three Topics:

1. Why is this Sprint valuable? → Define the Sprint Goal
2. What can be done? → Selects Product Backlog items
3. How will the chosen work get done? → Plans the tasks

Outcome:

Sprint Backlog created with Sprint Goal, selected items, and action plan.

The Daily Scrum is a 15-minute daily event for the Developers of the Scrum Team.

Purpose:

• Inspect progress toward the Sprint Goal
• Adapt the Sprint Backlog as necessary
• Adjust upcoming planned work

Format:

Held at the same time and place every working day. Only Developers actively participate.

Typical Structure (not mandatory):

• What did I do yesterday?
• What will I do today?
• What impediments do I have?

The Sprint Review inspects the outcome of the Sprint and determines future adaptations.

Duration:

Maximum of 4 hours for a one-month Sprint.

Activities:

• Product Owner communicates what was completed and what was not
• Team demonstrates completed work and answers questions
• Inspect what was accomplished and the current environment
• Adapt the Product Backlog as needed

Note: It's not just a demo! It's a collaborative working session.

The Sprint Retrospective plans ways to increase quality and effectiveness.

Duration:

Maximum of 3 hours for a one-month Sprint.

Objectives:

• Inspect how the last Sprint went (people, interactions, processes)
• Identify what went well and what could improve
• Create an improvement plan for the next Sprint

Focus:

The team identifies the most useful and impactful improvements and adapts the Definition of Done if needed.

The Product Backlog is an emergent, ordered list of what is needed to improve the product.

Characteristics:

• Single source of work for the Scrum Team
• Emergent - never complete
• Ordered - highest value items at the top
• Detailed enough for Sprint Planning

Commitment: Product Goal

Describes a future state of the product. The team must achieve (or abandon) one goal before taking on the next.

The Sprint Backlog consists of the Sprint Goal, selected Product Backlog items, and the action plan.

Characteristics:

• Created during Sprint Planning
• Real-time, visible plan of the work
• Updated throughout the Sprint
• Detailed enough for Daily Scrum

Commitment: Sprint Goal

Single objective for the Sprint. Provides direction and motivation. Can be refined during the Sprint as long as it's not endangered.

An Increment is a concrete stepping stone toward the Product Goal.

Characteristics:

• Made of all completed work from the Sprint
• Each Increment is additive to all prior ones
• Must be usable and functional
• Can be delivered to stakeholders

Commitment: Definition of Done

Formal description of the state of the Increment when it meets quality measures. If an item is not "Done", it cannot be presented at Sprint Review.

The Product Goal is the commitment to the Product Backlog.

Characteristics:

• Describes a future state of the product
• The team can pursue only one goal at a time
• Must be achieved or abandoned before starting another
• Provides long-term direction

Examples:

• "Launch beta version to external users"
• "Reach 10,000 active users"
• "Implement complete payment system"

The Definition of Done (DoD) is the commitment to the Increment.

Purpose:

• Creates transparency about what is complete
• Ensures consistent quality
• Avoids "almost ready" or "90% done"

Example DoD:

• ✅ Code peer-reviewed
• ✅ Unit tests pass
• ✅ Integration tests complete
• ✅ Documentation updated
• ✅ Deployed to staging environment

Note: If multiple teams work on the same product, they must define and adhere to the same DoD.

Rules:

• Developers: 3-9 people
• Product Owner: 1 person
• Scrum Master: 1 person

Total: 5-11 people in the Scrum Team.

Why these limits?

• Smaller teams → less interaction and reduced productivity
• Larger teams → too much coordination complexity

Note: If the team is too large, consider splitting into multiple cohesive Scrum Teams sharing the same Product.

The Scrum Team is self-managing and cross-functional.

Self-managing means:

• The team decides who does what
• The team decides when to do it
• The team decides how to do it

Cross-functional means:

• The team has all skills needed
• Does not depend on people outside the team
• Each member can contribute to different areas

Important: The Scrum Master does not assign tasks to Developers!

Refinement is the act of adding detail, estimates, and order to Product Backlog items.

Activities:

• Break large items into smaller ones
• Add clear descriptions and acceptance criteria
• Estimate effort (if the team uses estimates)
• Reorder based on new information

When it happens:

It's an ongoing activity, not a formal event. Typically consumes up to 10% of Sprint capacity.

A Sprint can be cancelled only by the Product Owner.

When to cancel:

• The Sprint Goal becomes obsolete
• Changes in market conditions
• Changes in company strategic direction
• Technology has become obsolete

What happens:

• Completed items are reviewed and accepted
• Incomplete items return to the Product Backlog
• A new Sprint Planning is conducted

Note: Cancellations are rare and disruptive. Should be avoided.

When multiple Scrum Teams work on the same product:

Rules:

• All share the same Product Goal
• All share the same Product Backlog
• All share the same Definition of Done
• Each team creates Increments that are part of the whole

Coordination:

• May need synchronization between teams
• Scrum Masters may coordinate work
• Avoid excessive dependencies between teams

Important: There is no official "Scrum of Scrums" in the Scrum Guide.

Common mistakes that break Scrum:

Anti-Patterns:

• ❌ Sprint as mini-waterfall: Design → Dev → Test in sequence
• ❌ Scrum Master as boss: Assigns tasks instead of facilitating
• ❌ Absent Product Owner: Not available to the team
• ❌ Daily as reporting: Reporting to manager instead of planning
• ❌ Retrospective ignored: No improvements implemented
• ❌ Weak Definition of Done: Allows bugs in production

How to Avoid:

• Follow the Scrum Guide rigorously
• Constant inspection and adaptation
• Continuous team education

The Sprint Goal is created during Sprint Planning.

How to Create:

• Identify the business objective
• Be specific but not too detailed
• Focus on value, not tasks
• Be achievable within the Sprint

Good Examples:

• ✅ "Enable users to log in"
• ✅ "Process online payments"

Bad Examples:

• ❌ "Complete 15 user stories"
• ❌ "Work on backend"

The Scrum Guide doesn't mention User Stories, but they are widely used.

User Story Template:

As [type of user], I want [action], to [benefit]

Other Formats:

• Bugs and defects
• Technical (refactoring)
• Investigation spikes
• Improvements

INVEST Criteria:

• Independent
• Negotiable
• Valuable
• Estimable
• Small
• Testable

Scrum doesn't require estimates, but they are often used.

Popular Methods:

• Planning Poker: Fibonacci cards
• T-Shirt Sizes: XS, S, M, L, XL
• Story Points: Relative effort
• Ideal hours: Time without interruptions

Best Practices:

• Estimate as a team, not individually
• Use past items as reference
• Re-estimate when needed
• Don't use estimates as performance metric

Continuous improvement is central to Scrum.

Where it Happens:

• Sprint Retrospective: Main improvement event
• Daily Scrum: Daily adjustments
• Refinement: Backlog improvement

Types of Improvement:

• Processes and tools
• Product quality
• Communication and collaboration
• Skills and competencies

PDCA Cycle:

• Plan - Plan change
• Do - Implement
• Check - Verify results
• Act - Adjust and standardize

Impediments are obstacles that prevent the team from progressing.

Common Examples:

• Lack of system access
• Dependencies on other teams
• Unclear requirements
• Technical problems
• External interruptions

Who Resolves:

• Scrum Master: Removes impediments
• Developers: Can resolve some internally
• Product Owner: Clarifies requirements

Visualization:

Use an Impediment Board to track status.

In Scrum, work is either "Done" or it doesn't count.

Rules:

• ✅ 99% complete = not complete
• ✅ "Almost ready" = not ready
• ✅ Tests failing = not Done
• ✅ No code review = not Done

At Sprint Review:

• Only "Done" work is demonstrated
• "Undone" work returns to Product Backlog
• No partial credit

Mindset: Better to deliver less 100% Done than more 80% Done.

Scrum can be scaled to large organizations.

Challenges:

• Coordination between multiple teams
• Complex dependencies
• Organizational culture
• Governance and compliance

Scaling Frameworks:

• Scrum@Scale
• LeSS (Large Scale Scrum)
• SAFe (Scaled Agile Framework)
• Nexus

Note: These are not part of the official Scrum Guide.

Scrum and DevOps are highly complementary.

Synergies:

• CI/CD: Continuous Increment delivery
• Automation: Supports Definition of Done
• Monitoring: Fast feedback
• Infrastructure as Code: Reproducibility

Benefits:

• Faster value delivery
• Better quality
• Faster feedback
• Less deployment risks

Note: DevOps is not mentioned in the Scrum Guide, but widely adopted.

Quick checklist to validate Scrum:

Events:

• ✅ Fixed-length Sprints?
• ✅ 15-minute Daily?
• ✅ Sprint Review with stakeholders?
• ✅ Retrospective with improvement actions?

Artifacts:

• ✅ Ordered Product Backlog?
• ✅ Sprint Goal defined?
• ✅ Definition of Done met?

Roles:

• ✅ PO available and dedicated?
• ✅ SM facilitates without commanding?
• ✅ Self-managing team?

If you answered "no" to any, there's room for improvement!