Meet Alex Cowan, entrepreneur (5x), intrapreneur (1x), author, and instructor at General Assembly. He’s also the author of ‘Starting a Tech Business’. When he’s not teaching at GA, he’s often found advising companies and posting instructional materials for innovators and instructions on alexandercowan.com. This is the second post in Alex’s series on Storyboarding. Click here to read his introductory post.
Outstanding products are the accumulation of many thoughtful details. Particularly in more mature categories, consistently thoughtful execution is probably more important than grand inspiration.
Agile’s primary input, user stories, have always been a great way to get that consistency. Sadly, they’re not a silver bullet and their impact is often marginalized because of weak stories. Quality stories that really represent users should thread back to personas & problem scenarios, meaning that you have a vivid depiction of who this user is and what underlying need the story’s addressing. Without this, the user stories may end up as a specification for something thought up ‘inside the building’ as opposed to out in the market. Furthermore, the story will end up in out there in the real world without a clear trail back to why you thought it was a good idea and a ready criteria for whether or not it’s delivering the outcome you intended.
Storyboarding gives agile user stories a boost in the right direction. First, you have to show who you’re talking about and what’s happening, which helps link them to personas & problem scenarios. Second, they force a more vivid picture of the outcome you envision for the user, something you can look at a month or two later when you’re asking ‘did that feature make any sense?’.
Quick Review of Agile User Stories
(Freely skip this section if you know stories up and down.)
First off, agile user stories have this format:
As a [persona],
I want to [do something]
so that I can [derive a benefit]
Second, to help stay organized and coherent, stories are often nested within various ‘epic stories’. If you’re new to product development, you’ll probably find yourself writing stories that turn out to be epic stories as you get into their particulars. Finally, ‘test cases’ are a good way to layer additional detail against your stories (test cases not covered here).
Using Storyboards for an Epic User Story
I don’t generally recommend storyboarding each individual agile user story. That’s a lot of work. But storyboarding your epic’s often gets you about the right amount of storyboarding to agile story writing. The final output might look something like this:
I recommend working through to that output in three steps:
1. Write your epic
This is a story that represents a broad swatch of user intent and product interaction.
2. Create a storyboard for it
Create a storyboard that steps through the sequence of your epic. I would do this without fitting the epic’s steps into actual story format- just think through it as naturally as you can. If the epic has various forks within it, you may find you want multiple storyboards to represent those different possible paths.
If you now find yourself wanting to revise the epic, don’t sweat it — that’s natural.
3. Draft the individual user stories within the epic
Once you’re happy with the epic story and its storyboard, then draft the individual user stories within the epic. In the examples here, I’ve then noted which storyboard squares tie to which stories within the epic. As the author, you should know that, and it will make the material more consumable for your reader, but if you find it too much time/trouble, don’t sweat it.
Let’s take a look at an example. I use a fictional company called Enable Quiz in my book. They offer lightweight technical quizzes. Managers use the quizzes to screen new candidates and also assess the skill sets of their existing teams so they can plan training, etc. Let’s say the persona ‘Frank the Functional Manager’ wants to assess one of his teams so he can plan a skills development program. The ‘epic user story’ might be:
‘As the HR manager, I want to create a screening quiz so that I can understand whether I want to send possible recruits to the functional manager.’
The storyboard below summarizes a few steps within that epic story:
Detailing the Epic
In the step above, I wrote an epic and then used a storyboard to think through the course and sequence of the epic without necessarily worrying about how the storyboard panels might break down into individual stories. This is the best first step since you want to make sure you’re creating a vivid, credible customer narrative first and then worry about formulating that narrative into stories. Agile user stories are a tool, not a strategy. They provide an opportunity for quality work, but by no means guarantee it.
Now let’s say you’ve got the epic and related storyboard to a place you like (possibly after a few iterations). You want to package up this great epic for discussion with your implementation team and/or colleagues in product. One thing I like to do is take the epic story panels and (once they’re ready) supplement them with notes and individual stories in a simple table. Here’s the epic above broken down (in this example without any further edits):
This epic assumes Frank and his company have already successfully onboarded with Enable Quiz, using it for screening new recruits.Frank’s first goal is to set up a quiz to complete a skills audit for his team. He has the employees he wants and it’s part of his job to help them make time to develop a holistic skill set.This first step covers these two stories:
A) “As a functional manager, I want to browse the quiz banks [of available questions] so I can make sure I’m subscribed to all the necessary topics for my skills audit.”
B) “As a manager, I want to purchase additional quiz banks so I can add additional technical topics to me quizzes.”
Frank is super busy and yet has a very clear idea of what topics are relevant, so the name of the game here is to make it easy for him to answer Helen.
C) “As a functional manager, I want to review, revise and confirm the set of question topics the HR manager has selected so the quiz will be ready to use for first round candidates.”
Note: This raises some interesting and possibly non-obvious questions about how Helen will do this and how we can make it easier for her to collaborate and close on this with Frank.
Enable Quiz charges based on the number of question topics (organized in ‘banks’) that the customer wants to use. In our narrative, Helen finds she needs to up her limit on available question banks.
D) “As a manager, I want to increase the limit on how many quiz question ‘banks’ I can use so that I can move ahead with the quiz I’ve formulated.”
Note: I’m not adding test cases against these stories in the example, but a good one here would be to make sure that users can put together quizzes with as many question banks as they want, getting warnings about their limit but only encountering a hard requirement to up it once they want to actually use the quiz. Bored with the level of detail here? Well, good products are the accumulation of lots of small, thoughtful details.
Now Helen gets an email from Frank- after seeing the draft quiz, he has
a couple of his own questions he’d like to add!
E) “As a manager, I want to create custom quiz questions so I can add them to my quiz.”
We’re ready! Helen’s using the quiz with a candidate for Frank’s open engineering position.
F) “As a manager, I want to administer the quiz to a recruit so I can understand where they are on key skill sets needed for the position.”
Note: It’s very likely with a little more digging this story is actually an epic itself and needs more detail, but I’m trying not to bore you, reader, with too much stuff!
Helen’s administered the quiz to some recruits and wants to send the results to Frank, possibly with supplemental notes in a few cases.
G) “As an HR manager, I want to send the results of our screening quizzes to the Functional Manager so he can decide who he wants to interview.”
H) “As an HR manager, I want to add supplemental notes to results for some of the candidates so I can share additional thoughts on the candidates with the functional manager.”
Why user stories? Storyboards?
Here are a few more reasons I like the user of stories:
They dovetail with design thinking outputs like personas, problem scenarios and value propositions.
They are highly consumable by developers, designers, and other creators who are helping you execute, balancing structure and description; specificity and objectives.
They’re robust and ‘nestable’, scalable even for large, complicated projects.
Storyboards are a great way to keep agile user stories from mimicking the dull, context-free requirements definitions they were meant to replace. They help avoid myopia, making sure you’ve thought through the whole story. They’re also a great way to engage your audience.
If you’d like more on storyboards or agile, here are a few things you might find handy: