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.
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:
- Title: The name of the journey
- Task Profile / Persona: The person’s role, including a named persona to make it more human, typically with limited access rights
- Description: A short-hand sentence to expand on the title
- Background: The setup for the scenario, with useful context
- Objective: What you need to accomplish and why
- Narrative: What happens—a story about what the personas experience and do, including decisions that they make and the outcomes
- 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
Other Posts in This Series
- Tip #1: Articulate a Solid Business Case
- Tip #2: Build the Right Team
- Tip #3: Setting the Right Business Foundations
- Tip #4: Capture Requirements That Don't Suck
- Tip #5: User Stories Are Everything
- Tip #6: Ask Questions That Really Matter
- Tip #7: Find More Than the Usual Suspects
- Tip #8: Target the Right Suppliers
- Tip #9: How to Engage Vendors
- Tip #10: Create RFPs That Actually Work
- Tip #11: Keeping It Real with Bidders
- Tip #12: Evaluate Proposals Critically
- Tip #13: Hold Demos on Your Own Terms