Tech Selection Tips #5: User Stories Are Everything

In our last set of tips ("Requirements That Don't Suck"), we emphasized the importance of user stories over long feature checklists.  But how do you do this right?  Here's some more tips.

About User Stories

User stories are short, real-life narratives that describe your information, your processes, your people, your customers, and your anticipated business results.  Here's an example user story.

After defining the business case, this the most important foundational work you will do in any technology selection effort, so spend some time to get it right — but don't agonize over the details, since you'll have the opportunity to modify them as you learn more throughout the selection process.

User Stories

How to Structure a User Story

There are many ways to structure user stories and indeed, some software development methodologies offer very specific guidelines. For the purposes of technology selection, we suggest a seven-part structure for each:

  1. Title: The name of the journey
  2. Task Profile / Persona: The person’s role, including a named persona to make it more human, typically with limited access rights
  3. Description: A short-hand sentence to expand on the title
  4. Background: The setup for the scenario, with useful context
  5. Objective: What you need to accomplish and why
  6. Narrative: What happens—a story about what the personas experience and do, including decisions that they make and the outcomes
  7. Variant (optional): Some additional steps that might get addressed during the demo phase only as time allows 

The narrative is where all the action happens, where you tell the stories about how the personas interact with each other and the system to achieve certain ends. There is both an art and a science to drafting such narratives. You want to be reasonably detailed, but not prescriptive; for example, you don’t specify where a "submit button" appears on a screen, just that "Edna the Editor saves her work prior to publishing."

To the extent possible, narratives should reflect "to-be" journeys and as such are designed to be aspirational. If you know that a particular narrative might present a "stretch" for existing state-of-the-art, that’s OK — just signal to the bidders that you know what you've sketched out might be difficult to execute and then see what they come back with.


  • Pay more attention to developing scenarios than "checklist" requirements
  • Deploy your user stories as the core of your pending RFP/Tender (more about that later)
  • User stories ideally reflect a "to-be" process, although you may want to document "as-is" as well
  • Do not make user stories overly prescriptive; give the vendors a chance to address your challenges creatively
  • Develop user stories that speak to the needs of each major actor in your pending system, but prioritize the most important journeys
  • Consider user story "variants" or "alternate endings" to address diverse processes, but don’t do this just to satisfy myriad edge cases that distract from your most decisive requirements
  • Perfect is the enemy of good; you’ll have a chance to iterate on these user stories if you follow RSG's agile process

Next Steps

If you're selecting digital workplace or marketing/engagement technology, be sure to check out RSG's hard-hitting vendor evaluation research.

Other Posts in This Series

Buy the book


Other ECM & Cloud File Sharing posts

ECM Standards in Perspective

In real life I don't see ECM standards proving particularly meaningful, and you should see them as a relative benefit rather than absolute must-have.