Better Practice for Managing Agile Stories

I recently came across a project working Agile with Rational Team Concert (RTC). This is great, they have all the tracking tools they need to monitor project velocity, and to manage which stories will go into which sprint. Job done. Short blog entry here…

Oh, just one thing. Who is ever in a project that couldn’t be working just a little better. Best practice, whatever that may mean, is too often an unachievable leap away for many reasons. Better practice is very often within  the grasp of the project.

Agile stories were well documented, some better than others, but in general they fairly good, clear, understandable. The only problem is that they are in the description field of an RTC work item. This means that requirements cannot be referenced individually, and finding a single requirement can be a challenge. RTC, after all, is not a requirements management tool. I have proposed a step forward, towards best practice. Mid way through a project is not the time to leap to a different tool solution, but better practice can be achieved with little disruption. This step is one to a state of better practice. It is also a viable option for a new project starting out. Best practice, state of the art, is not what is required on all projects, and for many Agile IT projects, the rigor demanded of large defence project best practice is not only unnecessary, it can be positively harmful.

There is value to be gained from moving towards DOORS Next Generation (DNG), with a lightweight approach, the value gained should far outweigh the investment. Value comes in the forms of searchability, traceability and analysability.

My proposal is as follows:

1. For each Story in RTC, create an artifact in DNG of type story, and link this back to the RTC work item with a ‘Tracked by’ link.
2. Create a module for each story in DNG and link the Module artifact to the story artifact with a ‘Expanded in’ link.
3. Document the story in the DNG module, including user requirements, system requirements and any other information as relevant. This is the same content as was previously in the RTC story description. Care should be taken here to make each sentence or requirement a separate artifact, and so set the artifact types for the user requirements and system requirements properly.
4. Make links between system requirements and user requirements, within the module and, if relevant, to other modules (stories).
5. If use is made of Business Goals, then create these in a separate business goals module, and reuse these in the story module.

Moving data for a few hundred existing stories will probably not add value, so only move stories as you ‘touch’ them, or create new ones. Each story should take in the order of five to ten minutes to transfer once you are familiar with the process.

1. Grab the content and paste into Word.
2. Set paragraph breaks and line breaks as needed.
3. Format by converting tables to text, setting headings and normal paragraph styles.
4. Import artifacts into a new module from document.
5. Create story artifact, link to RTC work item and to new module.
6. Set artifact types appropriately and create links from system requirements to user requirements.

There is potential value in creating all the story artifacts and creating the links to RTC. Each artifact contains the title of the story, and with some care in RTC you can extract this list into a document or spreadsheet for importing into DNG.

Another task that could easily repay its investment is that of creating glossary terms. Use DNG glossary terms for things that need to be consistently named. One example of this for an IT application is the screen or tab names, and the data entry fields. By using glossary terms for these, they have a quickly findable definition that is clear to all.

Finally, linking the requirements from DNG to Rational Quality Manager (RQM) gives improved traceability when investigating the consequences of a test failure and allows you to see the latest test result (Pass or Fail) directly against the relevant requirements.

Some benefits of moving to DNG:

• Discussions. With requirements in DNG it is easy to conduct discussions about individual requirements, rather than have them associated with the whole story.
• Reviews. Reviewing requirements using DNG reviews allows the team to review, discuss and update and then see the resulting requirements without the clutter of review comments.
• Attributes. Having individual requirement artifacts allows the team to set attributes for the requirements, priority, owner, or any other user defined attribute. This is going to be less heavily used on an Agile project where a whole story is implemented in one iteration than on a traditional V-model project.
• Inclusion of pictures and similar objects inline with the requirements. Screen mockups, graphs, truth tables and other items that would be attachments in RTC, can be included inline with the requirements, so there is no need to download and view them separately.
• Sketching. DNG has an inbuilt sketching tool that would serve adequately well for many screen layout purposes among other things. This would allow the team to review and make changes to the proposed layout without having to create a series of image files showing the desired layout.
• Splitting stories. Where a story is larger than it needs to be, moving some content to a new story can be achieved by creating the new story artifact and module and then moving the relevant requirement artifacts from one story module to another. If desired, the record of this can be made clear by the use of attributes. The same applies to merging stories.
• Analysis. Looking at the effect of a change becomes easier once the data is in a requirements management tool. Even adding course traceability between stories at the level of the story artifacts will make life easier when it comes to managing the effects of changes after the move to production. If this is likely to be a troubled, or changing, deployment, then finer grained traceability will add better value.

Greater rigor takes more investment of time, and for many Agile, IT, projects, this does not pay back. The decision must be made about how much effort to invest in creating the clarity and traceability in the data, and that is based on the likely need to perform analysis at later project phases. This trade off applies in all projects, the answers will look very different for different project types.