In the book “Balancing Agility and Discipline: A Guide for the Perplexed”, by Barry Boehm and Richard Turner, there is a story about a lease management system with over 1,000 story cards. The authors explain that it well beyond the ability of people to understand and deal with all of the possible interactions among that many stories and objects in their heads. Talking about lessons learned, the say that in similar complex projects in the future, they would “insist upon [...] constant updating of a more traditional picture or graphic of the overall application as part of the tasks in each iteration. The aim of
such an artifact would be to provide guidance for the writing of story cards and
their connected functional tests when the elements of the application under
development become very complex and interconnected. [...] Such an integrated picture would provide what a high stack of story cards cannot, namely, a guide for insuring that
every new story card can be written and tested completely in its relationships to
all other stories. “

Thanks for checking out my blog! Jonathan has a great site.

I think you make a great point to approach this just like any other requirements project. The user stories don’t actually add complexity. I think the challenge I’m facing is in really making decisions faster about smaller pieces of functionality without always having the time to step back and look at the whole. I need to keep both tasks on my radar.

I’m working on a set of work-flow diagrams now and it’s really helping pull everything together.

Laura

Not sure if I am exactly addressing your situation but I find that workflow models using swim lanes work the best for me when dealing with multiple streams of functionality, across various business departments and utilizing multiple integrated systems. Especially for a new application integrated with a legacy system. The activity steps on the workflow diagram are detailed using separate use cases if that applies or simple activity dictionaries if just for system to system interaction with no direct user defined function.

This book has been my best reference…
Workflow Modeling – Tools for Process Improvement and Application Development
By Sharp-McDermott

I amended the method though by including the “systems” in a middle swim lane. Effective for illustrating system to system integration steps or such things as web service calls in the diagram. Usually my workflow diagrams are multiple pages depending on the number of business domains involved. Not good for presenting to senior stakeholders but good for developers and some customers.