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.

So, how then does one manage Agile project Requirements in the long term?

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.

(The following is a bit of an aside, so feel free to skip it)

What I have considered doing:

Recently I've been tempted to start using a dedicated Requirements Management System (RMS). This system would be responsible for keeping track of Features, Acceptance Criteria, Non-Functional Requirements, a Dictionary of Domain Terms, and potentially other things.

The work item system/bug tacking system would link to the RMS instead of holding definitions of the requirements. So, instead of defining Acceptance Criteria in a User Story, the Story would simply reference existing AC in the RMS.

The lifecycle of Features and Acceptance Criteria would be managed in the RMS. If an AC is superseded it can be replaced with one or more AC and the RMS would store these relationships.

This would make it easy to quickly identify which Work Items relate to expired Features and then navigate to the up-to-date requirements.

Additionally, if coded tests are then linked to either AC or Features, it would be possible to immediately flag tests as inconclusive if their related requirement items have changed. This would help manage large sets of Unit and Integration tests, ensuring that only relevant and useful tests are maintained.

I haven't put too much thought in this approach yet so I'm sure it has flaws, but I'm very interested in which approaches other people have used to solve this problem.

So, to reiterate:

How does one manage Agile project Requirements in the long term?

Related posts

Recent Viewed