Like-to List: Basketball Queuing

I think the moment I was sure I wanted to pursue Operations Research came on my way home from playing pickup basketball.

It’s probably not safe to assume you (the reader) have extensive experience playing pickup basketball at Gregory Gym, so here’s how it typically goes down.

Five-on-five games are played to 30 (the first team to score 30 points wins). There are three basketball courts. If all the courts are being used, you pick a court and wait for that game to end. At the end of the game, the winning team stays on and the losing team steps off. This means there’s typically room for 5 new people in the next game. To settle this issue of who plays when, players will call “next,” when they arrive at the gym, which basically gives them the right to play after a given game. They recruit four other players, and that’s the 5-man team they’ll run with. Once that team is filled up, someone “calls next” after them, and you have another team waiting. Now we have a queue.

Things get just a little more interesting when one or more courts is empty. You can start a new game on the court, but that only works if you have 10 people who are all waiting at the same time. So until you get that many people, your service time is just based on the courts that are still running games.

All of this together is a fairly simple queuing model. The number of service stations is dictated by the number of people in the system. And if we assume exponential arrival times, it’s fairly simple to model the movement from waiting to playing on a court to introducing a new court to play on. Based on the arrival time, you can predict how long it takes to get a new 5-man team, then calculate all of the classic performance metrics like average waiting time and average time spent in the system. The necessary data would just boil down to finding distributions for arrival times and the length of each game.

But my earlier description is a gross abstraction at best.

The first assumption I made an was that there are never more than 5 people entering a game. But that assumption isn’t safe; sometimes one or more players on the winning team leaves, either to stop playing or play on an incoming team (like, for example, if their friend has “next”). The model would have to evaluate the probability of the winner of the last game winning again, along with the conditional probability that all of their players exercise that right and play another game. Having winning players drop introduces open spots for new players, increasing the service rate.

The process I laid out earlier makes another convenient assumption: players try to play as soon as possible. This assumption is completely wrong. When a player has “next,” they don’t always recruit players who are waiting. Sometimes they wait for their friends. Other times, they wait for the game to end to recruit the best players from the losing team. That kills the service rate; instead of having 5 new people play a game, you may only “serve” 2 or 3 more players.

Another complication comes with the selection of courts. If you do find 10 people waiting, they may not want start a new game. At Greg, the central basketball court during busy times has the most competitive games. A good portion of people will wait two or three games to play on that court instead of playing immediately on a different one.

Lastly, every player plays a different number of games. The simplest way to model this would be with each player playing until they lose. But often, players will lose and wait for a new game (with any luck, on an easier court or with a better team). Since different people have different tolerances for waiting times, this introduces another layer of randomness to the model.

When I first understood the premise of a queuing model, pickup basketball was a simple way to illustrate it. There are service rates and arrival rates, just like any classic example. But the process is so much richer than I first realized. Within the pickup basketball “system,” there are layers and layers of randomness introduced by the players. While I believe it would be an interesting exercise to actually model this process, the data collection would be an incredibly time consuming process, and at the end of the day my understanding of queuing just isn’t good enough to account for all the system’s complexities.