Managing requirements and project planning via a shared concept of user stories is the crux of agile software development. However, what actually goes into the user story depends heavily on the context of your team.
In this article, we’ll look at the situation I found myself in as an agile business analyst found itself in and how I decided to compile user stories for the project.
User Stories for a Geographically Dispersed Team
One challenge this team worked through was that they were what I’d call lightly geographically dispersed. The “business” side is about a 5-mile drive from the the “technology” side. While they were able to meet in-person for sprint planning meetings and other key discussions, a lot of communication happened over the phone and through email or other types of documentation.
This meant that the user stories needed to be more detailed descriptions of the functional requirements, since the developer could not easily clarify requirements in real-time. The content for each story, which was stored in Team Foundation System, may have fit on a single page, but would have rarely fit on an index card.
User Stories for Detail-Oriented Business Stakeholders
The business stakeholders that were part of this team historically documented very detailed requirements and maintains a repository of use cases and supplemental specifications that had been kept fanatically up-to-date since the system was launched 7 years prior. Moreover, many of the requirements required complex business rules to be analyzed, decided upon, and documented. All of this information made it into the user story or the supporting acceptance tests.
As a result, the user stories were fairly detailed and contained a lot of information. They were less “reminders to have a conversation” than “reminders of what we decided and why.” The user stories contained details about every field on the page, every exception, and notes about how the business might see this page extending in future iterations.
User Stories for a Web-Based Software Solution
Each story described the requested functionality for one part of a new customer-facing website. Early on, the business analyst used skeleton use cases to flesh out the end-to-end functionality – these were used as an analysis tool, not as a form of requirements documentation. The user stories were coupled with a set of click-through wireframes that represented the overall flow of the application. The wireframes are used to confirm requirements across a broad set of business stakeholders and evolved significantly over the course of the development process.
Within the user story, the business analyst would refer to specific user interface screens from the wireframe set or attach a detailed user interface specification to identify fields, business rules, and display rules.
User Stories Keep Development In Sync with Requirements
Overall, this method of capturing user stories worked. The software development team had clear requirements to build from, the tester had clear acceptance tests to verify against, and the organization supported many other aspects of the agile methodology, such as sprint planning.
A positive takeaway the team had from this agile experience was that a very small development team with minimal capacity deliver something that works and fulfills on requirements, consistently and week after week. The team gained momentum each week as they checked more and more user stories off the list, even as new stories were discovered and added. The team was able to focus on delivery, even in the middle of a significantly sized project that could have been easily overwhelming.
Like reading about agile experiences? Then you might also like my post on our product backlog.
>> 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.