At this phase, you can convert requirements into user stories that are intelligible to anyone and are testable throughout the forthcoming selection process. User stories are short, real-life narratives that describe your information, your processes, your people, your customers, and your anticipated business results.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 shorthand 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
- (Optional) Variant—Some additional steps that might get addressed during the demo phase only as time allows
Before we get into the meat of the narrative, understand that the RFP background and objective sections of the stories are important setups. The background introduces the personas, provides a back story where needed, and helps the readers understand why they are pursuing particular journeys. The objective explicitly tells the readers why the scenario is included at all: the all-important business goal, which should shape how bidders respond.
Caution: Avoid the Word User
You want to enter any procurement with a clear list of actors and their roles in any system. For the purposes of this book, we cite the catch-all term users, but ironically, the one word you want to avoid in your RFP stories is user.
Instead, raise up the people who really matter by their specific role: customers, colleagues, customer service reps, managers, prospects, partners, distributors, suppliers, developers, designers, authors, editors, data analysts, community managers, marketers, directors, executives, knowledge managers, line workers—the available list is endless.
For the system you’re trying to procure, there’s a handful of personas that matter a lot. Call them by name.
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 okay—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.
If you want an alternate ending or perhaps a journey needs to go in a different direction, you can include a variant paragraph or two. Resist the urge to go overboard here just to satisfy a squeaky wheel or random edge cases. The more tangents you include, the more you dilute the truly important requirements. We often recommend that bidders don’t need to give written answers to variants, but may have to demo them as time allows during the demo or PoC phases.
