Initial Issue Creation

After the initial up-front activity to get a handle on the basic feature set and Release Planning, we enter the tasks and features into the issue tracker system. From a high-level customer prioritization of the major feature sets, we can add in our technical development needs and come up with a rough plan of attack for the first handful of iterations. That's the EASY part!

Balance Tip
We always try to balance doing just enough work to be effective, but not going too far into the future where our efforts turn out to be wasted. Therefore, you should not plan out 20 iterations in great detail, as that is surely a fool's game.

<insert some TBS graphic>

Ongoing Issue Handling

For a long-term project, you will find yourself getting into a sticky mess with too much backlog if you are not careful. New issues (feature ideas, bugs, improvements, tasks) can arrive at any time -- from customers, from developers, from testing, from marketing. Managing those issues from the beginning starts with ensuring they are written well, and are not a duplicate. As we move through producing the release in a number of iterations, we continuously need to pull the next set of issues out of the issue database (see Management by Bucket, below), and schedule and estimate the iteration, and execute against the list of issues.

As we near a release, we begin to need to handle parallel development. Some issues are critical and need to be put into next week's build to TEST. Other issues are long-term, and are part of a more strategic set of features, or re-architecting. You may release new features to Production every iteration, or you may need to release every few months or maybe once per year. If you have to make interim fixes to the released product along the way, then you need to be set up for, and proficient in Branch Development techniques.

To put it in perspective, here is a snapshot in time of the issues for our Sales Portal project that is at the initial product release point in its lifecycle:


You can see the following:

• 11 issues in progress (for the current iteration)
• 343 open issues (you can't tell which milestone they are in, if any)
• 13 critical (0 blockers)
• 266 with the same priority of immediate
• 68 Eventual
• 5 Optional
  
• 8 issues reopened (undoubtedly due to testing discovering they weren't working quite right)
  

Management By Bucket

Once the project has been going on for some time, or after production, the issues are often flying in faster than you can ignore.

Instead of worrying about ranking a new issue in absolute terms, I tend to manage in big "buckets" as issues arrive. The first bucket is the "All New Issues" bucket -- whether it is a bug, a task, a new feature. The issue needs to be "scrubbed" -- it may be unclear, it might be a duplicate, etc.


Only when we get to Iteration or Release Planning do I begin to care about the true prioritization. For me, this is easier in that we don't waste time agonizing over a fine-grained priority of some issue that may not see the light of day for months.

Bucket	Intent
1st in line	We need it ASAP. Waiting for resource availability or milestone.
2nd in line	Needed next.
3rd in line	Would be a nice to have if we have time.

Some great new ideas for a feature might get tossed into the "1st In Line" bucket. Another idea might simply get tossed in the big "Next Release" bucket. Some bugs are high priority and get into the very next iteration. Others languish, or get picked up in an iteration when (1) we are working in that area of the app anyway, and (2) we know it is an easy fix. Some bugs may never get fixed and some issues may never get developed. It all depends on what the business chooses to spend time and money on.

You might even want to consider creating a bucket called "Reject" or "Not Wanted" if it is important to make it visible.

When it comes time to do Iteration Planning, we can pull from the candidates in the "1st In Line" bucket, then the "2nd In Line" bucket, and so on -- should we need more.

I find this easier than dealing with 100s or 1000s of issues in a single "bucket" to pull from for the next iteration

Tracking Progress

You can keep track of issues closed and added per milestone, either via homegrown excel chart like below, or with an already-supplied output from a tool.


Or another view: