Queue or Stack based development scheduling

There are two naive approaches to scheduling new features: queue based, where new bugs/features go at the end of the queue and stack based where the latest hottest idea or bug gets pushed to the front of the line.

The advantage of treating your scheduling like it queue is that it is very predictable. You know how much work is left until you get to a certain item. Of course there is uncertainty in how long a task will take, but you can at least tell what will be delivered in the next few weeks with some accuracy and you will eventually get to all tasks. The downside is that even the smallest fix might seem to take forever and that feature your truly believe in, is estimated to be started March next year.

Always putting the latest idea at the front, does make it possible to respond much quicker. That annoying spelling error, fixed the next day. A new feature idea from the director? You will have it finished in two weeks. Except that it becomes some sort of gamble: will you get to it before anything even more shiny and new pops up. Is that latest idea you dream up really the one that provides the most value? Are new ideas better than old ones?

I would say both extremes are dysfunctional. Neither is an efficient use of time and resources.

A common approach to become more functional is by giving discrete priorities to tasks. Must, should, could; 1, 2 ,3 ,4; low, medium, high, critical, to name a few popular categories. However on anything but the smallest projects this quickly becomes a queue of important items and a pile of ‘ignore forever’ for everything else.

The ideal is somewhere in the middle, which would basically be a sorted heap, the most ‘important’ task is always on top and everything else is weighted and waiting for its turn. This assumes we have a way to assign a value to the priority of a task. How to go about that? In the end you need a proxy or estimate for ‘value’, but what is the value of fixing a bug? Is changing the color of the font really ever important?

Even if you can somehow accurately determine priorities, what I think is an often ignored fact is that time changes priorities. This can go both ways: not acting quick enough on an opportunity may mean your competitor gets their first or it’s simply gone. On the other hand what was once an optional security best practice can change to an absolute necessity.

So what do we need?

  • objective data to determine priorities, you can’t keep trying to compare every item to every other item
  • priorities needs regular revising
  • the way priorities are set, depends on the working area
  • not every type of task has comparable priority, so instead you need to value the category as a whole
  • it’s easy to ignore certain aspects of a business or project that will hinder your progress as a whole ( e.g. marketing or security )

These observations and ideas are what form the foundation for Plan 49.

Leave a Reply

Your email address will not be published.