CM: THE NEXT GENERATION of Agile CM

to capture them.  When we take the initial concept documents and user stories, and then add in the feature tasks, we have something that is very close to a requirements specification.  We only need to make sure that the feature tasks are clear and concise, and then we need to identify re-works - how a feature as originally planned, has evolved differently.

Features can usually be easily gleaned from task specifications, often referred to as activities.  Re-work is not as obvious.  However, it again comes down to capturing the interaction at the end of each iteration.  "We're going to move this from a pull-down to a pop-up menu because the customer finds it more handy there."  Can we capture this as an issue, problem report, request or otherwise?  The problem was expressed, and the resulting task defined.  The real work is in capturing this statement, and then converting it into a problem report, or request, with a task defined which addresses it.  How is this best done?

Generally, when reviewing progress at the end of an iteration, a series of requests are identified.  Often solutions are suggested at the same time.  It's a mistake to capture a suggested solution and turn it directly into an activity.  There may be dozens of requests and we need to identify them, sit down and brainstorm on the solutions.  In that way, we come up with a more consistent set of activities, better architecture and more team involvement.  Capture the requests first and prioritize them.  Review them and sort them into features (changes requiring new activities) and problems (changes to fall in line with existing activities).  Create new activities and problem reports as necessary, and prioritize them.  These are added to the existing product backlog.  If a problem request is identified for a recently completed activity, it may even suffice to re-open that activity.

This sounds like it could be a lot of work - administration, forms, etc.  Well, if it is, you're not using an Agile CM tool.  To capture requests, you should be able to sit down with the customer and simply type in the request (maybe a title, some notes, and a priority) and hit an Add button, and then be ready to capture the next request.  You might categorize them as problem or feature as you go, or use a single click to do so later.  You should be able to right-click on each request and either generate a problem report, generate a (feature) activity, or relate it to and re-open an existing problem report or feature.  Traceability should be automated so that the problem/feature activity is tied to the original request.  If you have input from multiple customers, the request might be tied to an existing problem/feature if it already has been identified.  If your CM/ALM tool can't make this process more efficient than having to use a spreadsheet, turf your tool.  Don't use a spreadsheet.

Note the difference between requests (customer domain) and problems/feature activities (development domain).  You are sure to get customer requests that require no software changes, the same or similar requests from multiple customers and requests that are not in the business plan.  Don't muddle up your development domain by trying to keep all of these in one object class.  Customers don't always know if it's a feature or a problem.  Customers don't want to see the design details (generally).  Each customer wants to be sure that you're tracking each of their requests. The development team just wants its marching orders. It doesn't have to be difficult to do, just Agile, with a good tool