Agile Scenarios and Storyboards

Roman Pichler

Written by Roman Pichler

on Monday 29th April 2013



Find out how scenarios and storyboards can be effectively used in an agile context complement, and how they relate to user stories.

31 Flares 31 Flares ×

User stories are great at capturing product functionality. But they are less suited to describe the user interaction in more detail. This is where scenarios and storyboards come into play: Both are great tools to describe the interaction steps. In this post, I explain what scenarios and storyboards are, and how they can be used effectively in an agile context, and how the two techniques relate to user stories.

Scenarios in a Nutshell

Scenarios and storyboards are great to explore and describe how a user interacts with a product. When we started to work on the re-launch of our website, for instance, I wrote the following scenario:

  1. It’s Tuesday morning, and Mary is working on her computer. She wants to book Roger Smith on a public Certified Scrum Product Owner course taught by Roman.
  2. Mary visits and chooses a public CSPO class.
  3. She enters the participant information including first name, last name, email address, special dietary requirements.
  4. She then chooses a payment option and enters the payment details.
  5. Mary accepts the terms and conditions, and confirms the booking.
  6. Mary sees that her booking has been successful. After a short while, Roger receives an email confirmation with the booking details.

The scenario above describes the steps Mary has to take to book a seat on one of our public training courses. Mary is a persona who represents a user of our website: an HR employee of a large company, and who’s main need it is to book employees on a training course.

Note that I have tried to make the scenario descriptive and engaging while focussing on the key aspects of the interaction.

Storyboards Summarised

Storyboards are similar to scenarios: They illustrate the interaction required to achieve a goal. But instead of using a list of steps, a storyboard visualises the interaction similar to a comic strip. Here is a sample board I created to explore another interaction for our new website:

The storyboard above describes how the persona Mary books several employees on the same training course. The board consists of a series of frames. Each frame shows sample data. Underneath it, I added a brief description of what Mary does at each step.

Note that I have done my best to describe the functional aspects of the interaction, and not to design the user interface: When I was working on the board, we did not have any design sketches and mock-ups available. I generally find it good practice to capture the product functionality necessary to meet the main user needs before designing the user interface.

What about User Stories?

User stories are another technique to describe the user interaction. A large story or epic allows us to summarise the interaction acting as placeholders for more detailed stories. I like to think of an epic is as a scenario rolled up into a brief narrative: it hides all the specifics of the user interaction. Detailed stories correspond to individual steps in a scenario, and describe a specific piece of product functionality.

The first thing I usually do when working on a new product is to write epics. To discover the right ones, I use the needs of the personas. Starting out with epics helps me quickly sketch the new product functionality, and it keeps the Product Canvas or product backlog concise and manageable.

But working exclusively with epics can be problematic, particularly when the epic carries risk: If we only have a coarse-grained description available, then it’s difficult to test our assumptions about how the users interact with the product. I therefore prefer to create a scenario or storyboard for risky epics, as the picture below shows:

Creating scenarios or storyboards for selected epics allows me to explore the user interaction in more detail, to describe the necessary steps and their relationship. This helps me test my assumptions, for instance, by creating a paper prototype that implements the scenario in order to carry out an early user test.

This is, of course, not the only way to combine scenarios and user stories. You can also derive stories from a scenario, and you can use a scenario to illustrate the relationship between different stories. The following diagram illustrates the three options:

Choose the options that are most helpful in your context, and combine them, as it makes sense. You can, for instance, start with the first option (as I did above), then derive new stories from your scenario or storyboard, and finally capture the relationship between the new stories in a new scenario.


Scenarios and storyboards are great tools to describe how users interact with a product. They also complement user stories nicely: Scenarios and boards help explore risky stories, discover new user stories, and capture the relationship between stories. Make sure you include scenarios and storyboards in your product owner toolbox.

You can learn more about working with scenarios and storyboards by attending my Certified Scrum Product Owner training course.


8 comments on “Agile Scenarios and Storyboards

  1. Atanas

    Hi Roman,

    Thank you for the good summary !

    I still wonder regarding the usage of User Stories (US) for UI. I work in the are of e-Commerce and the web-shops normally are saturated by pages and UI design.

    I normally write UI USs, which capture that overall design of the page. Those US are then related to the various user interactions.
    To summarize, if we have a *login* functionality, i would have:
    – US for the Login page UI
    – US for logging in
    – US for forget password
    – US for restrictions
    – etc.

    Please share with me your opinion in such an approach.

    Thank you in advance !

    • Roman Pichler

      Hi Atanas, I prefer top capture the user interface design using sketches and mock-ups rather than in textual form. Please take a look at my post “Agile User Interface Design“. Hope this helps.

    • John

      This is actually a scenario my team is working to resolve right now. We tossed around the idea of creating a UI story and a functional story for each story in order to track the UI work, but we decided to go another direction because we wanted to ensure stories completed at the end of the sprint adhered to a certain definition of done (UI, testing and development completed). We decided to create a definition of ready that required all stories coming into a sprint accompanied with a wireframe, acceptance criteria and design pattern in order for our developers to have the ability to fully complete the story. Unfortunately I can’t speak on how successful this idea is as we haven’t started sprinting yet. In theory it makes sense and because we are a small team (4), we think we can allow for flexibility without much issue.

  2. Atanas

    Hi Roman,

    thank you for the clarifications. I read often your and Mike Cohn’s posts to get wisdom and inspiration.

    The reason we use User Stories for UX is due to the fact that we we want to capture the UI efforts and deliverables. For the planning we extended the study of Desirée Sy and Lynn Miller “Adapting Usability Investigations for Agile User-centered Design”. All UI packages became User strories.

    Using a US approach gives us the possibility to make a UI backlog, visualize it in a tool, report progress and prioritize it. This way we gained tremendous visibility for this workload towards the Client.

    Please share with me how you see that approach.

    Kind regards

    • Roman Pichler

      Hi Atanas, I prefer to work with one product backlog that contains all the outstanding work necessary to develop the product. You may want to take a look at my Product Canvas, which offers an alternative to a traditional, linear backlog and makes it easier to integrate the user models, the visual design, and the interaction design with the product functionality (epics and user stories):

      Hope this helps.

  3. Shaikhul Islam

    Hi Roman,

    Great post. Do you think, User Journeys are same or similar to Use Cases as I see all the elements of a normal use case flow from your given example. The only thing I don’t see here is exception and alternate flow.

    How would you then handle this in a user journey?

    Also, do you think a user journey should be about capturing an end to end process that a user intends to complete with the system?

    Names could be different but I can see the basic concepts are same.

    Please enlighten me.



    • Roman Pichler

      Hi Shaikhul, Thanks for your feedback. User journey and use cases share some similarities. Both describe the steps a user has to take to achieve a goal. Where they differ, in my view, is their scope. Use cases (or system use cases to be more precise) usually describe the detailed steps necessary to benefit from a specific functionality or use a specific feature, for instance, registration or search. User journeys, however, describe how users use several features and may include what users did before they started using the product, for instance, finding a website on Google Search, registering with the site, looking for a product, selecting it, and paying for it. In other words, you can think of a user journey as a sequence of use cases. Does this help?

Leave a Reply

Your email address will not be published. Required fields are marked *

31 Flares Twitter 11 Facebook 4 Google+ 11 LinkedIn 5 31 Flares ×