One of the important concepts of the Theory of Constraints is to reduce the amount of inventory in a system to help with the overall goal of increasing the rate of throughput of the system. Inventory is defined as the money that the system has invested in purchasing things that it intends to sell. In software development, inventory is things like software licenses, equipment, or even process artifacts that comprise the components of a release.
The typical start of software development processes is to estimate requests for business stakeholders. The requestor wants an estimate of cost and time while the software manager needs the estimate for planning people allocation, time, etc. Once labor is expended on the estimation effort and some type of answer is generated then the system has a level of inventory in it (the estimate becomes an artifact and money is spent to generate it).
If the request is rejected at this point it becomes process waste because money was spent that will have no investment return (although better to spend a little money early than to realize you need to cancel later). If the request is moved into a queue that awaits the next step in the process then it becomes inventory. The problem arises when the requests hit the process bottleneck and start to queue. The work-in-progress becomes a growing inventory which extends the time before the company can start to realize a return on their investment.
A growing inventory of estimated work in queue
Thinking back to the Theory of Constraints, we want to reduce the amount of inventory in the system. One way to do this is to control the rate at which requests are released for the initial estimating step. Instead of estimating every request that enters the system and then placing the estimated effort on the backlog, we can place new requests into the product backlog. The product manager is responsible for prioritizing the backlog based on the business value, not cost. Then when the team is ready to start working on a request the product owner and the team work to estimate the scope of work of the top items on the backlog. Think of it as pulling the top x items off a shelf. The idea is to pull as many items of the top of the list that the team can fit into one cycle of the software machine (an agile sprint).
This technique closely mirrors the agile methodology of Scrum. I like it, because it also helps to reduce the inventory in the software machine and works towards delivering software for an earlier return on investment to the business. The product backlog acts as a buffering mechanism to control the release of work into the system.
Work queues outside the software machine (buffer) to reduce inventory