Does your current tooling environment provide traceability paths for User Story Verification within an Agile Iteration? My last two posts in this series described how Agile tools, like Rally and Quality Center, are used to achieve this very objective. In this post I will bring the User Story Verification conversation to a close by elaborating on the last two points of Dean Leffingwell’s proposed Traceability Paths for High Assurance Software Development.  The final two points are:

  • User story to code – path to the SCM record that illustrates when and where the code was changed to achieve the story
  • User story to code-level unit test (the “white box” test which assures that the new code works to its internal specifications, also maintained via path to the SCM change set)

Dean provides us with a nice illustration of the Traceability Paths Model to review before we hop into a tooling example:

When it comes to traceability from story-to-code-that implements-the-story and story-to-code-that-implements-the-unit-tests-for-the-new-story, there are two separate cases to be considered:
1) the code and unit tests are in separate change sets
2) the unit tests and code are included in one change se

Let’s start with User Story to Code!

At the end of a 2 week Iteration we ultimately want to be sure that a User Story works as intended.  An important piece of achieving this level of Verification is to trace the User Story back to it’s

ultimate design, which is the code. Using Rally and Subversion as an example below, I show the level of traceability that is achieved from integrating the two tools. Below you see the details of a Task in Rally, TA75: Validate GUI design. In this example Rally is integrated to Subversion and each check-in presents an opportunity to trace the check-in to the coding Task that created the change.  See the Changeset table associated with TA75 in the image below.

I’m assuming that the code and unit tests are in the same change set. If your quality system calls out separate change sets, then you’ll have two such change sets for each story. However, since the “traceability report” for each situation is an automated compilation of the results of this activity, it shouldn’t drive too much overhead either way.

As the image above shows we can now review all of the changes including the files affected and build information which are now stored in a Rally Changeset object for each implementation Task and therefore the Story. The “Changes column is a link to the file in your SCM system and the “Builds” column links to Hudson. To further this example and show how integrated tools will support a “path to the SCM record that illustrates when and where the code was changed to achieve the story” I will include a custom application written by my friend and peer, Barry Mullan.  Barry provides us this description of his work, “over the course of an iteration a source file may be revised many times; that Iteration Diff Report App that I created helps pull all those revisions together and, in the case of viewvc users, create a link to the diff for all changes. This is useful for conducting code and/or security audits of the code changed for that iteration.”

This is a great example of how integrating tooling solutions can provide a very tight path between the User Story and Code for Verfication.

In sprint validation: validating that the system passes it’s new, automated build tests.

Of course, the inclusion of the new story into the baseline changes the behavior of the system, so it will be necessary to assure that the new system works as intended. For that, we’ll likely use tools such as Hudson or Cruise Control to automate the build verification process, including running the new unit tests against the new system baseline. Since this is largely an automated function, we’ll simply monitor the build health during the course of the iteration to assure that the new build verification tests pass.

For my example I will focus on continuous quality built into a high assurance environment using build Rally and Hudson.  One way that Rally can be integrated to your build environment to surface current status of your latest build is through a Build Status Indicator, which clearly surfaces our daily success/failure of the continuous build(s).  Assuming you are building unit tests into your build environment this will provide you with assurance that you are maintaining the quality of your system as you continue to enhance it.  See the screenshot below for an example of the trending Build Health Chart from Rally.

Also see Rally’s Build Traceability Application and other Rally extensions for automating your Build/SCM Traceability Reporting.Whew!  That completes the Define|Build|Verify within an Iteration. Please leave your feedback and examples for us as a comment on this post.

Looking forward I will be digging into how tools can be used to automate traceability from Features to SRS level user stories. During the next post I will also introduce a new Rally Application intended to help our high assurance customers quickly generate a traceability matrix.

Craig Langenfeld is a Technical Account Manager with Rally Software Development who has been working closely with many Agile Practitioners in the Healthcare Industry to define best practices.

Dean Leffingwell is an entrepreneur, executive, author and consulting methodologist who provides agile transformation consulting services to large software enterprises. Between consulting engagements and keeping up with his Blog Dean managed to publish his latest book, Agile Software Requirements.

Request a Call

Looking for support?

Send Us Your Feedback

Provide us with some information about yourself and we'll be in touch soon. * Required Field