What our platform team learned when sprint planning met production work.
By 15:17 on Thursday, six of the nine cards we had promised for the sprint were still open, and the one everyone wanted finished was waiting on a DNS change from another team. Our board looked less like a plan and more like the contents of a drawer after someone has searched for a battery.
We’d been running Scrum with the infrastructure group for four months: eight engineers, one engineering manager, a rotating facilitator, and enough Kubernetes work to make estimates feel mildly dishonest. We kept the ceremonies small, used two-week sprints, and made every operational interruption visible instead of pretending PagerDuty events arrived from another department.
That last part mattered. So did admitting that some things people say about Scrum are true only in the same sense that “the lift is working” is true while it is stuck between floors.
“Scrum Makes Delivery Predictable”
Verdict: mostly false, unless the work is already fairly predictable.
Our first three sprints did make delivery look more predictable. We averaged 31 points, then 34, then 32. Somebody put the numbers in a slide. Somebody else drew a trend line. We all briefly enjoyed the illusion that we had discovered arithmetic.
Sprint four contained a certificate rotation, a flaky EKS node group, two urgent access requests from finance, and a production issue where orders-worker kept opening connections after its PostgreSQL failover target had changed. We completed 14 points. The number was not the problem; the work was. Half of it had arrived after planning, and the other half had hidden dependencies behind apparently sensible tickets.
Scrum can force us to state an expectation before work begins. That is useful. It does not turn unknown work into known work, and it certainly does not persuade a cloud provider to schedule maintenance around our sprint boundary.
The Scrum Guide is careful here: a Sprint Goal is an objective, not a contract for a fixed pile of tickets. Teams tend to forget this because tickets are easier to count than objectives are to discuss. “Improve the reliability of cluster upgrades” sounds vague in a planning meeting. “Complete PLAT-184 through PLAT-191” feels reassuring, right up until PLAT-187 reveals a three-year-old Terraform module nobody has touched since 2023.
We changed our planning habit after that Thursday. We now select one Sprint Goal, reserve capacity for known operational work, and mark confidence on items with outside dependencies. A card waiting on Security, Data Engineering, or a vendor is not “in progress” in the same way as a card with a developer actively changing a file. This sounds obvious because it is obvious. We had still failed to do it.
Our predictability got worse before it got better. In May, the percentage of planned work completed fell from 82% to 54% when we stopped quietly pulling unfinished cards into the next sprint and started recording interruption work properly. Finance did not love the first report. Neither did we. It also showed that on-call work was consuming about 11 engineer-days a month, which was difficult to ignore once the number had a row in it.
Four sprints later, our completion rate settled around 73%, but the forecast conversations became less fictional. We can usually say whether a change will land in the next two weeks. We do not promise it when an external team holds the last key.
That is about as predictable as infrastructure work gets, and we are happier with it than the old 90% figure built from invisible spillover.
“Every Sprint Needs A Finished Commitment”
Verdict: false, and this wording causes more trouble than it saves.
We tried treating the sprint backlog as a commitment in the contractual sense. At planning, every card was assigned, estimates were discussed until people began using phrases like “relative complexity” with straight faces, and the team left with a tidy board.
Then Friday came.
A committed backlog produces bad behaviour when reality moves. Engineers split cards late so something can reach Done. They avoid useful investigation because it threatens the count. Work that should be stopped carries on because abandoning it looks worse than spending another day on it. We saw all three during a migration from an old NGINX ingress setup to AWS Load Balancer Controller 2.7.
One ticket was to move the customer-admin service. It had a seven-point estimate and a sensible acceptance list. During testing, we found that its websocket timeout had been set in an annotation inherited from a chart no one remembered choosing. The right response was to pause, reproduce the failure under load, and decide whether to move the service at all.
Instead, we kept pushing. The ticket crossed the board on the last afternoon. It was “done” because the service answered HTTP requests in staging. The websocket issue returned in production at 09:12 on the following Monday. We had manufactured a green card and bought ourselves a support incident.
A Sprint Goal can be a commitment. “Reduce the risk of expiring internal certificates before the September renewal window” gave us room to drop an unhelpful automation task and spend two days fixing the actual renewal path. The goal remained valid even when a ticket did not.
We now call individual backlog items forecasts. Some people dislike the word because they think it softens accountability. We think it describes reality. An engineer still owns the work. The team still explains why it moved or did not move. Nobody gets to call a ticket “almost done” for three sprints and hide behind uncertainty.
The distinction also makes review less ceremonial. We look at what changed for users or operators, what we learned, and what is parked. If a ticket has been open for more than ten working days, we ask whether it is too large, blocked, or simply no longer worth doing. That question has killed several pieces of work that would otherwise have become permanent residents of the board.
We did try a “commitment buffer” of 20%, where every sprint had deliberately unallocated capacity. It did not work. Urgent work filled it by lunchtime on day two, and people started treating the remaining 80% as a harder promise. We removed it after two sprints. No grand lesson emerged. It was just an awkward number sitting on a board while the pager went off.
“The Daily Scrum Is A Status Meeting”
Verdict: false, although many teams have made it one.
Our daily Scrum used to happen at 09:30, last 17 minutes, and contain a sequence of engineers reporting to a manager who already had access to the board. We called it a stand-up despite everyone being on video. It was not offensive; it was merely pointless.
The manager stopped attending after we agreed that the meeting belonged to the people doing the sprint work. This was not a rebellion against management. There are enough of those already, usually involving spreadsheets. It was a decision to stop turning coordination into a recital.
The format changed with one rule: talk only about the next 24 hours of progress toward the Sprint Goal, including anything likely to prevent it. “Yesterday I updated the Helm chart” is status. “The chart deploys, but the admission controller rejects our security context and I need Mina for 20 minutes after this” is coordination.
That took some practice. The first week was full of habit. People gave the old three questions, then added a blocker as an afterthought. By week three, the useful discussions had become shorter and more direct. One engineer would say a task had expanded; another would point out a similar change in payments-api; someone would decide to pair after the meeting rather than spend two days rediscovering the same failure.
Our daily Scrum now runs for nine minutes on most days. On Mondays it can run longer because somebody has usually found a surprise over the weekend. If a production incident is active, we cancel it and use the incident channel instead. There is no prize for maintaining a ceremony during a fire.
We also stopped forcing every person to speak. Silence is allowed if someone has no change to coordinate. This makes a few Scrum purists twitch, but the guide’s purpose for the event is inspection and adaptation, not attendance theatre.
There is one unresolved argument here. We rotate facilitation every sprint, and two engineers still think the daily meeting becomes noticeably worse when the rotation reaches people who dislike meetings. They may be right. We have not yet decided whether a team-owned practice needs a consistent owner to stay useful, or whether that is just us avoiding a mildly uncomfortable skill gap.
“Velocity Tells Us When To Hire”
Verdict: false, and we dislike velocity as a management number.
Velocity tells us how many points a particular team finished under a particular estimating habit. It does not tell us how much work exists, whether the work is valuable, whether another engineer would remove a bottleneck, or whether the points themselves are anything more than educated hand gestures.
We learned this when our eight-person platform group’s velocity rose from 29 to 41 across five sprints. The headcount had not changed. The work had. We had spent a month closing small access-control tasks and documentation gaps after a large migration. The average card got smaller. Our estimate scale drifted because people had become familiar with the code. No new capacity had appeared, unless confidence in kubectl counts as capacity.
A senior manager asked whether the data showed we could defer an open platform role. We said no, then had to explain why a rising line did not mean the team was suddenly 41% more capable. That conversation took longer than it should have, partly because we had supplied the line in the first place.
For staffing, we now bring actual constraints: time spent on on-call, the number of services per primary responder, lead time for changes requiring platform review, and the queue of work we have agreed is worth doing. The DORA research is more useful than sprint velocity when discussing delivery performance, though it will not tell us whether we need someone who understands IAM policy evaluation at 02:00.
Our cost story was equally unhelpful at first. We added a contractor to cover the observability backlog, and monthly cloud spend rose by $2,840 before it fell. The contractor found duplicated OpenSearch ingestion and an abandoned Datadog log pipeline, but the cleanup took six weeks and required running old and new paths together. The early finance report showed only a person costing money and a larger AWS bill. By July, the recurring spend was down by roughly $1,900 a month. Velocity did not explain any of that.
We still estimate. Planning with no rough sizing tends to turn every ticket into a philosophical dispute. But we keep points inside the team, refuse comparisons between teams, and do not put velocity in hiring cases. A hiring decision based on story points is one meeting away from measuring engineers in bananas.
“Scrum Needs Someone To Protect The Team”
Verdict: mostly true. We wish it were less true.
We have seen teams say they are self-managing, then accept every Slack request, executive question, customer escalation, and “quick” production change because nobody has the standing to say no. The result is a sprint plan that exists mainly to be apologised for on the final Friday.
Someone has to protect the time reserved for the work the team agreed mattered. In our case, that person is usually the engineering manager, but it is not exclusively their job. The rotating facilitator flags new requests during daily Scrum. The on-call engineer can redirect a non-urgent ask into the intake queue. Staff engineers push back on technically dangerous shortcuts. Protection works better when it is shared, because a manager in a meeting cannot stop a drive-by request in a Slack thread.
Still, a named person needs enough authority to resolve the hard cases. Last month, Sales wanted a one-off IP allowlist for a prospect’s proof of concept. The request arrived eight business days before a security hardening deadline. The technical change would have taken perhaps two hours. The review, exception handling, expiry process, and later cleanup would not. Our manager said no until the Sprint Goal was met. The prospect did not vanish. The certificate work finished on time.
This only held because our director backed the decision. On teams where every request can be escalated around the manager, “protect the team” becomes a polite phrase for losing an argument more slowly.
We do not need a full-time Scrum Master for eight engineers. We do need somebody prepared to tell a vice president that their urgent request is a backlog item until they can explain what it displaces.
