The role of user stories in agile software development |
 |
EXPERT RESPONSE FROM: David Christiansen
|
|
|
|
| > |
QUESTION POSED ON: 18 November 2008
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?
|
|
| > |
Let me first say I believe the value of traceability in determining coverage or application quality is widely overstated. It's only one facet of a difficult problem, figuring out how much testing needs to be done to make sure an application is good enough. I'm also not very interested in traceability as a tool for facilitating the "blame game" after a failed effort. I've seen too many people use it as a way of avoiding fixing problems by making the argument that a defect is a "missed requirement," not a real defect. I hate that game and don't like to see it played.
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.
|
|
|
|
|
|
|
|
Search and Browse the Expert Answer Center
Search and browse more than 25,000 question and
answer pairs from more than 250 TechTarget industry experts.
|
|
|
|
|
|
|
|
|
|
|
|
