The Checkout Line: Why is it so slow?
This post originally appeared January 10, 2011 on BetterProjects.net
photo © 2008 The Consumerist | more info (via: Wylio)
My wife and I have a running joke that if you want to spend a long time waiting around to leave the grocery store, you let her pick the line. Its uncanny that nearly every time we decide to not use the self-checkout, we get stuck behind the person who picked up 14 items without barcodes or in the line with the cashier who has decided to work at ¼ speed this day.
Given that my day job is to manage requirements for a point of sale system, the time spent waiting in line at the store ends up being rather ironic, but it does force me to think about what motions and systems work well and which ones could stand to be improved.
This is why the following video on Queuing Theory was so interesting to me:
The part of this video that stood out most to me was the most efficient way to lay out a checkout line, with a single line feeding multiple registers, was also the most emotionally frustrating way for customers. I know that when I’m standing in line for a roller coaster, with one massing long line up until you reach the station where that one line breaks up into a dozen small lines for each car, that the long line frustrates me, but that frustration goes away when i can pick my own short line.
I think there are some good applications to projects, especially when it comes to release management. Consider the situation where two stakeholders come to you with different problems. You know that in your next release, you have enough open resources to fulfill one of the requests, but not both. There are a couple ways you could consider to figuring out which you fulfill and which must wait.
You could use first in first out (FIFO) methodology and pick whichever request reached you first. This fails to take into consideration the severity of the problems. If both requests took the same time to develop, but one would bring in double the revenue of the other, then wouldn’t it make more sense to do the one with larger revenue first?
But what if the one that would make less revenue has an impact to a government contract which must be in place due to a legal requirement? In this situation, no matter the revenue implication, the regulatory requirement would like get pushed to the front of the line.
So what method does your team take to ‘queuing’ up items for the next release?