How useful is a Requirement Traceability matrix with US in a hybrid agile ecosystem

Recently I have too often been asked the question how do we do requirement traceability during Agile development. More often these questions arise in large transformation service delivery projects, especially those that originate from a RFP/RFI kind of process. These have requirements specified upfront for which the vendor provided a compliance matrix for and agreed what is part of the commercial off the shelf solution (COTS) and what parts will be implemented on top of the COTS. These requirements are not really “Agile structures”. If these are Agile structures in your case, then rest of the blog is not for you.

So even though the requirements are non Agile structures, development still prefers the agile mode since they would still like to get the other benefits that the Agile mode offers like integrative and incremental development, early feedback, scrum team dynamics and others. So during the development, teams convert these not so Agile structures into Agile structures like features or user stories. This leads to an interesting situation where the development is looking at scope in one way whereas the larger program might continue to look at scope still in the original requirements style.

Now one would argue that once we start development/execution, we could just do a baseline with the “Agile structures” and then don’t need to revisit the “non Agile Structures”. This is more complex than it sounds as a lot other stakeholders and processes prefer those non Agile structures e.g contracts or change control boards for example and of course the many people (and influential) who have just got used to a particular way of working. Now if all the ecosystem would be really Agile, then we won’t have these challenges but the fact remains what do you do when its not. You still want to get the benefits of Agile development yet you need to live and operate in this non Agile ecosystem.

A lot of Agile tools are recently offering ways and means to link the user stories to the requirements. This essentially means that that product backlog is essentially a list of requirements now in a different format. So instead of focusing on execution, development teams need to spend an awful lot of time doing this linkage. Most of the time this relationship is not straightforward or one to one or even one to many. Its many to many. And to extract a meaningful output from this is not trivial. But as humans we love data and its good to have. But is good to have good enough ? Is this effort justified? and is it worth ? Yes having this information might help, but what is the TCO on it?

My take is that going with the fundamentals of Agile about what a US is will help, especially in such a skewed partially Agile scenario. User stories are not requirements. User stories are about a conversation between the product owners and the scrum team. So let them be just that.The product owners are the bridge between the stakeholders and the development. Let the requirements guide the product owners to build the user stories that they discuss with teams and guide their development efforts.

To see that all the committed scope is being developed and working as expected, I would rely more on the testing to provide those views. The acceptance tests need to be a reflection of the requirements and are a better mirror of the real status of the scope traceability as well as development progress. Forcing this on the development at US level in terms of traceability matrices does not in anyway change the need to do it at the acceptance level. So why have the redundant layer in first place. We can keep things simpler. Simple is always good.

I would like to hear from others who have experienced similar dilemmas – especially in a large complex services based projects, not product development.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top
Scroll to Top