When using agile software development, how are the software requirements, user stories, and product backlogs linked to maintain traceability, considering the product management, client as the stakeholders, and development team responsible for the deliverable?
Requires Free Membership to View
When you register, you'll receive targeted emails designed to keep you informed of the most relevant information on Agile development, application security, testing & QA, software requirements, and more.
Hannah Smalltree, Editorial Director
|
 |
Anyway, on to your question: I'm a little confused by your inclusion of "requirements" in your list of agile artifacts because, in essence, all the other stuff you listed are the software requirements. So, it's not a situation where you have requirements and all that other stuff. You just have all that other stuff (for the most part). Occasionally, you might have a need to attach a detailed document to a user story, but that is the exception, not the rule. Getting rid of detailed requirements documents and the confusion, overhead, and hand-offs that go with them is one of the points of using user stories.
Traceability from the work backlog to user stories is usually pretty easy to do. A work backlog is a list of features/capabilities that will be built, and user stories are almost always tied to one of the items in the backlog. Generally speaking, you shouldn't write user stories that don't tie back to an item in the backlog. The main exception might be if you decide to use user stories to track things such as performance testing.
It's also important to understand that user acceptance tests are an important part of user stories. Every story should have an appropriate number of acceptance tests. This captures not only some of the details left out of the story, but also details of how to verify the feature is developed correctly. Since these acceptance tests are part of the user story, it's pretty easy to trace in both directions -- from the product backlog to the acceptance tests and from the acceptance tests to the backlog.
There's one last point I'd like to make. One of the most important agile values is "Working software over comprehensive documentation". The user-story approach is based on this value -- it's not trying to deliver a perfectly documented software project. If you find the user story approach too "loosey goosey" for your tastes, I suggest you spend some time thinking about this value and how it plays out in your practices.
For more information about user stories, I recommend the book "User Stories Applied: For Agile Development" by Mike Cohn and Kent Beck.
This was first published in November 2008