How would this team go about implementing this story? In my experience the system would be designed in layers with integration occuring after each team completed the work on their tier. Then there is the question of, what do we do about the "old system"? Some feel that disabling or perhaps integrating the antiquated system with the new feature in the "old system" should be part of the "definition of done" while others believe that it should be treated as a separate user story. Scott Ambler wrote an article on the subject where he describes the problem with creating user stories that focus on these "so-called" non-functional requirements:
All interesting requirements, but each one on their own provides very little value until you put them in the greater context of sending out marketing literature to a targeted group of customers. Until all of those user stories, and more, are implemented your system really doesn't provide true business value to your stakeholders, regardless of the fact that you have been producing potentially shippable software every iteration up to that point.Now if you have not read my original rant on "technical" user stories, then I should probably let you know that I believe it is a bad idea. The simplest approach IMO is to pair down user stories into the smallest vertical slices possible and incrementally add support for more general features. Using my example above, we could reduce this story to a specific type of crime. Another way to reduce the scope from an entire city to a neighborhood. Do whatever it takes to make it small enough to get "production releasable software" in one iteration. Its not that hard.
Totally agree. Here is what I wrote previously on this subject:
Post a Comment