Scrum

Complex work rarely goes to plan. Requirements change, technical problems appear and customers react in ways nobody predicted. Scrum is designed for exactly that kind of work. Instead of planning a whole project upfront, a Scrum team works in short, fixed-length cycles called Sprints, usually one to four weeks long. In each Sprint it delivers a usable piece of the product, shows it to stakeholders, reflects on how it worked and adjusts both the product and its process for the next Sprint. Progress is measured by working results rather than by documents and status reports. Each Sprint is a small, complete cycle of planning, building, reviewing and improving.

Scrum was developed by Ken Schwaber and Jeff Sutherland, who first presented it in 1995, drawing on a 1986 Harvard Business Review article by Hirotaka Takeuchi and Ikujiro Nonaka that compared high-performing product teams to a rugby scrum. The official rules are set out in the Scrum Guide, last updated in 2020, which is deliberately short. Scrum is the most widely used agile framework in software development and is increasingly used in marketing, operations and other fields. For delivery teams, product owners, Scrum Masters and the managers who support them, Scrum provides a simple structure for delivering value in uncertain conditions.

Definition of Scrum

Scrum is a framework for developing, delivering and sustaining complex products, in which a Scrum Team of a Product Owner, a Scrum Master and Developers works in Sprints, using the events of Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective, and the artifacts of Product Backlog, Sprint Backlog and Increment.

Its accountabilities include the Scrum Master and the Product Owner, its events are described under agile ceremonies and it is often compared in Kanban vs Scrum.

Roles, Events and Artifacts

The Scrum Team usually has 10 or fewer people. The Product Owner maximizes the value of the product and manages the Product Backlog. The Scrum Master helps the team and organization use Scrum effectively. Developers do the work of creating each Increment.

The Sprint contains all other events. Sprint Planning sets the Sprint Goal and plan, the Daily Scrum is a 15-minute check on progress toward the goal, the Sprint Review inspects the outcome with stakeholders and the Sprint Retrospective improves how the team works.

The Product Backlog is an ordered list of what is needed to improve the product, linked to a long-term Product Goal. The Sprint Backlog contains the Sprint Goal and the selected work. The Increment is the usable result, which must meet the Definition of Done.

Pillars and Values

Scrum rests on three pillars: transparency, so the work and progress are visible; inspection, so the team regularly checks progress and results; and adaptation, so it adjusts when something is off course.

The Scrum Guide also names five values: commitment, focus, openness, respect and courage. They describe the behavior that makes the pillars work.

Without these values, the events become empty rituals, which is one of the most common reasons Scrum adoptions disappoint. The Scrum Guide describes Scrum as purposefully incomplete. It defines only the parts needed to put empiricism into practice and leaves the rest to the team.

Importance of Scrum in Delivery and Engineering Operations

Scrum delivers value early and often. Usable increments every few weeks let customers benefit sooner and let the team learn what really matters.

It reduces risk. Frequent inspection exposes problems while they are small, and the short Sprint limits how much work can go in the wrong direction.

It also creates a predictable rhythm. Regular events give stakeholders clear moments to see progress and influence priorities, without interrupting the team constantly.

Scrum and Financial Management

Delivering working increments lets organizations start realizing returns before a full product is finished.

Frequent reviews allow funding decisions to change direction or stop work early when it is not delivering value, avoiding sunk costs.

Stable Scrum teams with known capacity make it easier to estimate what a given budget will deliver over time.

The events take time, typically a modest share of each Sprint, which is an investment in coordination and improvement rather than overhead to be cut.

Common Challenges

Teams often adopt the events without the empiricism, holding stand-ups and reviews while plans and scope are still fixed by others.

The Product Owner role is frequently weak, with too little authority or availability to make decisions, which slows the team.

Organizations sometimes use velocity and Sprint commitments as targets for pressure, which encourages inflated estimates and cut corners. Teams missing key skills, such as testing or design, cannot deliver a done increment each Sprint and end up depending on others.