User Stories: You Don’t Have to Be Agile to Use Them!

In past articles, I’ve spent lots of time asking you to find common ground between waterfall and agile. Not to discount either approach, but in realization, when done well, they have more in common than we often recognize. This call to find bridges between approaches comes from my experience with organizations working hard to manage a melting pot of methodologies, approaches, and leadership mandates. Organizations value adaptability, flexibility, and experimentation while hanging on to patterns that are traditional and comfortable, so teams (and their vendors) include pockets of traditional, hybrid, and agile approaches.

Shifting leader mandates along with a rotation of new tools and templates for each approach, leave many project teams churning in the wake. It’s rare that a team or organization fully implements a new methodology or approach. Instead they just grab bits and pieces—creating a hodgepodge of terms, techniques, and deliverables. Done strategically, a Swiss-Army-Knife approach might not be a bad thing, but without basic standards and principles across an organization, collaboration between teams can become difficult.

So, how do we create consistency and alignment? How do we help teams collaborate without forcing them to modify their methodology or approach? It’s really about communication—using techniques that generate dialogue and create shared understanding.

User stories are one technique that can provide context for great conversations regardless of methodology. They can align waterfall and agile practices a bit more and still leave timing and level of detail up to the approach. User stories are often done poorly, and must be done well to get the results!

Here’s an overview of the primary benefits of user stories for all projects:

User Stories are a “Placeholder for Conversation”

Most agile gurus define user stories as a “placeholder for a conversation” or a “promise of a future conversation.” This user story mindset aligns well with waterfall and agile and everything in between, because meaningful dialogue is the key to project success!

User stories promote meaningful dialogue by:

• Providing a great way to organize and prioritize your conversations
• Allowing work to begin without getting stuck in the muck of details
• Providing a dialogue centered around value to a user
• Creating a project parking lot: a simple way to let stakeholders see what is in the queue and reassure them that their needs will be met.

User Stories are the Tip of the Requirements Iceberg

Are user stories just a placeholder or a promise? Or are they requirements? It’s a great debate in some circles, but in my mind it’s clear; user stories provide high-level stakeholder requirements that give context needed to build shared understanding among stakeholders. Once a project team establishes business objectives and goals, they can create user stories to define the tip of the requirements iceberg.

Over time, BAs explore each user story, chipping away the iceberg and diving into the details. User stories help teams organize requirements in functional “chunks,” which simplifies:

• The end-to-end slices of value to the user
• Decomposition and elaboration
• Prioritization of requirements, releases or iterations
• Visual modeling
• Gap analysis
• Analysis of constraints and dependencies
• Testing

User stories become a valuable elicitation and analysis technique for all project teams, but the timing, documentation and level of detail can be adjusted to fit in a traditional, agile or hybrid model.

User Stories Focus Outside In

The obvious and most important benefit of user stories is user focus. When a team creates a basic set of user stories at the beginning of a project or iteration, the team’s time and talent tend to focus on the user’s point of view instead of the project team’s point of view. This outside-in focus offers many advantages including:

• Clearer Context: The user perspective provides a common language for stakeholder discussions. It allows each stakeholder to understand how and why they will be affected by the project.
• Integrated Approach: Many projects get into trouble when they work in silos by function or application (stand-alone systems or components of systems). User stories, written correctly, force an integrated approach because a user perspective ignores artificial project team boundaries. When a user makes an online purchase, they do not see separate applications. They browse items, make a purchase, pay, and receive items. Users do not get value from the web page alone, the product database alone, or the payment processor alone — the user gets value from the integrated experience.
• Added Value: Project teams with user-focus deliver more value to users. Why? The outside-in approach establishes a core value that guides decision-making throughout a project. User focus minimizes distractions and complexity when every work product begins and ends with, “How does this bring value to the user?”
• Increased Innovation: The basic format of user stories (defining role, task and reason) offers something unique that other techniques rarely include—the WHY! When teams understand user motivations, innovation comes naturally. Teams can quickly brainstorm many new and creative ways to solve the user’s problem.

Maximizing the Benefits

Just like any technique, user stories provide maximum benefit when applied strategically. The project team needs to be conscious of the WHY. Why are we using this technique? What value will it bring? What depth, scope, and timing will bring us the most value with the least amount of work?

Consider the law of diminishing returns. Where should the user story effort fit on this curve?

The answer will vary by project, probably depending on the value of the opportunity or level of risk or consequences of failure:

• Do you need a user story for every possible user interaction with the system?
• Do you need to include every value gained from the user perspective?
• Do you need a user story for every possible type of user?
• Is perfection critical? You might need to hit the high point of the curve?
• Is budget or time to market critical? You might stay in the range that maximizes your ROI.

Also, remember that user stories are not meant to be comprehensive—they will not lead us to every detail or task required to deliver a work product. Regardless of your project approach, you will need to supplement user stories with additional BA techniques that elicit detailed requirements, acceptance criteria or more dialog.

Don’t forget to leave your comments below.