Requirements Management in an Agile World – Yes it does make sense!

The main benefit of today’s Agile development methodologies such as Scrum or XP is the promise of delivering working software in a shorter period of time and the value derived from having the flexibility to adjust which features need to be implemented for the next iteration or release. But does this type of approach allow for requirements management? Or a better question is do we need to manage both requirements and backlog items such as user stories? Or are requirements and user stories analogous? Well — does the need to deliver what the requirement originally requested go away? Does the desire to control change to the requirement go away? Of course not, and neither does the need for requirements management under these newer methodologies. The nature of RM will change, certainly, but the fundamental principles will not.

In working with enterprise customers across various industries such as aerospace, embedded engineering (high-tech electronics companies) and financial institutions, I find myself wondering whether the term requirements management really means what people think it means. The term ‘requirements management’ is being used to describe a whole slew of different processes, tools, capabilities that have absolutely nothing to do with managing requirements – which is probably the contributing factor to some believing that RM has no place in an Agile world.

Within an Agile environment, let’s take Scrum as an example, you need the ability to define an overall product backlog which houses all outstanding feature requests the Scrum teams will eventually work on. For some organizations, call it a backlog item, user story, or feature request, this is the same artifact that the development team will see and break down into tasks during their sprint/iteration planning meeting. The job of a Product Owner would be to constantly sift through that pool of artifacts to identify candidates for the next release. However, some organizations that are now transitioning into an Agile development methodology typically are coming from a traditional methodology where they had ‘formal’ requirements management. By ‘formal’ I mean the requirements documents needed sign-off either from the key stakeholders in the company or their end customer. Let’s take the example of a cell phone manufacturer who gets most of their requirements from their carriers. These requirements typically come in a Word document format containing hundreds of requirements. Requirements management doesn’t go away in this scenario – it is just as important to ensure that the requirement is met, tested, and controlled in terms of change over the shorter development periods that these methodologies represent. What I have noticed is these requirements are sometimes very high-level and there is a need to decompose these into either Epic or User Stories to be placed in the Product Backlog. A RM solution can bring forth the visibility necessary to ensure that requirements are satisfied appropriately, reflect the current needs of the business and are communicated to end customer and key stakeholders.

What the Agile methodologies are also doing is that they are forcing requirements to be decomposed much earlier in the lifecycle such that their scope can be understood and mapped to an Epic or User Story in the backlog to be prioritized. We find ourselves moving away from a system of Business Requirements documents tracing to Technical Requirements documents tracing to System Requirements documents to one where the Business, Technical and System requirements for a given feature or request are fully defined and become the new Requirements Document. Once we have the Requirements Document, the Product Owners can decompose these into more granular User Stories so development can start building the end product. Pure Scrum does not talk about formal Requirements document because it is “too heavy weight”. However, there are companies out there that need to communicate progress in term of the requirements originally received and not in terms of backlog items such as user stories. The reason being the same document that came in needs to be sent back showing the status of each requirement. This holds true in the automotive industry as well where the OEM (automotive company) and parts suppliers need to communicate using the standard Requirements Interchange Format(RIF).

Under this environment the Development and Test (QA) teams have greater visibility into the entire request, from the business level through to the system level, and can make design and test decisions armed with that knowledge. Furthermore, requirements traceability becomes about how these requests and the User Stories themselves relate to each other rather than how the high level requirements are decomposed into lower level requirements.

All that said, the requirements within these documents still need to be managed – scope and change to them needs to be controlled and more importantly communicated – and they still need to be linked to the rest of the application development lifecycle – the designs, the test cases and the source code. So in a nutshell, we are talking about Lean development. See Brad Appleton’s article exploring the need for traceability and transparency in Agile development in his article – “Lean Traceability” CM Journal, September 2007 (Vol. 6 No. 9) (see

Remember, software methodologies need to be applied in a way that matches the strategy of your business. Whether Waterfall, Iterative, Agile or some combination of all of them, you still need to define what your customer wants, even when they change their minds (and they will!). — You need to know what you are building and how to adapt to those changes. In the end, you need to be able to match the deliverable back to what the customer originally asked for, and this requires a repository and change management for requirements, with traceability over the requirements throughout the lifecycle – sounds like RM to me.

Please feel free to comment on what your thoughts are on RM in an Agile World.