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.

    Advertisements

    2 Responses to “Prioritze tasks for web and software development : Issues”

    1. One of the ways I like to help product owners prioritize is with the business value view. This is cost divided by perceived $$$ value. This allows low priority items to still get caught into a sprint. Example: low priority item will provide $100 of value with 30 seconds of work = do it! High priority item will add $10,000 of value but will take 3 weeks… hmmm.

      One of the ways I like to help the team manage the backlog is by encouraging a horizon view:
      The first horizon is the current and next sprints, all stories must be granular, estimated, and ready to be picked up into a sprint.
      The second horizon is the 3 sprints further out and all stories must be estimated and have a very high level design.
      The third horizon (everything else), must be understood conceptually and maybe estimated if they are in the “release”.

    2. Howard Fine Says:

      I agree in how important it is in so many areas to prioritize, and this is one of the most important for many of us. I’ve often had 2nd thoughts about the process used to prioritize and my ability to feel a strong level of confidence that I can rely on the results. I just found a new product that I immediately signed up to beta test when another Director sent me this link… what a powerful, yet simple way to confidently prioritize.

      http://go.catalyst.com/?linkid=8034156

      Cheers,

      Howard Fine
      Director of IT

    Leave a Reply

    Fill in your details below or click an icon to log in:

    WordPress.com Logo

    You are commenting using your WordPress.com account. Log Out / Change )

    Twitter picture

    You are commenting using your Twitter account. Log Out / Change )

    Facebook photo

    You are commenting using your Facebook account. Log Out / Change )

    Google+ photo

    You are commenting using your Google+ account. Log Out / Change )

    Connecting to %s

    %d bloggers like this: