DO NOT USE THIS SITE

Origins

Scrum was formally introduced in 1995 by Ken Schwaber and Jeff Sutherland at the OOPSLA conference, but its philosophical foundation can be traced earlier. The 1986 Harvard Business Review article "The New New Product Development Game"¹ by Takeuchi and Nonaka described a "rugby" style of product development — one that emphasized cross-functional teams moving forward together through overlapping phases of work.

Scrum emerged as a response to traditional, predictive project management models like Waterfall, which assumed that requirements could be fully known upfront. Instead, Scrum embraced uncertainty, drawing on empirical process control theory, Lean manufacturing principles, and practical experience.

Today, Scrum remains a lightweight yet powerful framework for navigating complex work, formalized through The Scrum Guide² and refined by thousands of real-world applications across industries.

Core Foundation: Empiricism

Scrum rests on Empiricism — the belief that knowledge comes primarily from experience and that decisions should be based on what is observed rather than what is predicted.

Scrum operationalizes Empiricism through:

• Transparency: Key aspects of the process must be visible to those responsible for the outcome.
• Inspection: Scrum users frequently inspect artifacts and progress toward the Sprint Goal.
• Adaptation: Adjustments are made quickly to minimize deviation from goals.

Without Empiricism, Scrum's events and artifacts would lose their meaning, becoming hollow ceremonies. With it, Scrum teams stay grounded in reality, able to adapt intelligently as complexity unfolds.

How Scrum is Used

Organizations use Scrum to manage the work of complex product development and increasingly to navigate other forms of knowledge work. Scrum's minimal structure helps teams organize themselves around a clear goal, iterate quickly, and deliver continuous value.

Key characteristics in practice include:

• Small, cross-functional teams that deliver complete increments of value.
• Timeboxed work cycles (Sprints) that encourage fast feedback loops.
• Product Ownership that aligns the team's work with organizational priorities.
• Built-in reflection and adaptation mechanisms through Reviews and Retrospectives.

Scaling Scrum often requires thoughtful coordination across multiple teams, but at its core, Scrum succeeds best in organizations willing to trust small teams to solve hard problems collaboratively.

The Scrum Sprint Cycle (in Depth):

Each Sprint is a heartbeat of Scrum — a short, fixed-length event where a usable increment is created. Sprints reinforce Empiricism by tightly connecting plan, execution, inspection, and adaptation.

The Sprint includes:

1. Sprint Planning:
   • The team collaborates to define what will be delivered (Sprint Goal) and how the work will be done.
2. Sprint Work:
   • Daily development activities, guided by self-organization and the pursuit of the Sprint Goal.
3. Daily Scrum:
   • A daily inspection-and-adaptation event where Developers synchronize their work and adjust plans as needed.
4. Sprint Review:
   • Stakeholders inspect the Increment, provide feedback, and collaboratively adapt the Product Backlog.
5. Sprint Retrospective:
   • The Scrum Team reflects on how it worked together and identifies actionable improvements for the next Sprint.

Important:

• Sprints are consistent in duration (often 2 weeks).
• Once started, a Sprint is not extended or shortened.
• A Sprint Goal gives purpose to the work beyond just completing tasks.

Scrum Roles:

Scrum defines three accountabilities, each vital to healthy empirical practice. These are roles with responsibilities, not job titles:

1. Product Owner

• Focus: Maximizing the value of the product resulting from the Scrum Team's work.
• Key Responsibilities:
  • Managing the Product Backlog.
  • Clearly expressing Product Backlog items.
  • Ensuring the team understands items to the level needed.
  • Making prioritization decisions.
• Characteristics:
  • Acts as the "voice of the customer."
  • Needs sufficient authority to make decisions.

2. Scrum Master

• Focus: Helping everyone understand Scrum theory and practice.
• Key Responsibilities:
  • Coaching the team toward self-management and cross-functionality.
  • Removing impediments.
  • Supporting Product Owner effectiveness.
  • Helping the broader organization understand Scrum.
• Characteristics:
  • A servant leader, not a command-and-control manager.
  • A systems thinker and team coach.

3. Developers

• Focus: Creating a usable Increment each Sprint.
• Key Responsibilities:
  • Selecting work from the Product Backlog during Sprint Planning.
  • Owning how work is completed.
  • Inspecting and adapting their plan daily at the Daily Scrum.
  • Maintaining quality standards.
• Characteristics:
  • Cross-functional (all skills necessary are present within the team).
  • Self-managing (deciding internally how to accomplish goals).

Scrum Artifacts:

Artifacts provide transparency and opportunities for inspection and adaptation.

1. Product Backlog

• Description: An evolving, ordered list of everything known to be needed in the product.
• Attributes:
  • Emergent: Continuously refined as new information surfaces.
  • Prioritized: Managed by the Product Owner.
• Artifact Commitment:
  • Product Goal — the long-term objective for the Scrum Team.

2. Sprint Backlog

• Description: A plan for the Sprint, composed of selected Product Backlog items plus a plan for delivering them.
• Attributes:
  • Owned by Developers.
  • Updated throughout the Sprint as new work emerges.
• Artifact Commitment:
  • Sprint Goal — the single objective for the Sprint.

3. Increment

• Description: A concrete stepping stone toward the Product Goal.
• Attributes:
  • Must meet the Scrum Team's Definition of Done.
  • Multiple Increments can be created in a Sprint, but they must integrate into a coherent whole.
• Artifact Commitment:
  • Definition of Done — the quality standard the Increment must meet to be considered complete.

When to Use Scrum and When Not to Use It:

Scrum is best used when:

• Work is too complex to predict fully upfront.
• Requirements are likely to change as more is learned.
• Collaboration and creativity are essential to success.
• There is organizational commitment to transparency and empowerment.

Scrum is not the best fit when:

• Work is simple, routine, or highly predictable.
• Leadership insists on rigid upfront plans and resists adaptation.
• Teams cannot be cross-functional or self-managing.
• Organizational culture punishes inspection and transparency.

Key Takeaways

• Scrum is built on Empiricism — learning through doing.
• Sprint Cycles allow teams to plan, build, inspect, and adapt rapidly.
• Scrum's Roles create clear accountability without hierarchy.
• Artifacts ensure transparency and guide work toward tangible goals.
• Scrum thrives in complex, changeable environments but can flounder when misunderstood or misapplied.
• Mastering Scrum is less about performing ceremonies and more about living its principles.

Summary

Scrum is a powerful framework for managing complexity, guiding teams to continuously adapt and deliver value. Its strength lies not just in its structure of roles, events, and artifacts, but in the deeper trust it places in teams to work empirically — inspecting reality, adapting intelligently, and delivering excellence incrementally.

Scrum is simple to understand yet difficult to master because it requires deep shifts in mindset, not just changes in workflow. When organizations embrace Empiricism and foster strong Product Ownership, capable Scrum Masters, and empowered Developers, Scrum unlocks creativity, resilience, and sustained innovation.

Recommended Reading

Scrum: The Art of Doing Twice the Work in Half the Time

Buy Now

Scrum Mastery

Buy Now

Essential Scrum: A Practical Guide to the Most Popular Agile Process

Buy Now