{"course":{"slug":"how-software-changed","title":"How Software Development Changed","url":"https://addaly.com/learn/how-software-changed","level":"intermediate","track":"work"},"lesson":{"slug":"work-in-progress-limits","title":"Capping the queue","url":"https://addaly.com/learn/how-software-changed/work-in-progress-limits","position":53,"of":87,"minutes":9,"answer":"Capping work in progress moves effort to the constraint automatically and cuts time in system without changing throughput, and the argument that persuades managers is Little's Law computed from the team's own numbers.","keyIdea":"Capping work in progress moves effort to the constraint automatically and cuts time in system without changing throughput, and the argument that persuades managers is Little's Law computed from the team's own numbers."},"body":{"format":"markdown","text":"## The counterintuitive move\n\nIf review is the constraint, the correct response to a faster writing stage is to start fewer things. That sentence is correct, it is well supported by queueing theory, and it will be resisted by everyone who has ever been measured on activity.\n\nThe mechanism, restated: work in progress equals arrival rate times time in system. Hold the service rate fixed, raise the arrival rate, and time in system rises proportionally. Every extra item in flight makes every other item slower, including the one you most want finished.\n\n> Figure: Same throughput, different time in system. Bars (working days from opening to merged): 40 open, writing doubled and nothing capped 10; 25 open, where this team is today 6; 12 open, capped 3. Little's Law on a team that merges twenty changes a week: time in system is work in progress divided by throughput. Capping changes nothing about what gets merged, halves how long each change waits, and gives every review more attention because fewer are queued.\n\n## What a limit looks like in practice\n\n**Per person: at most two open pull requests.** When you have two and want to open a third, you must first get one merged, which means going and reviewing somebody else's, or chasing yours through, or splitting it. The effort moves to the constraint automatically, without anybody having to decide it should.\n\n**Per team: a number on each column of the board.** In review: five. In progress: eight. When a column is full, nothing enters it. The board stops being a list of everything anybody is doing and starts being a system with a shape.\n\n**Pull, not push.** Nobody is assigned work. When you have capacity, you take the next item. This sounds like a small procedural difference and it is the whole mechanism: pushing work into a full system is how you get a full system.\n\n## Setting the number\n\nThere is no correct value and there is a good method for finding one.\n\nStart at roughly your current average (count what is actually in flight today) and then lower it by one every couple of weeks until something hurts. What hurts first tells you where the real constraint is, which is the information you wanted.\n\nIf lowering the limit leaves people idle, that is a finding rather than a failure. It means your bottleneck is elsewhere, and the idle time is visible capacity you can move to it. Idle time that is visible is far more useful than idle time hidden inside a queue of half-finished work.\n\n## The conversation with a manager\n\nThis is the hard part, and the argument that works is arithmetic rather than philosophy.\n\n> We merge about 20 changes a week and we have 25 open. That is 1.25 weeks from opening to merged, and you can check it. If we open 40 a week and review capacity does not change, we merge 20 and the pile grows by 20 a week, for ever. We would show more activity and deliver the same amount, with worse review on all of it.\n>\n> If we cap at 12 in flight, time in system drops to about 0.6 weeks. Same throughput, half the latency, and reviews get more attention because there are fewer of them waiting.\n\nTwo numbers, both from your own systems, both checkable. This works far better than any appeal to principle, because it makes a prediction and invites verification.\n\nThe follow-up question is always whether this means people will be idle. The honest answer is that they will be doing the work that actually moves delivery: reviewing, testing, pairing, deleting things, improving the pipeline. All of that is invisible on an activity dashboard and all of it is at the constraint.\n\n## Where it goes wrong\n\n**Limits without a rule for what to do when blocked** just produce frustration. Write it down: when you cannot start something, you review, you help finish something, or you work on reducing the constraint. Not \"start something else\".\n\n**Limits that ignore urgent work** get abandoned in the first incident. Have an explicit expedite lane with a limit of one, and the rule that using it means something else stops.\n\n**Limits on a board nobody looks at** are decoration. The limit has to be visible at the moment someone is about to break it.\n\n**Counting the wrong thing.** If your limit is on tickets but the queue is in review, you have limited the wrong stage. Put the limit where the wait actually is, which you know from measuring stage times.\n\n## The deeper point\n\nA limit on work in progress is a decision to make the constraint visible instead of hiding it inside a queue. That is uncomfortable, because a visible constraint is a thing somebody has to answer for, and a hidden one is just everybody being busy.\n\nBut you cannot elevate a constraint you cannot see, and a system with unlimited work in progress is a system that has chosen not to look at its own bottleneck. In a period when the stage in front of the bottleneck got several times faster, that choice became much more expensive than it was."},"check":{"question":"A team imposes a limit of two open pull requests per person. Within a month, some engineers are regularly unable to start new work. What does this indicate?","options":[{"text":"The limit is set too low for the team's throughput and should be raised to three until nobody is blocked.","correct":false,"tempting":"Raises the limit to hide the signal, restoring the queue that the limit was introduced to expose."},{"text":"Per-person limits are the wrong granularity, since capacity varies between individuals and a team-level cap would balance better.","correct":false,"tempting":"Team caps have advantages, but they would smooth over exactly the blocking signal that is telling you where the constraint sits."},{"text":"The team is writing faster than it can review, which the limit has made visible rather than caused.","correct":true},{"text":"Reviews are being left too long, so the fix is a service-level agreement requiring first review within a working day.","correct":false,"tempting":"A review SLA is a sound complementary practice, but it addresses latency within the stage rather than the capacity mismatch causing the block."}]},"prev":{"slug":"estimation-and-the-demo-effect","title":"Why everything looks nearly done","url":"https://addaly.com/learn/how-software-changed/estimation-and-the-demo-effect"},"next":{"slug":"planning-verification-as-work","title":"Putting verification in the plan","url":"https://addaly.com/learn/how-software-changed/planning-verification-as-work"},"authorship":"Founder and series editor: Dr Mustafa Mun. Written by AI models to a written standard. Exam keys checked blind by a second model: 3,665 of 3,666 agreed. Academic review invited.","review":{"status":"Draft, open for academic review"},"cite":"Addaly (2026) 'Capping the queue', in How Software Development Changed. Edited by M. Mun. Addaly. Available at: https://addaly.com/learn/how-software-changed/work-in-progress-limits (Accessed: 13 October 2026).","licence":{"name":"CC BY-NC-SA 4.0","url":"https://creativecommons.org/licenses/by-nc-sa/4.0/"},"reader":{"schema":1,"title":"Capping the queue","courseTitle":"How Software Development Changed","module":{"index":6,"slug":"teams-and-delivery","title":"Teams, process and delivery"},"answer":null,"keyIdea":"Capping work in progress moves effort to the constraint automatically and cuts time in system without changing throughput, and the argument that persuades managers is Little’s Law computed from the team’s own numbers.","hero":{"kind":"figure","figure":{"t":"figure","label":"Figure","figure":{"type":"bars","unit":"working days from opening to merged","title":"Same throughput, different time in system","series":[{"label":"40 open, writing doubled and nothing capped","value":10},{"label":"25 open, where this team is today","value":6},{"label":"12 open, capped","value":3,"highlight":true}],"caption":"Little’s Law on a team that merges twenty changes a week: time in system is work in progress divided by throughput. Capping changes nothing about what gets merged, halves how long each change waits, and gives every review more attention because fewer are queued."},"alt":"Figure: Same throughput, different time in system. Bars (working days from opening to merged): 40 open, writing doubled and nothing capped 10; 25 open, where this team is today 6; 12 open, capped 3. Little’s Law on a team that merges twenty changes a week: time in system is work in progress divided by throughput. Capping changes nothing about what gets merged, halves how long each change waits, and gives every review more attention because fewer are queued."}},"blocks":[{"t":"h2","id":"the-counterintuitive-move","runs":[{"text":"The counterintuitive move"}]},{"t":"p","runs":[{"text":"If review is the constraint, the correct response to a faster writing stage is to start fewer things. That sentence is correct, it is well supported by queueing theory, and it will be resisted by everyone who has ever been measured on activity."}]},{"t":"p","runs":[{"text":"The mechanism, restated: work in progress equals arrival rate times time in system. Hold the service rate fixed, raise the arrival rate, and time in system rises proportionally. Every extra item in flight makes every other item slower, including the one you most want finished."}]},{"t":"h2","id":"what-a-limit-looks-like-in-practice","runs":[{"text":"What a limit looks like in practice"}]},{"t":"p","runs":[{"text":"Per person: at most two open pull requests.","b":true},{"text":" When you have two and want to open a third, you must first get one merged, which means going and reviewing somebody else’s, or chasing yours through, or splitting it. The effort moves to the constraint automatically, without anybody having to decide it should."}]},{"t":"p","runs":[{"text":"Per team: a number on each column of the board.","b":true},{"text":" In review: five. In progress: eight. When a column is full, nothing enters it. The board stops being a list of everything anybody is doing and starts being a system with a shape."}]},{"t":"p","runs":[{"text":"Pull, not push.","b":true},{"text":" Nobody is assigned work. When you have capacity, you take the next item. This sounds like a small procedural difference and it is the whole mechanism: pushing work into a full system is how you get a full system."}]},{"t":"h2","id":"setting-the-number","runs":[{"text":"Setting the number"}]},{"t":"p","runs":[{"text":"There is no correct value and there is a good method for finding one."}]},{"t":"p","runs":[{"text":"Start at roughly your current average (count what is actually in flight today) and then lower it by one every couple of weeks until something hurts. What hurts first tells you where the real constraint is, which is the information you wanted."}]},{"t":"p","runs":[{"text":"If lowering the limit leaves people idle, that is a finding rather than a failure. It means your bottleneck is elsewhere, and the idle time is visible capacity you can move to it. Idle time that is visible is far more useful than idle time hidden inside a queue of half-finished work."}]},{"t":"h2","id":"the-conversation-with-a-manager","runs":[{"text":"The conversation with a manager"}]},{"t":"p","runs":[{"text":"This is the hard part, and the argument that works is arithmetic rather than philosophy."}]},{"t":"quote","runs":[{"text":"We merge about 20 changes a week and we have 25 open. That is 1.25 weeks from opening to merged, and you can check it. If we open 40 a week and review capacity does not change, we merge 20 and the pile grows by 20 a week, for ever. We would show more activity and deliver the same amount, with worse review on all of it."}]},{"t":"quote","runs":[]},{"t":"quote","runs":[{"text":"If we cap at 12 in flight, time in system drops to about 0.6 weeks. Same throughput, half the latency, and reviews get more attention because there are fewer of them waiting."}]},{"t":"p","runs":[{"text":"Two numbers, both from your own systems, both checkable. This works far better than any appeal to principle, because it makes a prediction and invites verification."}]},{"t":"p","runs":[{"text":"The follow-up question is always whether this means people will be idle. The honest answer is that they will be doing the work that actually moves delivery: reviewing, testing, pairing, deleting things, improving the pipeline. All of that is invisible on an activity dashboard and all of it is at the constraint."}]},{"t":"h2","id":"where-it-goes-wrong","runs":[{"text":"Where it goes wrong"}]},{"t":"p","runs":[{"text":"Limits without a rule for what to do when blocked","b":true},{"text":" just produce frustration. Write it down: when you cannot start something, you review, you help finish something, or you work on reducing the constraint. Not “start something else”."}]},{"t":"p","runs":[{"text":"Limits that ignore urgent work","b":true},{"text":" get abandoned in the first incident. Have an explicit expedite lane with a limit of one, and the rule that using it means something else stops."}]},{"t":"p","runs":[{"text":"Limits on a board nobody looks at","b":true},{"text":" are decoration. The limit has to be visible at the moment someone is about to break it."}]},{"t":"p","runs":[{"text":"Counting the wrong thing.","b":true},{"text":" If your limit is on tickets but the queue is in review, you have limited the wrong stage. Put the limit where the wait actually is, which you know from measuring stage times."}]},{"t":"h2","id":"the-deeper-point","runs":[{"text":"The deeper point"}]},{"t":"p","runs":[{"text":"A limit on work in progress is a decision to make the constraint visible instead of hiding it inside a queue. That is uncomfortable, because a visible constraint is a thing somebody has to answer for, and a hidden one is just everybody being busy."}]},{"t":"p","runs":[{"text":"But you cannot elevate a constraint you cannot see, and a system with unlimited work in progress is a system that has chosen not to look at its own bottleneck. In a period when the stage in front of the bottleneck got several times faster, that choice became much more expensive than it was."}]}],"check":{"question":[{"text":"A team imposes a limit of two open pull requests per person. Within a month, some engineers are regularly unable to start new work. What does this indicate?"}],"options":[{"text":[{"text":"The limit is set too low for the team’s throughput and should be raised to three until nobody is blocked."}],"correct":false,"tempting":[{"text":"Raises the limit to hide the signal, restoring the queue that the limit was introduced to expose."}]},{"text":[{"text":"Per-person limits are the wrong granularity, since capacity varies between individuals and a team-level cap would balance better."}],"correct":false,"tempting":[{"text":"Team caps have advantages, but they would smooth over exactly the blocking signal that is telling you where the constraint sits."}]},{"text":[{"text":"The team is writing faster than it can review, which the limit has made visible rather than caused."}],"correct":true,"tempting":null},{"text":[{"text":"Reviews are being left too long, so the fix is a service-level agreement requiring first review within a working day."}],"correct":false,"tempting":[{"text":"A review SLA is a sound complementary practice, but it addresses latency within the stage rather than the capacity mismatch causing the block."}]}],"order":[3,1,2,0],"why":null},"prev":{"slug":"estimation-and-the-demo-effect","title":"Why everything looks nearly done","minutes":9},"next":{"slug":"planning-verification-as-work","title":"Putting verification in the plan","minutes":8}}}