4 fixing a typo
source | link

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?

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 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?

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?

3 Trying to clarify that by "long term" I mean years.
source | link

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? Now, imagine a 2 year gap between development iterations 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?

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.

So, to reiterate:

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

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 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?

2 Getting rid of my aside.
source | link

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?

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?

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.

So, to reiterate:

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

    Tweeted twitter.com/#!/StackProgrammer/status/496279102555713536
1
source | link