[skybrian]

A backlog is not a queue. It's just a mutable list. A principle of Agile is that you can change your priorities and reorganize the backlog to put the currently highest-priority stuff first.

(This isn't unique to Agile - any bug database could do this, though they don't typically stack-rank things.)

Putting high-priority tasks first increases responsiveness for them, but will starve lower-priority tasks. That's inherent, but at least management gets to prioritize.

[hinkley]

> A backlog is not a queue.

That's only slightly true, and it's a dangerous assertion from a process standpoint to say it is so. Everything is queues. Work in progress, undeployed code, dark features, sales pipelines.

There is a queue of requirements we have defined but haven't acted upon. That's contained within the backlog, along with bug reports and wishful thinking. The backlog is approximately a superset of incoming feature request queue (modulo anything that skips the backlog and goes straight into WIP)

[Jtsummers]

To expand on your point: Queueing theory applies whether the thing is a proper FIFO queue, a LIFO stack, a statically prioritized priority queue, a dynamically prioritized priority queue, or a bunch of cards grabbed randomly out of a hat. If things keep coming in faster than they can be handled, the queue, no matter its form, will just continue to grow. That a backlog is not a proper FIFO queue in most orgs doesn't change this fact.

[skybrian]

I still think "mutable list" describes the situation better than "queue," at least for programmers familiar with common data structures. No argument that queuing theory is useful.

Defining "responsiveness" in terms of everything that anyone has ever wished for seems like a bad thing, though. We can have a brainstorming session that comes up with a long list of features that would be nice to have, end up throwing them out, and that's perfectly fine.

[hinkley]

I think you have a poor understanding of what queueing theory is. You should read more and type less.

[barfbagginus]

Attacking someone's knowledge level does not dismiss their argument, which is that you might be imprecise in your use of the term responsivity in your first statement, and could be using it to impress rather than inform your audience.

Let's get to the bottom of this in an illuminating and polite way, without further insults.

You made two statements about responsivity:

1. If your queue is 100% saturated you have 0 responsivity.

2. It's common to see maximum responsivity if the team is only pushing 50% of their maximum throughput.

I'm assuming that you are either

1. defining a responsivity metric for backlog items and using it consistently in both cases

2. Using responsivity in the imprecise business consultant sense of the word which is being criticized

Case 1: You're a serious Queue theorist

If you're doing it in the first sense then could you please give us a more technical explanation of which responsivity metric you're talking about and how these relationships attain?

Some questions there:

1) I can't find a responsivity metric in basic queueing theory. I find average occupancy, thoughtput, waiting time, service time, etc - all metrics which describe /aspects of/ responsivity. Can you point us to more specific and holistic responsivity metrics you have in mind? What makes it the "right" metric to capture something as abstract as responsivity?

2) How can a saturated queue have no responsivity? It seems that saturated queue - which I define as a full queue that is still serving requests - still responds in the average waiting time, plus now there's a chance that the request is rejected by a full queue. Assuming the queue is still serving, there should be some nonzero probability that a request will be served, because a position in line opens up, for a brief period, every time a request is completed. So responsivity can't be strictly zero, can it? It would make sense to me here if our responsivity metric drops so close to zero, compared to normal functioning, as to not make any effective difference. For example, if 95% of our requests are being rejected, and all accepted requests have awful waiting times, then it makes sense that responsivity should be considered effectively nil.

3) where can I learn about the model where maximum responsivity requires some sacrifice on throughput? Usually for this kind of result we have some curve, we take it's derivative, and it turns out the critical point is some equilibrium or maximum. Do we really have the ability to do this for coding teams and their backlogs? That could give us serious objective power in negotiating our work throughput! But it requires a trustworthy model.

Case 2: Your a business consultant and you're laying it on a little too thick

Finally, if you're doing it in the second sense, then you are using the term in the sense that is being criticized. In particular, using it without a formal definition, in a way such that a business audience would hear "responsivity" as whatever metrics they care about most. That would mean you use queuing theory terminology to misinform and manipulate those unfamiliar with queuing theory - probably the most used application of queuing theory in the industry. If you're intentionally doing this, and willing to insult people who call you out for it, we probably couldn't persuade you to own up to it or stop. But if you're not aware of it, you might reconsider how you use queuing theory terms, and commit to being accurate and objective. I state this not only for your benefit but for my own benefit, and for the benefit of anyone who might use technical terms imprecisely! It's always best to be able to ground technical statements in objective theory.

Conclusion

Assuming that you are using the term accurately, with a particular metric in mind, I'd love to learn about it and analyze the metric in our two pet cases. If you're being shady, I hope you'll recant and improve the accuracy and honesty of your language. Thanks for your patience and dialogue!