In his CM: the Next Generation series, Joe Farah gives us a glimpse into the trends that CM experts will need to tackle and master based upon industry trends and future technology challenges.
Rapid Customer Feedback
One of the key reasons for requirements change is that in an agile world, there is plenty of customer feedback along the way. As the customer views the product's evolution, perhaps at the end of 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 (i.e., current release, future release, next iteration, etc.)
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. The idea is the same. The tasks are the allocated requirements with 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 change), 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"). 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.
Eventually we get a set of activities or tasks and we start prioritizing them. This is done, first, by allocating them to a particular target release (release 1, release 2, etc.), and then by prioritizing them within each release. If we don't start out with a full set of requirements, we won't then 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. We can also 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 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.