Agile Development Blog

In our Agile Tooling for High Assurance Software Development series we’ve looked at a prescribed user story structure for requirements traceability and we dove into how tooling is important to maintain relationships needed for traceability to other artifacts in the system (defects, test cases, etc.). Given this, how do we automate a traceability matrix from Rally?

First let’s review the why. Why do we spend so much time and energy creating traceability matrices?

There are a number of sources that I could cite but I’ll go back to the Design Control Guidance for Medical Device Manufacturers, where section F Design Verification states:

DOCUMENTATION OF VERIFICATION ACTIVITIES. Some verification methods result in a document by their nature…

Another self-documenting verification method is the traceability matrix. This method is particularly useful when the design input and output are both documents; it also has great utility in software development. In the most common form of the traceability matrix, the input requirements are enumerated in a table, and references are provided to each section in the output documents (or software modules) which address or satisfy each input requirement. The matrix can also be constructed “backwards,” listing each feature in the design output and tracing which input requirement bears on that feature. This reverse approach is especially useful for detecting hidden assumptions. Hidden assumptions are dangerous because they often lead to overdesign, adding unnecessary cost and complexity to the design. In other cases, hidden assumptions turn out to be undocumented design input requirements which, once exposed, can be properly tracked and verified.

Although this is only a guidance, it is pretty clear that the FDA is encouraging the building of traceability matrices, that might be “why” we all create them. In order to automate the creation of this matrix Rally has offered two Rally Catalog apps in the product, the Iteration Traceability App and the Release Traceability App. The screenshot below shows an example of the Iteration Traceability App that displays Stories with their associated Tasks, Test Cases, and Defects for an Iteration.

In the spirit of the work that Dean Leffingwell and I have been doing I persuaded one of Rally’s awesome App Developers, Charles Ferentchak, to help me build an additional trace matrix app based on an example shared by a customer. This app is not bound to an Iteration but instead allows the creator to select from their list of tagged PRD’s and creates a trace report showing all of the features associated to the PRD along with test cases, results, design outputs, and etc.

Both of these traceability matrices are examples of possible automation that can be easily achieved by adding tooling to your Agile practice.

To submit your own idea for a Traceability Matrix to Rally’s Product Team visit Rally Ideas for Regulated Industries and the next time you are on LinkedIn be sure to join the Agile in Regulated Environments LinkedIn Group.

And, as always, I encourage your comments on this post or email craig@rallydev.com.

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.

Establishing an upfront, common understanding of “done” that suits the unique dynamics of each development project can be one of the most critical activities for Agile teams. With a consistent meaning of done, agreed to by the whole team, velocity or throughput becomes more stable – allowing your team to make and meet commitments, establish priorities and plan iterations.

We recently hosted a webinar entitled “Defining Done: Creating Velocity without Debt,” to discuss how a common definition of done lays the foundation for focusing on business value while avoiding technical debt. Although we enlisted Rally’s expert coaches to answer the hundreds of questions that pored in from over 2,200 people around the world who joined in, we wanted to spend some more time providing in-depth answers to a few of the questions we received. Below is a video with answers to some of the tough questions about the definition of done:

I also put together a presentation that goes into more depth about what your team can learn from burndown charts.

We hope these resources help you come up with a definition of done that suits your unique team and project. Have more questions? Feel free to post them in the comments section below – we’re always thrilled to continue these discussions with the Agile community.

Zach Nies is a CTO at Rally Software and a proud member of the Boulder/Denver Agile community for the last ten years.

Are you challenged with trying to map Agile Software Requirements to a traditional requirements model for the documentation required during internal or external audits?

If you answered “yes”, you are not unlike many of Rally’s highly regulated customers who want to reap the benefits of Agile but struggle to find good tools for creating and managing system documentation. For the next two posts in our Agile Tooling for High Assurance Software series, I will provide an overview of the material that I presented to a small sampling of customers in early May at our inaugural RallyON conference in Boulder. This work is a continuation of the project that Dean Leffingwell and I have been working on over the past year.

Let’s start by reviewing Dean’s post, Agile Software Requirements in High Assurance Development, which provides us with a traceability model as well as a medical device example to follow. From there I’ll demonstrate how Rally can be used to support traceability from what we traditionally think of as a PRD, a document detailing the system’s intent, to user stories that are commonly used to implement the features of the system.

An important part of the verification effort is to assure that every feature traces to one or more user stories (or other forms of software requirements expression) as is illustrated below. But first we need to begin with a PRD that defines the overall behavior and intent of the system. This will serve as design input in FDA terms. The PRD is going to be decomposed into individual features that will be implemented by many Software Systems Requirements, which we’ll also refer to as User Stories. Take a moment to review the illustration.

With regard to managing these requirements, many of us have encountered or even created spreadsheets with thousands of rows of requirements and tens of columns of attributes that described the system we intend on building.

As part of the introduction to Agile practices we will trade-in the spreadsheet for an Agile Lifecycle Management (ALM) tool that will provide us with better traceability to the real system being implemented. An ALM tool, like Rally, allows us to create a high level user story that will represent system intent and maintain those items that we said were important to document such as a PRD. In Rally the system, intent, features, and user stories will all be tightly coupled by creating a family of user stories through parent/child relationships.

The screenshot below shows the EPAT example that Dean Leffingwell described in his post, extrapolated in Rally. Notice that our EPAT Device Enhancement has been broken down in a way that will allow us to trace each child user story back to the PRD (represented by a parent user story). Another convention being used in this example is that of tagging. Rally users often tag stories to represent requirement types like PRD, SRS, functional, or non-functional stories for better reporting on specific story groups.

Being prescriptive and consistent when structuring our Agile Software Requirements (User Stories) in Rally provides us with the unique capability to create our own custom document exports, such as the Product Requirement Document that I will highlight in a post next week.

In summary, Rally helps us to transform individual user stories that each implement a small increment of value into a aggregation of stories that represents the intended product.

To learn more about Rally’s User Story Hierarchy watch this informational video.

To submit your own ideas to Rally’s Product Team see Rally Ideas for Regulated Industries and the next time you are on LinkedIn be sure to join the Agile in Regulated Environments LinkedIn Group.

And, as always, I encourage your comments on this post or email craig@rallydev.com.

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.