Planning Poker for DevOps and Platform Engineering Teams: Estimating Infrastructure Work

Platform engineering and DevOps teams occupy an awkward position in most agile organizations. They run sprints, hold retrospectives, and maintain a backlog — but the estimation playbook written for product feature teams often breaks down fast.

A story like "Add persistent volume support for the staging cluster" doesn't have acceptance criteria the way a user-facing feature does. An SRE task like "Investigate intermittent 502s on the API gateway" has unknown scope by definition. A runbook improvement that prevents the next 3 AM page is hard to size against a billing feature.

The pressure to estimate is real regardless. Platform teams need to forecast capacity, justify headcount, and make credible commitments to their internal customers. Planning poker is still the right tool — it just needs calibrating for the infrastructure context.

Why Infrastructure Work Is Harder to Estimate

Before adapting the process, it helps to name why standard estimation fails for platform and DevOps teams:

Work is reactive by nature. A significant chunk of the platform team's week gets consumed by incidents, urgent product team requests, and production anomalies. This unpredictability makes sprint commitments feel like fiction.

Scope reveals itself during execution. Upgrading Kubernetes from 1.28 to 1.30 sounds bounded until you discover three deprecated APIs your workloads depend on. Infra work regularly uncovers unknown unknowns.

There is no "user story" structure. Infrastructure tickets describe technical outcomes, not user journeys. The "As a [user] I want [feature] so that [benefit]" format rarely applies, which makes it harder for the team to anchor on a shared mental model before voting.

Work types are wildly heterogeneous. A single sprint might include a Terraform module refactor, a CVE patch, a database upgrade, a new observability dashboard, and a cost optimization analysis — different in nature, not just in size.

Despite all this, estimation is still worth doing — not for false precision, but for the conversations it forces and the shared understanding it builds.

Adapting the Card Set for Infrastructure Work

Standard Fibonacci sequences (1, 2, 3, 5, 8, 13, 20, 40) work fine for platform teams, but the calibration anchors need to reflect infrastructure reality. Spend one session as a team aligning on what each value means for your work:

Pin this table where your team can see it during estimation. The shared anchor prevents the classic pattern where one engineer's "2" is another's "8."

The Spike Ceiling: Cap Unknown Work Before It Enters the Backlog

One rule that pays dividends fast: anything with genuinely unknown scope should not be estimated directly. Instead, convert it to a time-boxed spike.

A spike is a fixed-duration investigation: "Spend two days determining whether we can use managed Postgres or need self-hosted." At the end, the team produces an outcome — a decision, a recommendation, a proof of concept — and then estimates the follow-on work.

Trying to estimate work you don't understand yet produces fake numbers that mislead everyone. Teams that adopt the spike pattern find that their non-spike estimates become more accurate because the backlog no longer contains mystery work masquerading as sized stories.

Good candidates for spikes on platform teams:

• New technologies your team hasn't used before
• Performance investigations where root cause is unknown
• Architecture decisions that depend on constraints you haven't fully mapped
• Security incidents where remediation scope is unclear

In planning-poker.app sessions, these tickets typically draw question marks (?) or infinity cards — a clear signal to convert to a spike before the next refinement.

Running a DevOps Estimation Session

Before the Session

Send tickets to participants 24 hours in advance. For infrastructure work, include:

• The current state (what exists today)
• The desired end state (what done looks like)
• Known risks or dependencies (other teams, change freeze windows, blast radius)
• Any relevant runbook, architecture diagram, or incident post-mortem

Context prep matters more for infra work than feature work because the mental model is harder to reconstruct in a meeting. Engineers who see a Terraform snippet or a network diagram before the session vote with much more confidence.

During the Session

Read the ticket aloud, including the technical context. Don't assume everyone absorbed the pre-read. A 60-second summary surfaces assumptions and lets participants ask clarifying questions before they commit to a number.

Vote simultaneously. This is the most important mechanic. If the senior SRE reveals their estimate first, junior engineers anchor to it. Tools like planning-poker.app hide all votes until the reveal, which surfaces genuine disagreement and forces real discussion.

Treat outliers as signal. When one engineer votes 3 and another votes 13, that gap almost always means one person knows something the other doesn't — a hidden dependency, a past incident, a quirk in the service's architecture. That conversation is the value of the session.

Time-box the discussion. Give people 5–8 minutes to discuss a ticket before revoting. Don't rush to consensus, but don't let it become a design meeting. If agreement isn't reached in two rounds, default to the higher estimate or convert to a spike.

Handling Reactive Work Capacity

A common failure mode: the team estimates 40 points of planned work, spends half the sprint on incidents and urgent requests, and finishes with 15 points completed. The velocity number becomes noise.

The fix is to stop treating reactive work as zero-cost.

Reserve a percentage of capacity for reactive work. Track how many points your team consumed on unplanned work over the last four sprints. If it averages 30%, commit only to 70% of your normal planned capacity. That's not sandbagging — it's honest planning.

Size incidents and urgent work after the fact. When a major incident consumes significant time, estimate it retroactively and add it to completed points. This keeps velocity honest and makes the cost of reactive work visible to stakeholders who wonder why fewer planned items shipped.

Estimation Patterns by Work Type

Not all infrastructure work should be estimated the same way. These patterns help.

Planned Infrastructure Projects

Kubernetes upgrades, database migrations, observability platform rollouts — these are the work types that benefit most from planning poker. They have defined outcomes, real complexity, and cross-team coordination requirements. Estimate them in the normal way, break them into phases if they exceed 13 points.

Compliance and Security Work

CVE patches, access reviews, encryption upgrades mandated by policy. These often have external deadlines and non-negotiable scope. Estimate them for capacity planning, but don't deprioritize them based on story points alone. Security work tends to be underestimated because the surface area of a vulnerability isn't known until remediation begins.

A useful pattern: estimate the "known path" portion of the work (upgrading the package, updating configs, deploying) and add a separate ticket for "validate and test remediation" with its own estimate. This surfaces the verification effort that teams routinely forget.

Runbooks, Documentation, and Toil Reduction

Toil reduction deserves special treatment. A runbook that prevents two hours of manual work per incident is genuinely valuable, but it competes for points against "shipping" work in stakeholder conversations. Frame toil reduction tickets with an explicit payoff statement: "This automation will eliminate roughly 4 hours/month of manual effort."

Estimate these like any other ticket — teams consistently underestimate documentation and automation work — but be clear about what done means. "Runbook written and reviewed by two team members" is estimable. "Improve our incident response" is not.

On-Call and Incident Response Improvements

Post-incident work items — improving alerting, adding circuit breakers, fixing the root cause of a recurring page — often compete poorly against new features in prioritization. Estimation helps make this work visible and plannable.

When estimating post-incident improvements, start with the post-mortem action items and estimate each one separately. Teams that bundle all follow-up work into a single "address incident X action items" ticket tend to underestimate and leave it perpetually unfinished.

Handling Cross-Team Dependencies

Platform teams frequently deliver work that blocks product teams. This creates a particular estimation challenge: the platform team's estimate affects another team's sprint planning.

A few principles that reduce friction:

Estimate what you control, flag what you don't. If completing a task requires a product team to update their service configuration, that dependency belongs in the ticket, not inside your estimate. Your estimate covers your team's work.

Use a definition of done that includes integration testing. "Deployed to staging and one product team has confirmed it works" is a better done condition than "deployed to staging." Build the integration checkpoint into your estimate so downstream teams aren't surprised.

Communicate estimate confidence levels. Infrastructure estimates often carry higher uncertainty than feature estimates. Sharing that a 13-point estimate has "±5 points of uncertainty because we've never done this specific cloud provider feature" is more useful than false precision.

Metrics Worth Tracking

Standard velocity tracking works for platform teams with a few adjustments:

Track planned vs. unplanned ratio. If your unplanned ratio has been rising for three sprints, that's a systemic signal — not a one-off. Tracking it makes the cost of reactive work visible to leadership before it becomes a crisis.

Measure estimate accuracy by work type. Do your 3-point estimates actually take 3 points of effort? Most platform teams find they consistently underestimate security work and overestimate documentation work. Breaking out accuracy by work type is what moves calibration from vague intuition to specific adjustment.

Track toil percentage. What fraction of sprint capacity goes to manual, repetitive operational work? The goal is to drive it down over time. You can't drive down what you don't measure.

Getting Buy-In from Skeptical DevOps Engineers

Not every engineer on a platform team will embrace estimation. Common objections:

"Our work is too unpredictable to estimate." Some of it is — which is exactly why spikes and reserved reactive capacity exist. The planned work is estimable. The goal isn't perfect accuracy; it's shared understanding and better prioritization conversations.

"We've tried this and the numbers are always wrong." Usually a calibration problem. Run a retrospective on your last ten estimates. If they're consistently off in the same direction, adjust your anchors. Accuracy improves with practice and shared context.

"It takes too long." Refinement for infrastructure tickets requires more upfront context-building than feature tickets, yes. But it replaces a different cost: mid-sprint surprises, scope creep, and post-sprint debates about what happened to velocity. Most teams find the tradeoff worth it after a few sprints.

---

The teams that make planning poker stick report the same benefit: better conversations about risk and complexity before work begins, not during it. The numbers matter less than the alignment they produce.

Planning Poker supports anonymous voting, custom card sets, and direct Jira and Linear integration — so your infrastructure backlog flows into estimation sessions without manual copy-paste. Teams can also join without accounts, which matters when you're pulling in a product engineer or a security reviewer for a single refinement session.

Start with your next sprint's planned infrastructure work. Exclude reactive capacity explicitly. Estimate what you can, spike what you can't. The calibration will follow.