As enterprises embrace Agile development, they need user stories to form the foundation of their Agile requirements process. Dev teams and product owners meet to discuss how users will interact with their solutions. They write stories on index cards or sticky notes, and they arrange them on walls or tables to facilitate planning and discussion.
The point of these user stories is to provide just enough information so developers can estimate the level of effort needed to implement the functionality described by the story. When written well, they can be powerful, because they help developers and testers view requirements from a customer’s perspective. They provide context and an understanding of what motivates the people who will use the solutions they deliver.
Difficulties With User Stories
As enterprises work to expand and mature their Agile practices across their projects and teams, they struggle to figure out how user stories fit, because:
- Because stakeholders are unfamiliar with user stories, quality is often compromised. Developers and testers may prefer user stories over a lengthy, text-heavy Business Requirements Document, but user stories are new to most business stakeholders and Business Analysts. As organizations try to transition to Agile, these individuals struggle to write high-quality user stories that accurately and sufficiently describe all customer needs. They get bogged down writing and managing them and lose focus on the bigger picture.
- Complexity causes the number of user stories to mushroom. Most enterprise projects involve the development and enhancement of multiple, integrated systems to deliver functionality for a variety of roles. Users can take many paths that often interconnect and overlap with other processes. This can mean hundreds of user stories for a project of any size. Manually recording and managing the wealth of information that the development team needs is not feasible, and user stories can be missed or misinterpreted in the process.
- Organizations need to pay attention to critical nonfunctional requirements, like those for compliance, security and performance, but this complicates the adoption of user stories because they weren’t designed to represent those types of requirements. User stories scribbled on sticky notes or created in an Excel spreadsheet don’t support the rigor enterprises need for audits, change management, history and traceability.
Large organizations with complex, high-dollar, high-risk projects want to realize Agile’s benefits while managing complexity and risk. They need a robust Agile requirements tool to help them, especially for the creation of reliable, consistent and high-quality user stories.
Helping Teams Define Enterprise-Level Agile Requirements
Price Waterhouse Coopers noted in its paper, Adopting an Agile Methodology, Requirements gathering and delivery:
“As companies shift from small projects and teams engaged in Agile to more complex projects and potentially distributed teams, there is a need to shift from paper and spreadsheets to tools that provide workflow, persistence and traceability.”
Next-generation requirements management tools enable teams to leverage the power of user stories for development while making it easier for business stakeholders and business analysts to create them. It eliminates the need to manually create user stories within the development teams’ Agile tools. It bridges the gap between traditional and Agile requirements, enabling enterprises to scale Agile while managing enterprise concerns.
Such tools helps teams generate enterprise-level user stories with powerful capability sets, enabling them to:
- Collaboratively define customer journeys visually. This enables stakeholders to “tell their stories” as they work with product owners and business analysts to collaboratively define customer journeys. Using the familiar construct of user models—with steps, decision points, actors and condition statements—the entire team collaborates to record and analyze processes in a shared workspace. Teams maintain a focus on strategic objectives when making prioritization decisions and spend less time managing a huge list of user stories manually.
- Automatically generate high-quality user stories and tests from process flows. Product owners and business analysts use customer journeys to automatically generate user stories and acceptance criteria with the click of a button. They push these artifacts into the development teams’ Agile management tool of choice, where developers and testers also have access to related requirements information, like regulatory information, visual models, and constraints supporting a comprehensive understanding. User stories are reliable and consistent, and there is no longer a need to spend time and money to teach business stakeholders or business analysts to write them.
- Leverage the power of a mature, robust Agile requirements management tool. This helps teams realize Agile’s benefits while leveraging enterprise-level capabilities for visualization, traceability, and reuse. Support for visual models and the ability to relate them to one another and other requirements artifacts helps teams establish the precise traceability they need to ensure full requirements and test case coverage. It also supports improved change management and decision-making, ultimately leading to higher-quality software. Customer journey models can be reused across projects and teams, as can user stories and other requirements artifacts, saving time and improving consistency.
The technology to support requirements management has evolved substantially over the last few years. Yet many organizations are unaware of the powerful capabilities best-of-breed Agile requirements tools provide, including those for visualization, collaboration, traceability, management analytics and reuse. However, a robust Agile requirements tool bridges the gap between business and IT, speeding delivery while managing enterprise constraints. It enables organizations to recognize their goal of scaling Agile across the enterprise to reap its benefits while managing complexity and risk.