Article No :1690 | September 28, 2017 | by Jarrod Gingras, Tony Byrne
Chapter 5: Why User Stories Are Everything
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.
After defining the business case, it's the most important foundational work you will do, so spend some time to get it right — bbut 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 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
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.
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.
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.
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.
Example User Story
Here’s an example user story. It’s a simple one, and yours may prove to be more complicated, but you’ll get the gist of it (see Figure 5.1).
An example user story for a web content management system (“CMS”) at a public university.
With this user story, the customer has signaled a variety of important requirements, but most importantly, they will be able realize those needs and opportunities in the context of an actual business process that needs to get executed on a regular basis.
Don’t Be Overly Prescriptive
There is a bit of art and science when it comes to developing user stories. The trick is to be descriptive of what you want your future state to look like, but you need to do so without being overly prescriptive. You want to leave it open-ended enough so that the vendor can do the prescribing of how their solution best meets your needs. So in your stories, talk about what employees and customers do, but don’t go into too much detail about how they do it.
Which User Stories and How Many?
How many user stories should you develop? To paraphrase Winston Churchill: all that are necessary, and not one more. Of course, this depends to a large degree on the complexity and importance of the technology you’re selecting. If you are procuring a new email platform for a 40,000-person enterprise, you’ll want to make sure you’ve accounted for numerous use cases. If you’re selecting accounting software for a mid-sized business, you may have only three or four journeys to address.
Don’t Dilute Your Most Critical Journeys
If you get tempted to add more than six-to-eight user stories to your selection process, understand that each one you add makes more work for both you and the bidding vendors. It becomes more for them to describe and demo, and more for you to evaluate throughout the process. Note that most user stories involve multiple personas, so you don’t need an individual journey for each key persona.
If you find the team wanting to include more than eight, have you really prioritized your requirements against your business goals? Reference your business case and focus on your most important objectives.
Which user stories should you pursue? Here again, you should be guided by your business case — applying new technology to which personas and journeys most effectively satisfy your business objectives.
This will prove highly situational. For example, in an ecommerce platform selection, you will isolate different types of customer journeys (new customer, returning customer, failed transaction, etc.), as well as interweave how your key enterprise colleagues (marketers, merchandizers, customer support staff, designers, etc.) will interact with the platform.
When selecting workplace or customer-facing technology, be sure to include essential IT personas and tasks, such as developers enhancing and testing the platform. Even simpler, SaaS-based products can entail consequences for your internal IT team, including requirements like integration with your single sign-on (SSO) layer. While some of these are one-time challenges best addressed as specific questions (see Chapter 6, “Ask Questions That Really Matter”), to the extent your IT colleagues need to interact with the system regularly, they become important personas and often require their own stories.
Similarly, don’t restrict the narrative to just the tool you’re procuring. With expanding technology portfolios and the rise of API-driven development, your new platform is unlikely to prove completely free-standing, and instead will need to co-exist within a larger ecosystem of tools. From a user’s standpoint, it really shouldn’t matter: they have a particular goal and shouldn’t have to think about your system boundaries. So follow the story where it goes and instruct each vendor to propose how their piece fits together into your larger whole.
Don’t Rule Out Other Types of Stories
By the time you read this, methodologies around “design thinking” will have evolved. It’s early days for this new world of technology requirements definition, and we’re seeing a lot of useful experimentation.
In particular, you’ll likely find alternatives to user stories. One promising approach is “job stories,” which focus on situations, motivations, and outcomes rather than personas, context, and journeys. Doubtless other types of storytelling will emerge as well. We’re agnostic on what works best, and you should be, too, as long as your selection process includes a narrative approach to describing interactivity rather than a checklist of features.
As always, know that the iterative process described in the chapters that follow means that you can modify and switch out individual stories as you start to see systems in action. Follow your best initial judgment, but then give yourself the leeway to adapt.
For links to example RFPs with completed scenarios, see the appendix, “Resources and Examples.”
- Pay more attention to developing scenarios than “checklist” requirements.
- Use your user stories as the core of your pending RFP (more about RFPs 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 vendor a chance to address your challenges creatively.
- Develop user stories that speak to the needs of each major actor in your pending system, but as always, 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.
- In a world of evolving UCD methodologies, you might choose another approach like “job stories” — the important thing is to describe an interactive narrative.
- Perfect is the enemy of good; you’ll have a chance to iterate on these user stories throughout the process.
If you are interested in reading the rest of the book, you may purchase it at Rosenfeld