Based on my experience analyzing requirements in user stories, I’m convinced that a fundamental challenge for the agile business analyst or product owner is to maintain and communicate the “big picture” while also detailing out requirements in very small, discrete pieces.
It’s so easy to get into a rhythm of looking at one story after another, eliciting the requirements, defining the stories, and prepping them for implementation. After a few weeks of this, you can lose track of where you are at in the context of the project as a whole and it can become increasingly difficult to groom the product backlog.
On one particular release I worked on, there were 4 main pieces of functionality and about 60+ product backlog items that collectively delivered 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 faced was how to expose these inter-relationships in a coherent way to support my own analysis and get meaningful sign-off on the product requirements. In the past, I have relied on the rigor of more comprehensive use cases with accompanying wireframes 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.
What I ended up doing was creating a feature map, with each user story laid out in a hierarchy and used color-coding to show which stories were implemented and which were not. This helped us see that we’d been cherry-picking important stories across different big features, but hadn’t really finished a single big feature on the project.
We re-prioritized our stories, looking at what stories were most important by feature and what minimum number of stories could be used to consider a feature complete. This allowed us to approach a collection of related user stories together and made the requirements process go a lot more smoothly. I felt a lot more like I was writing my beloved use cases.
And it also helped me keep my sanity.
>> Learn More About Agile Requirements
Check out Use Cases and Wireframes – our virtual, instructor supported, professional credit course, where you’ll learn how to iteratively analyze and model functional requirements, and break apart use cases into user stories.
