top of page

Finding Hidden Queues in your Workflow

Queues are steps in your process where multiple work items wait by design. They serve different purposes (like smoothing out flow, or supporting batching policies), but very often they are implicit, or hidden, and therefore difficult to see, and their impact (or usefulness) difficult to assess.


The following video explores some questions you can ask about your process to help you identify those hidden queues. You can also read a summary right below.



๐Ÿ™‹ "But we don't have queues in our process!"

๐Ÿ‘€ "Do you rely on anyone who is not 'instantly available'?"


If work is ready for someone before that person is ready to work on it, the result is often the formation of a queue. An example of this is your PO, in cases where final approval for user stories is needed.



๐Ÿ‘€ "Do you have explicit hand-offs between team members? is any work collected to be processed in batches?"


If pieces of work need to go from one group of people to another, or if you need to accumulate "enough work" to proceed to the next stage, then often the result is the formation of a queue.




๐Ÿ™‹ "But we do Continuous Delivery and deploy quickly to production, with little delay!"


๐Ÿ‘€ "Is there any 'done' work waiting for other work to be 'done'?"


If yes, it may indicate that your process includes a step for final integration (wiring front end to back-end, for example), which is often preceded by a queue.


๐Ÿ‘€ "Any 'done' work not usable by the Customer yet, waiting for "enough work" to be deployed to form a meaningful release?"


If yes, then there's a queue of work waiting to be activated (by "feature flag", for example)




๐Ÿ‘€ "Do you have any internal verification / approval step? (by team leads, for example)"


If you do Code Reviews, or Test Case Reviews, or any other step where work needs to be verified by some other team member (often in a senior position), very often that results in a queue forming while work waits for the other person to be available, or until there's enough of a batch to proceed with the review.



๐Ÿ‘€ "Is there a mechanism to prevent starvation (being idle because work isn't ready)?"


Refinement (or "grooming") often results in an inventory of "ready work", that has to wait until selected. That's a queue.


๐Ÿ‘€ "Do you preselect work for development in batches?"


Replenishment meetings essentially result in the formation of an "input queue" at the process' front-end.


๐Ÿ™‹ "Ok, we have some hidden queues. What do we do now that we can see them?"


Ask more questions to understand how they work:

  • How long does work wait in the queue in average? How significant is that delay? What would it take to shorten it?

  • What's the average size of the queue? Is there a limit? Would it make sense to impose a limit? If so, what would that limit be?

  • How is work selected from the queue? (FIFO? LIFO? random?) What's the impact of this decision? Would it make sense to make this an explicit policy? or to change it to something else?

  • If used for batching, how big are the batches? What's the purpose of the batch? What would the impact be of making it smaller or bigger?

And then, the most important questions:

  • What's the purpose of having this queue? How is this queue helping? or not?

  • Would it make sense to remove it? if so, how?


45 views0 comments

Recent Posts

See All
bottom of page