back
|25 Mar 2014|System User

The Pre-queue: See what's after next

2

The idea of the pre-queue came about three years ago in a system design workshop with a Swiss financial services company as we were contemplating the input queue and its dimensions. We thought a weekly queue replenishment would be good and set the length of the queue to 8 as the staff assumed that this was the maximum number of tickets they could close in a week. After trying out a short simulation of how the kanban system would behave in real-life operation, there were mixed feelings about the input queue. “Surely you don’t believe for one moment that our stakeholders can decide which are the next eight items we should process,” one of the heads of department said. An experienced developer continued with the argument: “Not only that they have to agree on the next 8 work items – they are not allowed to change their minds. As soon as something lands in the input queue it cannot be removed. That sounds like science fiction in our current way of working.”

A testing assistant spoke up and countered: “Yesterday we were still speaking about what we were dissatisfied with,” she says going to a list of improvement wishes and points to a specific card.” And in second place in our pain points we can read here ‘We want to know what is to be done next.‘ We get this information from the input queue. If we take a look at number 5 on our improvement wishes, I read ‘We want our priorities to stop changing constantly’. We can address this with a controlled input queue. As soon as a task is hung up, we do it.” Everyone nodded in agreement but they did not seem really convinced that the stakeholders would agree to this change.

The analysts’ perspective

We decided spontaneously to ask two of the stakeholders – business analysts – to join the workshop and to discuss the topic with them. That worked really well, because we then understood better what their wishes were. “Above all, we must be able to react flexibly. It’s just the way things are the time and new opportunities come up and we want to be able to respond to these,” one of the business analysts said. A recurrent pattern in system design: One wants to achieve maximum room for maneuver and the others want to know exactly what is to be done next. Opportunities can also be addressed with classes of service, which also was suggested by some people. In this particular situation it was, however, a matter of ensuring that the stakeholders did not want to state categorically the standard work they required one week in advance.
The other business analyst continued to argue. “Another important point is that we want to see what will be completed by you in the coming two to three months. If you want this thing-a-me-jig queue, then we must set the limit to at least 64 – which matches your calculations for two months. But as already mentioned before, we must be able to permanently change the sequence, otherwise you are cementing in the agility we require”. And this is where the A-word fell: agility. I did not want to open this big door once again and bit my lip. A discussion between agility vs. chaos is the last thing we needed. 

Large and small at the same time

In my role as moderator I tried to sum up the discussion: “I have heard that the main issue is that priorities keep changing and that you want to know what work you can expect in the coming period. We can achieve this through a regulated flow to the kanban system – the input queue and queue replenishment. From the business analysts I heard that for you it is important what can be achieved within a large time window. But you want to maintain flexibility so that the sequence of tasks may change.” Fine, at least we have consensus on the issue. 
My brain was ticking like mad: More flexibility or agility is achieved through a shorter input queue and more frequent replenishment. We could reduce the input queue to four and replenish it twice a week. That would give us more flexibility but we have reduced predictability from the desired two to three months to half a week.  Simultaneous large and small input queues cannot be created. So the solution does not lie with the input queue. I made the following suggestion: “What would you think if we built a pre-queue in front of the input queue where the stakeholders could change the sequence? This queue could be large so that you have the necessary predictability. 64,  for example, corresponding to two months. At the same time we reduce the input queue to 4 and it is replenished twice a week giving you greater flexibility.” After some discussion we came to a common understanding of what the benefit of the suggestion could bring and we agreed to simply give it a try. It cannot be stated enough. In Kanban system design pragmatism is what is needed. The initial design looked similar to as follows:

A few weeks later

When I visited the company again a few weeks later, a lot had changed. The pre-queue was reduced to 20, because it turned out very quickly that the business analysts were not able to define 64 work items in advance. The size of the input queue had increased to 9 and it was replenished only once a week. The issue of queue replenishment had caused a lot of interactions among the stakeholders and so the permanent reordering of tasks was reduced significantly. 

What are the benefits of a pre-queue?

What had I learned? A lot! I identified the following main reasons why companies often go for a pre-queue:
  • Look ahead: An instrument to see what may be achieved within a lengthy period of time. 
  • Higher agility: The input queue can be kept small so one can react faster to changing conditions. 
  • Shorter lead times: The input queue can be kept small which leads to reduced lead times for individual work items. 
  • Late commitment: The contents of the pre-queue can change continually, something very valuable for business analysts.
Stefan Roock
25 Mar 2014 23:24

Sounds like a Scrum-like Product Backlog or do I miss the point

Klaus Leopold
26 Mar 2014 08:28

I think the pre-q would be in between the sprint backlog and the product backlog in a Scrum context. I’m not a Scrum expert, but my understanding is that items in the sprint backlog are committed and ready to be processed which can be compared to the input queue. Items in the product backlog are not committed and not ready to be processed which can be compared to the idea pool or work pool or however named in kanban.

Items in the pre-q are ready to be processed but not yet committed – id est options. A lot of kanban systems use a very small input queue in order to react on opportunities and other external factors very quickly (= improved agility). If you replenish the input-q multiple times a week (which would be multiple Scrum sprints a week) it turned out to be useful to have a small window to the future to answer the question “what other stuff will arrive soon”? The pre-q is this small window to the future.

This conversation lacks your voice:
Your E-Mail Address will not be published.