Loading today’s stories
Build1 distinct publisher3 min readUpdated
A platform team of eight put on-call on the board and watched planned-work completion fall from 82% to 54% before settling near 73%. The old 90% was a ledger habit.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
Three sprints at 31, 34 and 32 points is a spread of three around a mean of 32.3, under a tenth of the mean [3][1][2]. That is what a process under control looks like on a chart, and it is the reading the slide and the trend line invited [3]. Those numbers describe the queue feeding the team, not the team. Sprint four fed a different queue: a certificate rotation, a flaky EKS node group, two urgent access requests from finance, and orders-worker still opening connections after its PostgreSQL failover target had changed [4]. Output was 14 points, about 43% of the earlier mean [4][3]. Half of that work arrived after planning, and the rest carried dependencies hidden behind reasonable-looking tickets [5]. The velocity figure did not bend under load. It stopped applying.
The more instructive number in the team's account on dev.to is the one that moved while the work stayed the same. In May, after they stopped quietly pulling unfinished cards into the next sprint and began recording interruption work, planned-work completion fell from 82% to 54%, a drop of 28 points [7][4]. Recorded on-call came to roughly 11 engineer-days a month [8]. Eight engineers on a two-week sprint is 80 engineer-days, so on a 20-day month on-call takes about 5.5 engineer-days per sprint, close to 7% of capacity [1][5]. Seven points of capacity does not pay for a 28-point fall. The remaining 21 or so were never operational load; they were the roll-forward finally landing in the period where it belonged [6]. The 90% the team used to report was, by its own description, assembled from invisible spillover, and the 73% it reached four sprints later is the same group measured honestly, 17 points worse on paper [9][10][7]. Finance did not enjoy the first version of that report [14].
The forecasting claim breaks hardest on the cards the team does not own. By 15:17 that Thursday, six of the nine promised cards were open, and the one everyone was waiting for needed a DNS change from another team [6]. No estimate the platform group could produce was ever a statement about the platform group's capacity. Their revised habit accepts that: one Sprint Goal, reserved capacity for known operational work, and a confidence marker on anything with an outside dependency, because a card blocked on Security, Data Engineering or a vendor is not in progress the way a card with someone editing a file is [12]. The team notes that the Scrum Guide already treats a Sprint Goal as an objective rather than a contract for a fixed pile of tickets, and that teams drift because tickets are easy to count and objectives are hard to discuss [11].
Counting also shapes behaviour. Treating the backlog as a contractual commitment produced late card-splitting to get something to Done, avoidance of investigation that threatened the count, and work continued past the point it should have been stopped, all three visible during a migration from an old NGINX ingress setup to AWS Load Balancer Controller 2.7 [13]. What the 73% buys is narrower and more useful: the team can usually say whether a change lands in two weeks, and it declines to promise when someone outside holds the last key [9].
Follow any of these and your For You feed starts watching them — no settings page required.
Ranked by verification strength, evidence, and original report placement.
The team's verdict on the claim that Scrum makes delivery predictable: mostly false, unless the work is already fairly predictable.
The team ran Scrum with its infrastructure group for four months: eight engineers, one engineering manager, a rotating facilitator, two-week sprints, and enough Kubernetes work to make estimates feel mildly dishonest.
The team kept ceremonies small and made every operational interruption visible instead of pretending PagerDuty events arrived from another department.
The first three sprints made delivery look predictable: 31 points, then 34, then 32. Somebody put the numbers in a slide and somebody else drew a trend line.
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. The team completed 14 points.
Half of sprint four's work arrived after planning, and the other half had hidden dependencies behind apparently sensible tickets.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Single self-reported account, specific but unverifiable
All quantitative content originates from one first-person practitioner post; the figures are unusually specific and internally consistent (31/34/32 then 14; 82%/54%/73% versus 90%; 11 engineer-days a month), and the derived arithmetic checks out. But there is no second source, no raw data, no comparison team, and no independent confirmation of any number. The article body supplied is also truncated mid-sentence on the 20% commitment-buffer experiment, leaving one described trial without a result.
One eight-person team, no external uptake evidence
Adoption evidence is confined to three disclosures from the same eight-engineer platform team: the accounting change, the planning-practice change, and one ingress-controller migration. Nothing in the supplied material shows another team, organisation or tool vendor adopting the pattern, and no timeframe beyond roughly eight sprints is documented.
Slightly overstated by generalisation, not by numbers
The reported figures are deflationary rather than promotional - the team volunteers a worse-looking number and calls its old 90% a ledger habit - so the specific claims sit close to the evidence. The modest positive gap comes from framing: a single team's four months is presented as retiring general 'Scrum myths', and verdicts stated as broadly true ('mostly false', 'false') rest on n=1 with no comparison case or external data.
Self-published practitioner post, no product being sold
The single source is a community-platform post from a devops-oriented author account. There is no product, vendor sponsorship, pricing offer or disclosed commercial relationship in the supplied material; the visible incentive is reputational reach on a developer platform, plus the ordinary self-interest of a team narrating changes it chose and now defends. That self-interest is partly offset by the author publishing a less flattering completion figure.
Coherent narrative, thin evidentiary base
Confidence is moderate-low: the account is detailed, dated, arithmetically consistent and candid about its own worse-looking numbers, which supports the descriptive claims about this team. It is a single unverified source with no corroboration, so any claim that the pattern generalises - or that the settled 73% reflects durable capability rather than a new accounting convention - remains weakly grounded.
build
A 30-to-45-second timeout change, four approvals, no merge: the cost of a two-person gate1 distinct publisher
build
Partition, not consolidation: what a 43-minute Jenkins queue actually cost1 distinct publisher
build
A NetworkPolicy in another repo broke invoicing while every dashboard reported success1 distinct publisher
build
A year without sprints: nine engineers, 36 services, and a WIP cap of eight graded B1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 23, 2026