Agile Scenarios and Storyboards

Published on 29th April 2013

User stories are great at capturing product functionality. But they are less suited to describe complex user interactions. 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, how they can be used effectively in an agile context, and how they relate to user stories.


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 goal is to book one or more 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 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:

A Sample Storyboard

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:

Persona, Epic, and Scenario

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:

Options for Working with User Stories and Scenarios

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.

Post a Comment or Ask a Question


  • Heloisa says:

    Thank you for sharing your experience!

  • Deep Patel says:

    I have a basic doubt. Like in waterfall model, we have basic flows, alternative flows and exception flows in use cases, how are different scenarios/flows related to a user story mentioned in agile process?

    • Roman Pichler Roman Pichler says:

      Hi Deep,

      Thanks for sharing your question. There is nothing wrong with using use cases in an agile context. In fact, use cases are sometime preferable over user stories, as I discuss in the article “User Stories or Use Cases?“. If you wanted to capture the scenarios in a use case in form of user stories, you would create one or more stories for each success and exception scenario. You hence end up with several user stories instead of having one use case.

      In addition to the functionality described in a use case, you would typically also capture the relationships between use cases, for example, by a system use case or activity diagram, in order to describe a workflow or user journey. If you work with user stories, you don’t have these diagrams available. This is where scenarios and storyboards come in, as described in the post. Alternatively, you can adjust the diagrams and use them with stories, as I explain in the article “User Story Modelling“.

      Hope this helps!

  • Mike says:


    I’ve been simply asked to replicate a report like for like in a new system. The format will be as close to identical as possible and the data analysts will manage the data side. For some reason, I’ve been asked to create a storyboard, which I’ve not used before and though I get the idea, I don’t get how it’s relevant to my scenario. Why would i create a storyboard, a visualisation of a sequence of steps (forgive me for putting it like this, but basically a process that the person or system goes through), when none of that is happening. It’s simple: here’s a chart in Excel, copy this format into your nw reporting system. Do you have any thoughts on this?

    • Roman Pichler Roman Pichler says:

      Hi Mike, Thanks for sharing your question. A storyboard helps you depict a multi-step interaction between a user and a product. For example, when you shop online, you typically search for a product on a website like, look at the product details (which may include reading reviews), then make a purchase decision, place the product in your basket and pay for it. Such an interaction can be happily captured in form of a storyboard.

      Butf you have a simple, one step interaction, you may find a different technique, such as writing a user story, more helpful. For more info, see my article “User Stories are Not Enough for a Great User Experience“. Hope this helps!

  • Sonu Sayeed says:

    Great article Roman….What steps/ strategy would you recommend when proposing high level requirements, for example for a new live chat feature on a web site. Would user stories in conjunction with storyboards and perhaps a sample product backlog work containing some Low-fi wireframes be a good idea. And, would this be best complimented with a roadmap and/or vision board?…what would you suggest for internal stakeholders?

    • Roman Pichler Roman Pichler says:

      Thanks for your feedback and question Sonu. Starting with epics, storyboards, and UI mockups sounds like a good idea to capture a new feature. I would suggest, though, that you ask yourself if live chat is a new feature or a new product, see my article “What is a Digital Product“.

      If it is a new product, then I would first develop a valid product strategy and actionable product roadmap before detailing the solution.

      I also recommend involving the key stakeholders early and regularly and preferably achieving consensus on the strategic product decisions.

      Does this help?

      • Sonu Sayeed says:

        Thanks for the reference articles, I had read them previously but it was good to revisit.
        Yes it is a product but not a new one. It needs revamping in terms of its capabilities with the objective towards driving ecommerce sales. Aiming to propose some high level requirements to kick off mock discussions with stakeholders. Would you still suggest starting with the strategy you’re vision board is a great tool), roadmap into epics, story boards and UI mocks? This is acually for a job an interview, so I’ve been asked not to spend more than a couple of hours the work is a prop for further discussions. Thanks in advance for your input!

        • Roman Pichler Roman Pichler says:

          If you plan to make bigger changes to an existing product, I recommend revisiting the current strategy, identifying the changes required, and updating it accordingly. Then determine the key risks in your product strategy and address them (strategy validation). Next derive a product roadmap and show how the changes are likely to be implemented over the next, say, twelve months. Use the goal of the first major release on your roadmap to discover the right epics. I discuss this approach in more detail in my book Strategize. Good luck with the interview!

  • Ali Raza says:

    Hi Roman,

    Can you help me out with this question? which is,
    How scenarios can help you explore user interaction?

    • Roman Pichler Roman Pichler says:

      Hi Ali, A scenario describes the steps necessary for a user to achieve a goal or get a job done. Each step is an interaction. Think of using a bank / ATM machine. A scenario would describe how you select the service, insert your card, enter you security code, choose how much money you want to draw out, and so forth. Does this help?

  • Shaikhul Islam says:

    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 Roman Pichler says:

      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?

  • Atanas says:

    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 Roman Pichler says:

      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.

  • Atanas says:

    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 Roman Pichler says:

      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 says:

      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.

      • Roman Pichler Roman Pichler says:

        Sounds like a great idea. I’ve written about integrating UX/UI activities in the product backlog grooming work here:

        It would be great to hear how you are getting on.

Leave a Reply

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

Sign up for great new content from Roman

Hear about his latest product management work including new articles, videos, podcast episodes, and more.