Build1 distinct publisher3 min readUpdated
The cap changed which conversation happens before work starts. It also moved a cost off the board, where nobody counts it.
The Engineer · Build desk

Compiled by The EngineerSomething wrong?How this is made
Little's Law does the work the grade does not. A cap of eight items in progress against 14 completed standard tickets a fortnight, taking a fortnight as ten working days and the queue as roughly steady, puts the average ticket in progress about six working days [1]. The 11 the team found sitting in Doing on the first Tuesday puts it near eight [2]. A limit does not make anyone type faster. It sets how long a half-finished thing is allowed to sit there, and those two days per ticket are the whole prize.
Then look at what the 11 was made of. Three were waiting on a reply, two had not been touched since the previous week, and one was a task to investigate service mesh options [10]. Five of the eleven slots were held by work that needed a message sent rather than an engineer's afternoon, which leaves six genuinely in hand, under the cap they had supposedly blown through [3]. The limit did not find an overloaded team. It found that "active" had been defined to include waiting.
That is also where the unbudgeted chores come from. When the board refuses a new start, the next move is usually outside the team: the engineer on the OpenTofu module went and asked the service owner for the missing variable list, and someone else confirmed with a vendor that a release had been withdrawn before closing a stale upgrade card [11]. Blocked went onto the board on day two precisely because Doing had been hiding that category of work [9]. None of it appears in the throughput count, and the team's own phrase for it, chores nobody put on a capacity plan [c5c], is the accurate one.
The claim about how disagreements get argued is thinner than the flow numbers, and the B grade concedes it [c5a]. Expedite has a test with a number in it, live production impact or a security deadline under five days out, and fixed date has to be a date imposed from outside the team [7]. The account presents that as what they expected of classes of service, not as something they went back and measured. What did get measured is the check-in, 25 minutes down to about 11 [12], which across nine people is roughly 21 person-hours a fortnight returned if everyone attends [6].
The cap itself is still the weakest number on the board. Eight came from headcount minus the people they assumed would be in meetings, a derivation the authors disown in writing [6], and it leaves fewer standard slots than engineers [4]. Re-deriving it from completions is harder than it sounds: 23 tickets in October against six in January is a spread of nearly four to one [13][5], and an average across that is something to argue about capacity with, not something to set a limit from.
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.
On 19 August 2025 the platform team deleted the remaining two-week sprint from its board while seven tickets were still marked "in progress".
Of the seven tickets still in progress, two were waiting on product teams, one was a certificate renewal nobody had planned, and one was an ordinary Terraform change that had acquired four assignees.
The nine-person platform team supports 36 production services, a shared Kubernetes cluster, identity, CI runners, and internal tools.
The team spent six months treating the situation as a planning problem and concluded it was an interruption problem.
Sprints made the work look orderly for roughly a day and a half before an incident, access request or release deadline arrived.
The team moved to kanban with a hard WIP limit, an expedite lane, and a decision to stop describing unfinished work as "carryover".
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 case study
The evidence is detailed and specific — dates, ticket counts, meeting durations, throughput per fortnight, named failure modes — but all of it originates from one first-person post by the team that made the decision. No instrumentation output, no independent measurement, no second publisher, and no control comparison against the sprint period. Internal consistency is good enough that the derived flow-time arithmetic holds, which lifts this above anecdote, but the supplied text is also truncated mid-argument.
One team, twelve months
Adoption evidence covers exactly one nine-person platform team over one year, from the sprint deletion on 19 August 2025 through the retrospective. The practice is genuinely in production use with policy enforcement (managers cannot bypass the cap) and a tightened blocked-ticket standard, but there is no evidence of spread to other teams, no organisational mandate, and one product group actively pushed back on the Blocked status wording.
Understated relative to its own evidence
The piece consistently discounts itself: it grades the change a B rather than a success, disowns the derivation of its own WIP number, admits to unbudgeted board chores, refuses to use throughput for individual targets, and notes that blocked status became politically awkward. The measurable improvements it does report — check-in time roughly halved, stalled work surfaced, sequencing conversations changed — are presented more modestly than the numbers would license, so the claim level sits slightly below the evidence rather than above it.
Self-assessment bias, no product pitch
The visible incentive is reputational: a practitioner narrating and grading a decision they own, on a developer-blogging platform, with the usual pull toward justifying the change. No vendor, product, sponsorship, pricing or funding interest is disclosed or discernible in the supplied text, and the article criticises purchased delivery dashboards rather than promoting a tool. That combination keeps the incentive pressure moderate and mostly inward-facing.
Moderate on the account, low on generality
Confidence is reasonably high that this team did what it says and observed what it reports: the account is dated, internally consistent, arithmetically coherent and unusually willing to name its own weaknesses. Confidence is low that the numbers generalise, because there is one publisher, one team, no independent verification, no baseline comparison, and a truncated conclusion.
build
ALB validates the JWT, Keycloak decides what is in it: the Terraform for the matching realm1 distinct publisher
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
security
GitLab 19.3 puts agent runtime, inference models and secrets under one permission model1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 21, 2026