I wouldn't put unimportant tasks in the stack; that would mean you do those first. Fast turnaround tasks are best for the stack. Tasks which involve multiple

I wouldn't put unimportant tasks in the stack; that would mean you do those first. Fast turnaround tasks are best for the stack. Tasks which involve multiple parties & thus planning and coordinating are best for the queue. Many organisations already deal with this in having first line and second line support; first line pick off the quick stuff and log the hard stuff; second line then work their way through the hard stuff/ First line will also put a task on hold if a new call comes in; their priority is to answer the phones/get things logged, with working on resolutions taking lower priority. So first line support's a stack, second line's a queue. As the blogger mentions though, generally things are mixed; whilst there will be a preference/default working style most people/teams will fall somewhere in between, usually adding some level of prioritisation. Another point is that prioritisation is generally based solely on the importance of the task & detailed analysis of its implications for queue people, whilst stack people will tend to guess at both the importance and the implementation time to get a priority based on the weightings of both factors.