If you believe in the theory of constraints, then you know that you can only get as much done as you can have flow through your system at once.
What is your system? It’s the entire development process from idea to in your customer’s hands. It’s the people, processes, and tools that are part of this process. It’s influenced by the contexts present in your system. It’s the physical, emotional, and mental aspects of the work you do and the people who are a part of the software development process.
Now, back to this idea of flow. It’s not perfect, but for teams that struggle with getting valuable software into the hands of their users, flow can get you a long way. Basically the idea is that the faster you can get value into the hands of your users, the better (I’m assuming you’ve already determined that what you’re making is valuable to your users).
If you imagine a running faucet in a tub (the input), the water filling in the tub, and the drain (output), you know that you can’t just turn on the faucet and expect water to leave the tub at the same rate it’s going in. That difference is excess waste. Since you can’t just turn the faucet on all the way and expect water to flow out of the tub as fast as it flows in, you may as well turn the faucet down to what can make it out of the tub as fast as it goes in (Special Thanks to Donella Meadows work “Systems Thinking” for this analogy).
Guess, what, your development process has the same constraint, and the chief way you turn that faucet too high is by having priorities. Not priority singular, but priorities, plural. When you have more than one priority, you’re trying to fill your bathtub too full and expecting water to still flow out at the maximum rate it flows in. That doesn’t work.
Instead, by lowering your rate of flow to what can go through your system without backing up, by focusing on a single priority, you can get value to your users without delay, and without gumming up the works.