Learning Scrum by Making Decisions: Introducing Sprint Panic!

Scrum is easy to describe. It is considerably harder to understand.

A learner can memorize the accountabilities, events, artifacts, and commitments in a relatively short time. They can learn that a Sprint has a Sprint Goal, that Developers adapt the Sprint Backlog, that a Daily Scrum is held every working day, and that a Sprint Review involves stakeholders.

Yet this does not necessarily prepare someone to answer the questions that appear when a real Sprint becomes messy.

What happens when a Developer gets sick? What should happen when a critical library releases a security update in the middle of the Sprint? Should a newly discovered technical task become part of the Sprint Backlog? What happens when work is almost complete but a defect prevents it from meeting the Definition of Done? Should the team start another item or swarm on the work already in progress?

These decisions are where Scrum starts becoming interesting.

From knowing Scrum to experiencing Scrum

Sprint Panic! is a small browser game designed around this problem.

The player manages a Scrum Team developing an intentionally absurd product: an interplanetary pizza-delivery application for customers on Mars.

The Product Goal is simple:

Enable a person on Mars to choose, pay for, and track a pizza with confidence.

The player goes through four simulated Sprints. Each Sprint includes Planning, several simulated working days, Daily Scrums, a Sprint Review, and a Retrospective.

The game is deliberately short. A complete session should fit into a classroom exercise, workshop, or individual learning session rather than becoming a long project-management simulation.

But the main objective is not to reproduce Scrum mechanically. It is to force decisions.

The Sprint Goal is more important than finishing everything

At the beginning of each Sprint, the player chooses a Sprint Goal and selects Product Backlog Items.

The simulation then introduces a tension that experienced teams know well: the Sprint Goal matters more than simply completing the largest possible number of disconnected items.

A team may discover that its capacity is lower than expected. New technical work may appear. An infrastructure problem may consume part of a day.

The relevant question becomes: What should the Developers change while preserving the Sprint Goal?

This also helps address a common misunderstanding: the Sprint Backlog is not a frozen contract created during Sprint Planning. It is a plan by and for the Developers, and it evolves as more is learned.

The Daily Scrum is not a status meeting

One of the most important design choices in Sprint Panic! concerns the Daily Scrum.

The game does not ask each virtual Developer to report what they did yesterday, what they will do today, and what is blocking them. Instead, the player is given a situation.

Perhaps too many items are in progress. Perhaps one item is close to Done while several others have just started. Perhaps unexpected technical work has appeared. Perhaps everything is actually going well.

The player then chooses whether the team should reduce work in progress, swarm on an item, update the Sprint Backlog, protect quality, focus more strongly on the Sprint Goal, or simply continue with the current plan.

The important lesson is that inspection does not require change for the sake of change. A Daily Scrum may conclude that the existing plan is still appropriate.

Emergent technical work should be visible

Imagine that the team is implementing orbital payment and discovers that the authentication mechanism of an external API has changed.

That work should not magically disappear inside the original estimate. Sprint Panic! can create a new technical item in the Sprint Backlog:

Orbital Payment
└── Update API Authentication

The same mechanism is used for defects, integration problems, expired certificates, security patches, flaky tests, and other forms of emergent work.

This makes an important concept visible: learning during development changes the plan.

Done means Done

The simulation treats the Definition of Done as a real constraint.

A Product Backlog Item that has been implemented but still has a blocking defect or unfinished integration work cannot simply become Done.

The game therefore creates an uncomfortable but useful situation: something may look almost complete while still producing no usable Increment.

The player can sometimes take shortcuts, but those decisions create consequences such as technical debt, lower quality, or reduced stakeholder trust.

Flow practices without pretending they are Scrum rules

Sprint Panic! also introduces practices that are common in Agile environments but are not prescribed by the Scrum Guide.

For example, the simulation uses a suggested WIP limit, swarming, velocity, Burndown, Burnup, and a Cumulative Flow Diagram.

The distinction is intentional. A learner should not leave the game believing that story points, velocity, WIP limits, or Burndown charts are mandatory parts of Scrum. They are tools that may help a team.

In the simulation, the team has three Developers and normally performs best with only a small number of items simultaneously in progress. When one item reaches Done, available Developers can pull the next priority item or swarm on existing work.

The model is simplified, but the simplification creates something that can be discussed: Why did reducing WIP help? Why did opening more work make delivery slower? Why should velocity be used for forecasting rather than as a productivity target?

Things go wrong

Starting with the second Sprint, the environment becomes less friendly.

Events may include team illness, power outages, Internet or VPN failures, broken equipment, expired certificates, CI limitations, flaky automated tests, merge conflicts, new library releases, security patches, and incompatible major versions.

Some events are harmful. Others are opportunities.

A bug-fix release of a dependency may be worth adopting immediately. A Release Candidate containing an attractive feature may not be. A critical security update creates a very different decision from an optional major-version migration.

There is deliberately no generic answer such as “always update” or “never change dependencies during a Sprint.” The player must consider the Sprint Goal, risk, quality, and available capacity.

The Sprint Review changes the future

Sprint Review decisions focus on evidence about the product.

Stakeholders may reveal that customers abandon an order when they cannot see an estimated delivery time. They may request a visually attractive feature with little evidence of value. Accessibility may suddenly become a release condition.

The question is not whether the stakeholder is “right.” The question is what this new information means for the Product Backlog and progress toward the Product Goal.

The Review therefore becomes an inspection and adaptation event rather than a ceremonial demonstration.

A game is a conversation starter

Sprint Panic! is not intended to be a Scrum simulator capable of predicting real software projects.

Its numbers are artificial. Its Developers are simplified. Its velocity is calibrated. Its work items are pizzas, orbital payments, and Martian addresses.

That is deliberate.

The purpose of the model is not to reproduce reality perfectly. The purpose is to create decisions that make Scrum concepts discussable.

After a game, a facilitator can ask:

• Why was the Sprint Goal achieved or missed?
• Which Daily Scrum decision changed the outcome?
• When should the team have reduced WIP?
• Which technical work needed to become visible?
• Was accepting technical debt ever justified?
• Which stakeholder feedback should reorder the Product Backlog?
• Which metrics were useful, and which could become dangerous if treated as targets?

Those conversations are arguably more valuable than the score itself.

Try it, break it, and improve it

Sprint Panic! is implemented as a single HTML file. There is no server, installation process, external library, or account. It can run locally and offline, which makes it easy to use in classrooms and workshops.

The interface is available in Portuguese, English, Spanish, French, and Italian.

The project is being developed openly, and the intention is for Scrum educators, trainers, practitioners, students, and curious teams to use it, challenge its assumptions, suggest new events, improve its translations, and experiment with it.

Scrum is fundamentally about learning through inspection and adaptation. Perhaps learning Scrum should work the same way.