Prioritze tasks for web and software development : Issues

Any product manager or business analyst has always been stuck with how to prioritize stuff and development work.

The basic approach that people generally use to prioritize development tasks:

• Write down all the pending development items, as and when you think of them at a common place.
• Assign them a priority of high, medium or low [or something fancier] and pick up the high priority items first.
• Keep compiling the list of most high priority items as you go. There are many problems in this kind of prioritization.

The major problem is that any decent sized project/ product would have a lot of development items as open. And most of these items are always high priority or medium priority but not low priority. Hence, you have to do a nested priority tango [where you prioritize between high priority items further with something like Very High Priority, Super High Priority etc], till you are left with the items you can pick up for the next release.

Although very simple to look at, as the data grows, this method becomes a complete mess for you to manage your priorities and also takes a lot of time for managing the priorities. In addition, this gives some items with low priority a wrong interpretation – these are not important, and even worse, confuses the high priority items as the most important. Another major problem that development teams face is classifying the items as bugs, defects, new features, revision of old features etc and sort of prioritizing within this.

Hence, the main problems in the main approach is:

• As the data grows, managing the priorities becomes an issue
• Making an item/ task as not important, low priority, can wait, not urgent, good to have – makes people take those tasks/ items lightly
• Prioritizing within the items/ tasks – bugs, defects, new features, revision of old features

A quick review of Internet threw up some variations of this approach:

• OrganizeIt.com suggests that you should prioritize the stuff between must do, should do and would like to do. The only problem with this approach is that different arguments can convert a would like to do into a must do.
• OpenBravo has a delicious looking approach to development process management and takes a linear time bound approach for each task. I have not used OpenBravo as yet but probably this would probably work well in some circumstances as long as you make sure you enter the right data.
• A common approach in Scrum Projects is to have teams gather around for a Sprint Planning Meeting and arrive at a consensus on what they would need to develop in the next sprint. Everything else waits. This is a good approach. However, the work involved in estimation of the items/ tasks and discussions can sometimes extend. This is not a problem with the approach but signifies something else [communication gap between the teams and product owner]. Unfortunately, not many people would see it like that [I will cover this topic in more detail later].
• Another very effective approach [again borrowed from Scrum/ Mike Cohn’s work] is to first draft coarse grained requirements and refine the ones that are immediate priority. This takes care of not having too many requirements/ items while still having enough detail for meaningful priority for the tasks / items at hand.

Now that, we have discussed in brief what we probably already know, I will try and analyze why these problems appear.

• No single product owner
• Too long a time before priorities can be changed
• Wasted effort on not so hear horizon tasks [which might never get done, or are changed when those are picked up]

However, the biggest issue is that prioritizing the above way gives you a false sense of security that you understand how the future would unfold. You lock yourself up in decisions [based on a prediction of future, and a growth path/ evolution of product or features]. This is the exact mindset and belief which Agile [or “a”gile ???] seems to correct. The product management teams and development teams, both need to be open to all possibilities. Unless the mindset which develops the products is open, we fight keeping the natural progress of the product [based on customer requests and inputs] at bay.

Now that we have seen the issues in prioritizing using conventional techniques, lets try and see an alternative approach to prioritization.