Reordering Your Backlog Is Zero Sum. Deleting From It Is Not.

Дата публикации: 13-09-2026 06:00:00

Image


Open the Scrum Guide and look for a word that takes something out. Refinement is "the act of breaking down and further defining Product Backlog items into smaller more precise items." The Product Owner is accountable for "Ordering Product Backlog items." Work that misses the Definition of Done "returns to the Product Backlog for future consideration." I have taught that document for twenty years and I have never found the sentence that lets an item leave.Every operation the framework names either adds items, splits one into several, or sequences what is already there. On its own that is a documentation gap, and it becomes something worse once you notice that sequencing is the one lever mathematics guarantees will not help.A 1965 Proof That Sorting Is Zero SumLeonard Kleinrock proved something about queues in 1965. Reordering a queue cannot reduce the total amount of waiting inside it. Sorting moves waiting from one job to another, and that is the whole of what it does. Promote something to the top and the time it saves comes out of the items behind it, to the hour.The result is a conservation law, and it holds under three conditions that Dijkstra later wrote out cleanly: no server sits idle while a customer waits, the scheduling decision does not change anyone's arrival or service time, and nothing gets interrupted once started. Meet those and the total waiting, counted so that bigger jobs weigh more, "is independent of the choice of non-preemptive scheduling method."This is not a statement about careless prioritization. It applies with equal force to the quarterly ranking that took three workshops and a scoring model. A better order hands the waiting to more deserving items, which is worth doing, and the total is what it was before anyone opened the spreadsheet.The One Sorting Trick That Beats the AverageThere is a gap in that result, and product teams already exploit it without knowing whose it is. The quantity Kleinrock conserves is waiting weighted by job size, and the plain average is not conserved.W. E. Smith proved in 1956 how to attack that average. To minimize weighted flow time you schedule jobs with the highest ratio of weight to processing time first, which in product terms is value divided by duration. That is Weighted Shortest Job First, arriving about half a century before the framework that named it. Drop the value term and you get the rule everybody knows anyway, that short jobs should go ahead of long ones.So ordering does buy something, one specific provable gain, and that gain is bounded. Once your queue sits in weighted-shortest-job order you have collected all of it, and everything after that is rearrangement. In April I argued that pricing time with cost of delay separates product management from feature management, and this is the ceiling on what that pricing returns.Both proofs take the set of jobs as given. Neither has anything to say about how many jobs there are.Removing Work Obeys Different ArithmeticQueue length in the standard single-server model is the load divided by one minus the load. At 80 percent load the queue holds about four jobs, at 90 percent it holds nine, and at 95 percent nineteen.Slack is what produces that pattern, because work never arrives evenly spaced and idle gaps are what let a queue drain between clumps. At 80 percent load those gaps are there. At 95 percent almost nothing is spare, so a bad week never gets cleaned up.Run it the other way and dropping from 95 percent load to 80 removes about four fifths of the queue, with every item left moving faster, including the ones nobody prioritized. No reordering produces that, because reordering cannot change the load. Only changing what enters or stays can.Sorting can only hand the waiting to someone else. Removing work shrinks it for everybody at once, and the emptier the queue gets the faster that shrinking goes. Product teams have built elaborate machinery for the first move and have almost no words for the second.What This Does to Cost of DelayCost of delay accrues against everything sitting in the queue. It is recovered only on what ships. For an item that never ships, the delay cost is total, and where it sat in the order is irrelevant to the outcome.Richard Lawrence has been asking product owners how much backlog they hold and how much of it ever reaches the top. His informal survey, not a controlled study, puts the middle of the distribution at "two to four years and 50 to 75%", so between half and three quarters never gets built.Put that next to the 2017 Scrum Guide, which capped refinement at "no more than 10% of the capacity of the Development Team." The cap was sensible; the question is where the ten percent goes. If most of the list will never be delivered, most of that capacity is spent adding detail, estimates and order to work that will never exist.Ordering Cannot Change the Outcome, Only the CalendarDelivery time is the smaller half of this. A sequence determines when things arrive and cannot determine what arrives, because everything in the order is already in the set.That matters more than it sounds, because items get built for the sole reason that they are present. A long backlog is never just a store of options. It works as a standing supply of plausible next work. A team out of obvious things to do pulls from it, rather than asking whether the list still describes the product it now intends to build. Filtering is the only operation that reaches this, because it changes what is available to be chosen.Two Objections, One of Them SeriousThe easy objection is that a deleted item might be needed later. Archive it. Lawrence puts the trade honestly, that you can always recover an item from the archive but "you'll never recover the focus it's stealing if you leave it there."The serious objection is political, and no amount of queueing theory dissolves it. Every item has a person attached who asked for it and was told yes, or told something that sounded enough like yes. Deleting means going back to that person. Reordering means going back to nobody. Sorting survives because it lets an organization avoid that conversation while producing the paperwork of a decision, which is why teams who understand all the mathematics above still spend refinement ranking.I contributed to the Scrum Guide Expansion Pack. We got as far as observing that "a smaller Product Backlog often provides more Transparency." We did not write a removal practice either. The observation is in the text and the operation still is not, so I am describing a gap I helped leave open. We need to fix this in the next update.Four Things That Change the NumberDivide your backlog by your throughput. Items divided by average items finished per month gives the months of work you are holding, and anything past two quarters is not a plan.Set an intake rule with a subtraction in it. Nothing enters without something leaving, which is a work-in-progress limit applied to the list instead of the board, and it forces the conversation that ordering exists to postpone.Date-stamp every item and send anything untouched for six months to the archive rather than the bottom. The bottom is where items go to consume attention quietly.Then measure the one number nobody reports. Last quarter, how many items left your backlog without being built? If the answer is zero, nobody has been managing that backlog. They have been sorting it, and Kleinrock settled sixty years ago what sorting is worth.Ralph Jocham is Europe's first Professional Scrum Trainer, co-author of "Professional Product Owner," and contributor to the Scrum Guide Expansion Pack. As an ICF ACC certified coach, he works with organizations to build Product Operating Models where strategic clarity, operational excellence, and adaptive learning create measurable competitive advantage. Learn more at effective agile.References[1] Dijkstra, E. W. 'On Kleinrock's Theorem' (EWD 775), E. W. Dijkstra Archive, University of Texas at Austin. Source of the three conditions and the statement that the sum of Wi times Ri is independent of the non-preemptive scheduling method. Used because Kleinrock's original paper is paywalled; this is a verified accessible statement of the same result. Available at: https://www.cs.utexas.edu/~EWD/transcriptions/EWD07xx/ewd775.html[2] Kleinrock, L. (1965) 'A conservation law for a wide class of queueing disciplines', Naval Research Logistics Quarterly, 12(2). The original result, cited as origin. Abstract is behind a publisher paywall and was not fetched; the statement used in this article comes from [1]. DOI: 10.1002/nav.3800120206[3] Stanford University, MS&E 324, Lecture 2, 'Scheduling and Queueing'. Source of Proposition 2.1 (shortest processing time first minimizes flow time on a single machine), Proposition 2.3, Smith's ratio rule (schedule jobs with the highest ratio of weight to processing time first, minimizing weighted flow time), and the M/M/1 result that average queue length is rho over one minus rho. Text extracted from the PDF and verified. The 80 / 90 / 95 percent arithmetic in this article is computed from that formula, not quoted. Available at: http://web.stanford.edu/class/msande324/handouts/Lecture2.pdf[4] Smith, W. E. (1956) 'Various optimizers for single-stage production', Naval Research Logistics Quarterly. Origin of the ratio rule, attributed as such in [3].[5] Schwaber, K. and Sutherland, J. (2017) 'The Scrum Guide', November 2017 edition. Source of "Refinement usually consumes no more than 10% of the capacity of the Development Team" and of refinement defined as "the act of adding detail, estimates, and order to items in the Product Backlog." Verified verbatim. Available at: https://scrumguides.org/scrum-guide-2017.html[6] Schwaber, K. and Sutherland, J. 'The Scrum Guide', current edition. Source of refinement as "the act of breaking down and further defining Product Backlog items into smaller more precise items," of the Product Owner's accountability for "Ordering Product Backlog items," and of undone work that "returns to the Product Backlog for future consideration." Checked for the words remove, delete, discard and drop in relation to Product Backlog items; none appear. Available at: https://scrumguides.org/scrum-guide.html[7] 'The Scrum Guide Expanded', Scrum Guide Expansion Pack. Source of "A smaller Product Backlog often provides more Transparency." Also checked for removal, pruning and archiving guidance; none present. Available at: https://scrumexpansion.org/scrum-guide-expanded/[8] Lawrence, R. and Green, P. (2025) 'The Life-Changing Focus of a Clean Backlog', The Humanizing Work Show, 3 November. Source of the "two to four years and 50 to 75%" figure and the archive quotation. This is Lawrence's informal survey of product owners, described as such in the article, and is not a controlled study. Available at: https://www.humanizingwork.com/life-changing-focus-clean-backlog/[9] Jocham, R. (2026) 'Price Your Time: The Cost of Delay Discipline Most Product Teams Skip', 10 April. Referenced in the text as the prior argument this one bounds.

Схожие новости

#	Наименование новости	Тональность	Информативность	Дата публикации
1	AI Changed the Bottleneck. Your WIP Limits Should Change With It.	0	10.22	08-09-2026
2	5 Things the Product Owner Shouldn’t Be Doing	0	16.4	29-09-2026
3	Scrum's Meetings Are Capped at Five Hours a Week. Something Else Filled Your Calendar.	0	17.09	20-09-2026
4	Scrum's Protocol Is Easy to Copy. Its Agenda Is Not.	0	14.4	27-09-2026
5	Your Team Isn't Slow. Your Handoffs Are.	0	8.51	22-09-2026
6	Nobody Owns Whether it Worked.	0	8.63	29-09-2026
7	Your Scrum Team Might Be Excellent at Building the Wrong Thing	0	13.28	27-09-2026
8	‘Batches’ in Scrum	0	13.56	24-09-2026
9	AI on Top of a Dysfunctional System (1): The Product Backlog	0	5.29	20-09-2026
10	KI auf einem dysfunktionalen System (1): Das Produkt-Backlog 🇩🇪	0	8.42	24-09-2026

Классификация: . Схожих патентов: 0. Схожих новостей: 10. Тональность: 0. Информативность: 9.38. Источник: www.scrum.org.