Storyboarding/Storymaping/Journeymapping a requirement

"We don't write our stories we draw them." - Walt Disney

I am big believer of being agile but just hated using it as an excuse to be half-assed about requirements and design. Two areas whose mastery has extreme impacts to project success.

It might take little time to create storyboard but we create an understanding on paper then team can make it happen on code. Storyboard can cut off lots of unnecessary work upfront. I want to this blog in value first style, since I completely concur with Simon Sinek and like to start with WHY questions first. Hence lets start with answering our first questions and slowly move forward.

"WHY we should use storyboards?"

Short: Teams are better aligned and confident doing a change or developing a new feature. It helps in building shared understanding in the room.

Long: A picture worth thousand words. Storyboards are extremely useful, when we have a very long narrative to explain. It brings the communication overhead down by multiple notch. It helps in creating a shared understanding where developers can apprehend, what the client or product owner is imagining and why. It is not that a person is right or wrong but with sketches and sticky notes around, we evolve our shared understanding in the room lot quicker which is super-hard with just words alone. It is very easy to make changes and alteration on storyboards vs. on real projects. We can't measure shared understanding but after trying storyboards my teams definitely feel more aligned and confident.

"How we start with storyboards?"
I always like to start with an empty template, like below: There are lots of templates available on google (search world story board template). Or make one, which works best for your team. Choose the one you like.

Start off by visualizing your product or feature. Tell the requirement in the most simplest form before you start building them in most complex form.

Close you eyes and start to think about desired out come.  Who it is for and why are we building it. Think about the tasks a user would perform. Imagine big picture and include pains and joys of user. Write them down on sticky notes and arrange them from left to right flow (also called story telling flow). Try to use verbs to specify tasks. Write phrases in your user language. You must have noticed that each sticky note is a step, and hidden in between each sticky note is the nifty little conjunction phrase, "... and then I ...".  Keep in mind when you are thinking about user using your product. They might have different goals. They may use it in different contexts. This may evolve different types of users or things. Explore other types of users.

Use the goal-level concept to aggregate small tasks or decompose large tasks. Alistair Cockburn uses an altitude metaphor where sea level is in the middle and everything else is either above or below sea level. A sea-level task is one we would expect to complete before intentionally stopping to do something else. 

So far we got all happy path. Now start to think about ".. what about..". We will get some alternative variation for our storyboard. By now, you should get pretty wide board and little deep if you have explored few tasks. 

Now if you will step back a bit, you will find bunch of stories that seems to go together. Cluster these task which seems to go together to help reach a bigger goal. Put another sticky on top of these tasks and write a short phrase on it that distills all the tasks underneath it. This will help us in identifying high level tasks or activities. 

To slice out minimum solution that would both delight people and help reach it's goal, Identify minimum set of tasks that would make that outcome possible. Bingo! In short

• Tasks are short verb phrases that describe what user do.
• Tasks have different goal levels.
• Tasks in a map or board are arranged in a left to right narrative flow.
• The depth of a map or board contains variations of alternative tasks.
• Tasks are organized by high level activities across the top of the map.
• Activities form the backbone of the map.
• You can slice the map to identify the tasks you'll need to reach a specific outcome

Don't forget so far all these are hypothesis so don't forget to add stories for risk and how to measure our hypothesis. Now it's time to develop things which we identified. Focus on risky things. first

In gist building a map helps you see a big picture, to see the forest for the trees. That's one of the biggest benefits of story mapping but if you are the one responsible for building the forest, you make sure to plant one tree at a time. Two most important things which makes them work :

• Use storytelling with words and pictures to build shared understanding
• Don't just talk about what to build: talk about who will use it and why so you can minimize output and maximize outcome.

What are storyboarding or storymapping?

"What I was thinking of was the way users sometimes tell stories about the cool new things the software they use does. [ For example,] if I type in the zip code and it automatically fills in the city and state without me having to touch a button. I think that was the example that triggered the idea. If you tell stories about what the software does and generate interest and vision in the listener's mind, then why not tell stories before the software does it?"
                                                                                                                             - Kent Beck
So the idea is telling, and you know you're doing it right if you're generating energy interest and vision in the listener's mind. That's big and it sounds a lot more fun than reading a typical requirements document. But folks who start using stories for software development and who still have a traditional process model in their heads, tend to focus on the writing part and gets frustrated.

If you are not getting together to have rich discussions about your stories, then you are not really using stories correctly in your project. To get that experience sketch your requirement then tell the stories to explain those sketches during discussion capture the facts as acceptance criteria.

There's some evidence that a fact wrapped in a story is much more memorable than the fact presented alone - 22 times more memorable, according to psychologist Jerome Bruner.

Enjoy mapping your stories
Manisha