Over the past few weeks, I’ve had an interesting experience getting into a bi-weekly rhythm of requirements elicitation, definition, and reviews. Based on this experience, I’m convinced that a fundamental challenge for the agile product owner or business analyst is to maintain and communicate the “big picture” while also detailing out requirements in very small, discrete pieces.
The release I’m working on has 4 main pieces of functionality and about 60+ product backlog items that collectively will deliver on that functionality. Although most backlog items are relatively independent from the perspective of implementation they are inter-related in terms of how they fit together to achieve our defined business objective. Moreover, much of this new application will be interfacing with a legacy system and database and exposing data from that system live to customers on the web for the first time. The small minutia of what’s in a database field or what the status of a record is in a given state can have significant business implications and impact how decisions are made in the minutia of detailing out other stories.
The challenge I have been facing is how to expose these inter-relationships in a coherent way to support my own analysis and informed decision-making about product requirements. In my past, I have relied on the rigor of more comprehensive use cases to “hold it all together” so to speak. Oftentimes 2 or 3 use cases might be inter-related to deliver a complex feature, but now I’m often faced with 10+ stories, which is a mite beyond that infamous “rule of seven” that the brain can hold at any given time. I sense the need of a diagram or model that places the user stories in context with one another, complete with an articulation of what data is pulled from and pushed to the database when (we’ve already got a domain model, so this should extend up that). And therein lies my Monday morning task…if I intend to keep my sanity for the coming week.
As always, suggestions and comments welcome. And, of course, check back for details on what will hopefully become a successful endeavor.
Related posts:




.jpg)
{ 2 comments… read them below or add one }
Hi Laura,
Glad I found your site on blog roll link from Jonathan Babcock.
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.
Hi Chris,
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