Scrum in production

When people talk about “Scrum in production,” they are usually referring to one of two things:

1. Applying Scrum to the “Operations” side of a product (Maintenance, bug fixes, and infrastructure).
2. The process of moving code into a live environment (The “Production” phase of the Software Development Life Cycle).

In a modern DevOps environment, these two are merged. Here is a breakdown of what Scrum looks like when a product is “live.”

1. The Shift: From “Building” to “Running”

In early development, Scrum is about features: “How do we build this new login page?”
In production, Scrum is about reliability and evolution: “How do we keep the site up, fix bugs, and scale for 1 million users?”

To do Scrum in production effectively, the team must balance Innovation (new features) with Stability (keeping the lights on).

2. How Scrum Components change in Production

The Product Backlog (Mixed Priorities)

In a production environment, the backlog is no longer just “New Features.” It must include:

• Bugs: Critical, high, and low-priority issues found by users.
• Technical Debt: Refactoring old code that is causing production slowdowns.
• Infrastructure/SRE Tasks: Scaling servers, updating security protocols, or improving CI/CD pipelines.
• Feature Requests: The standard “new stuff.”

The Sprint (The Capacity Split)

One of the biggest challenges in production is the “Interrupt.” If a server goes down, you can’t finish your Sprint goals. To manage this, many teams use a Capacity Allocation model:

• Example: 60% of the Sprint is for new features, 30% is for production bug fixes/maintenance, and 10% is for “buffer” or unexpected outages.

The Daily Scrum (Status & Health)

Instead of just saying “I finished the button,” the Daily Scrum in production focuses on:

• System Health: “Are we seeing any spikes in error rates?”
• Blockers: “The deployment pipeline is failing; I need help.”
• Triage: “We just got a P1 (Priority 1) bug report; who is handling it?”

Sprint Review & Retrospective (Post-Mortems)

In production, these meetings take on a new flavor:

• Review: You demo the new features, but you also report on SLAs (Service Level Agreements) and uptime.
• Retrospective: This is where Post-Mortems happen. If a production incident occurred during the sprint, the team analyzes why it happened and creates “Action Items” to prevent it in the next sprint.

3. The Role of DevOps in “Scrum in Production”

You cannot have successful Scrum in production without DevOps. The goal is to break down the wall between the “Developers” (who write the code) and the “Operations” (who run the code).

• Continuous Integration/Continuous Deployment (CI/CD): This is the engine of Scrum in production. It allows the team to move a “Done” increment from the Sprint into the live production environment automatically and safely.
• Observability: The team needs dashboards (Grafana, Datadog, etc.) to see the “Increment” performing in the real world.

4. Common Challenges (and Solutions)

Summary

Scrum in production is the practice of using Agile ceremonies to manage the lifecycle of a live product. It requires a balance where the team is constantly delivering new value while simultaneously protecting the integrity of the live environment. It moves the team from “Project” thinking (Done = Launched) to “Product” thinking (Done = Stable and Growing).