Just for fun, I was recently reading about queuing theory (that’s a normal thing people do for fun right?). One of the things that you need to think about in queuing theory is scheduling policy. There are a number of different way that you can pick which object in the queue goes next. One scheduling policy that intuitively makes sense to me in the first-in, first-out policy. Basically, you would pick the thing that has been in the queue the longest as the one that goes next.
But you can also choose to use a last-in, first-out policy. That doesn’t seem very fair to me. Think about waiting in a queue at the grocery store. You’ve been in line for a while, and someone else comes along and stands behind you in line, but when the next chashier is ready, they help the person who joined the line after you. The last one to join the line is the first one out. Why would you ever choose this scheduling policy?
Well, since I was just reading this for fun, I didn’t bother myself about it too much, but then a couple of days later it hit me that we often use a variation of this policy in the way we manage our backlogs. Things that have been recently added to the backlog are more likely to be worked on than things that have been there for a long time.
Why is that?
One reason for it might be availability bias. The newest items added to the backlog are fresh in our minds and so they seem to be more important. This is a bias, but since software is built by humans, for other humans, it might not be so bad to have human biases in the decisions. Things that are fresh in our minds are probably fresh because they are related to new features that we were working on. These things might be ok to work on first as they might be fresh in our clients minds too. Of course, we should still at least give a little bit of thought to that before assuming it is true in every particular situation, but it might not be an all bad thing.
Another reason for using this kind of queue scheduling is that it might be cheaper to work on stuff that is fresh rather than having to get back into an old context. If we have just created the story or filled out the details on a defect, we should have a pretty good understanding of what we need to do for it. This can mean that we can more quickly complete the newer work in the backlog than we can the older.
I don’t want to gloss over a glaring reality though. The last-in, first-out policy means that those poor items at the front of the queue are very unlikely to ever get a turn. Since there is always more work to be done than there are people available to do it, without some other mechanism to bubble up those older tickets they will languish forever. Most teams have mechanisms that do this (even if they are not deliberately put in place). For example, a client might escalate a known issues and hence bump it up in the queue.
But can we be more intentional about them? What do you think? What are your strategies for dealing with those old defects or stories that have been in backlog for years?
offbeattesting 