The Next Generation: ALM Tools for an Agile World

each iteration, feedback is provided identifying, for example, potential issues with the user interface, potential improvements based on demonstrated product capabilities, and clarifications to requirements once thought to be unambiguous.

The ALM tool must be able to track this customer feedback. Ideally, the customer has the capability to enter requests along the way (maybe from a smartphone or tablet interface).  When the "customer" is really multiple customers, or even an industry, the ALM tool must be able to track each customer's input and must be able to identify for each customer the status of each request.  Some requests may be at odds with other customer requests.  Some may be duplicated.  Some may be ambiguous.  The ALM tool helps to capture initial requests and move it along the work flow so that an unambiguous requirement results that can be added to the appropriate part of the development team's task backlog (e.g. current release, future release, next iteration, etc.)

3. Release and Iteration Backlogs
The customer requirements are turned into tasks or activities in an agile world.  This is a bit different from developing a new set of allocated requirements for the next phase of development, as is done in a traditional project.  But the idea is the same.  The "tasks" are the "allocated requirements" - no need to track project management activities and "internal" (vs. customer) requirements as two sets of objects (i.e. one for a Requirements Management tool and another for Project Management).  In an agile world, these really become one and the same.  In fact, in a traditional project, I would argue that there should not be separate "internal" requirements and "project management" repositories.  This is duplication of effort and results in lower quality.

What's really important is that we know what the customer has told us (customer requirements, which continually are changing), and what our tasks are to accomplish those requirements.  We also need the traceability from the tasks back to the customer requirements, and ultimately from the test cases and test results back to the customer requirements.  This is where a Next Generation ALM tool can help make this traceability automatic.  For example, you create a new task, not by clicking on a "New Task" button, but instead, by right-clicking a requirement and selecting "Add Requirement Task"  (or "Add Activity" or "Add Internal Requirement Task" or whatever).  The traceability is then automatically associated between the two items.  Similarly, as updates (i.e. change packages) are created from the tasks, a similar set of actions help to ensure that the traceability extends down through the process.

So we eventually get a set of Activities or Tasks and we start prioritizing them - first by allocating them to a particular target release (release 1, release 2, etc.), and then by prioritizing them within each release.  Now if we don't start out with a full set of requirements, we won't have a complete activity/task list.  But we will have the beginnings of a product backlog, which will grow over time in an agile world.  And we can trace this backlog back to the requirements that have been addressed.

We will also need to track versions of requirements, or more accurately, changes to requirements.  Our traceability needs to be at the level of requirement revision, so that if a requirement changes, we can identify impact and create additional tasks, traced back to the later revision.

As we look at the tasks for each release, that is, at each release backlog, even though incomplete, we can begin to identify which tasks will be addressed first.  The ALM tool allows us both to prioritize