Requirements Management in the short term for Agile projects seems like a solved problem to me.
From the Scrum angle new requirements or changes to existing requirements are delivered through User Stories. And User Stories grouped under an Epic or Feature facilitate the delivery of larger more complex requirements.
Of course, a User Story isn't technically a requirements document. It is a manageable grouping of work which maps to what is often called a Vertical Slice of functionality. And the scope of these stories can be defined unambiguously through the use of Acceptance Criteria (AC).
So, although User Stories aren't formal requirements, browsing through them can give you a pretty clear idea of their underlying requirements. In the short term.
I say in the short term because, as a project progresses, the number of User Stories increases. Thus, browsing through an ever increasing list of Stories to find a Requirement becomes less and less efficient over time.
This problem is compounded when you consider User Stories that expand on, supersede, or even negate previous Stories.
Now, imagine a 2 year gap between development iterations on a project (stable in production). The original team is gone and so is all their knowledge.
If the original team knew this was going to happen (eg, it's the nature of the business), then what measures could they take to help subsequent teams?
Sure, the backlog will provide some information, but it's hardly in an easily browsable form.
So, what can be done to help subsequent teams understand the state of the project, including why and how it got there?
In my experience, the following things don't work:
- Backlog grooming to delete or update previous User Stories so that the Backlog can be read as a requirements document.
- Documentation Sprints where team members are tasked with documenting the current state of the system.
- Documentation through Behaviour Tests. This approach is the only one I have seen come close to working. Unfortunately, Coded Behaviour tests are victims the Naming Problem. Although the tests might properly document the system, getting a fluctuating team of developers to write their tests following the same Domain terminology, wording, and style is almost impossible.
So, to reiterate:
How does one manage Agile project Requirements in the long term?