The Next Generation: ALM Tools for an Agile World

tasks and to assign them to an iteration.  It must also allow us to right-size the tasks.  No sense in having a 4-month task with 2-week iterations.  The agile process being used must allow tasks to be broken down into roughly iteration-sized tasks, though some may have to span multiple iterations.  The ALM tool must allow a representation of such a work breakdown, and must also facilitate it's creation by allowing us to track and identify sizing.  Furthermore, the ALM tool must allow us to express dependencies between tasks, so that if we see one, we can rapidly and easily record it so that the ALM tool will bring it to our attention if we try to implement one task before its dependencies have been completed.

In the end, we will have a product backlog, release backlogs for the product, and iteration backlogs for each iteration within a release of the product.  The ALM Tool must make it easy for all team participants to view these backlogs.  Some want to view it from a product perspective, some from a developer's perspective.

4. Priority-based Scheduling
The basic process we've just discussed is really a priority based scheduling process.  What we're doing is taking our requirements, converting them to tasks and prioritizing those tasks. This process isn't really much different from a traditional approach except for a few key points:  we don't know all of the requirements yet;  after prioritizing tasks, we don't have to associate start/end dates with them, just iterations, and this is done in an ongoing, rather than a big bang, fashion;  we do some right-sizing of the tasks to fit our iterations, though some tasks may span more than one iteration; and we allocate requirements to tasks, rather than to the "next level" of requirements.   

Such a priority-based scheduling capability within an ALM tool will also be able to support a traditional project, provided the ALM tool can also assist with traditional scheduling.

In an agile world, we're going to hit road blocks along the way and we'll have to adjust priorities.  This is fine if we're using a priority-driven development process, as most Agile methods are.

Now as well as these tasks that come from requirements, there are problem reports/defects/bugs or whatever you want to call them. These have to be factored into the schedule.  There are two ways to do this. One is to create tasks for the problems, the other is to treat problems differently from tasks.  The latter is the better practice, even in an agile world.  

Problems are different animals than feature tasks.  They require different processes.  A feature creates new functionality that must be specified, documented, designed and implemented, perhaps with a change to training courses.  A problem corrects behavior to correspond to existing specifications and documentation.  The main effort in fixing a problem is usually in reproducing it, and the problem report should already identify how that is done.  Often the first response is to develop a workaround, which effectively reduces the priority of the problem.  A problem could take a few minutes to fix, or a few days.  Problems are used to measure product quality.  Problems don't look good in a product, much worse than the lack of a feature.  They're different.

A next generation ALM tool will support separate tracking of problems and tasks/activities.  Scheduling of problems may be similar to or different from feature tasks.  A typical agile strategy might suggest that emergency problems pre-empt any current work, high priority problems be scheduled into the current or next iteration, and other problems fixed at the discretion