Could somebody explain how queue theory fits into agile processes? Where are these unmanageable queues, that need to be emptied coming from?
Queue theory only becomes a problem when (1) stories are being added to the active story queue at a furious rate; and (2) nothing gets shipped until the active story queue is emptied. I don't think think either of those things are supposed to be true in an agile process, especially the last.
It sounds suspiciously like a symptom of gamification to me (if new stories are being added by the development team). Or a broken process where field defects (which are supposed to go to the top of the queue) are so numerous that they completely overwhelm active development, which is an entirely different issue, requiring an entirely different response from management.
If story points are so wrong that it no longer fits in a sprint, it seems reasonable to split the story. In my experience, I don't think I've seen it happen more than a handful of times. How often is an initial story point estimate so wrong that it has to be revised upward to the point that it no longer fits in a sprint? If it's wrong, but still fits in a sprint, just do it. It makes me wonder whether there's gamification going on around using story points to evaluate developer performance.
(Assuming that stories are converted to tasks at the start-of-sprint meeting).
Queue theory only becomes a problem when (1) stories are being added to the active story queue at a furious rate; and (2) nothing gets shipped until the active story queue is emptied. I don't think think either of those things are supposed to be true in an agile process, especially the last.
It sounds suspiciously like a symptom of gamification to me (if new stories are being added by the development team). Or a broken process where field defects (which are supposed to go to the top of the queue) are so numerous that they completely overwhelm active development, which is an entirely different issue, requiring an entirely different response from management.
If story points are so wrong that it no longer fits in a sprint, it seems reasonable to split the story. In my experience, I don't think I've seen it happen more than a handful of times. How often is an initial story point estimate so wrong that it has to be revised upward to the point that it no longer fits in a sprint? If it's wrong, but still fits in a sprint, just do it. It makes me wonder whether there's gamification going on around using story points to evaluate developer performance.
(Assuming that stories are converted to tasks at the start-of-sprint meeting).