If I understand this through my past 5-6 years of Agile Scrum:

  1. Product Owner is responsible for a regulated Product Backlog, and delivering user stories to businesses.

  2. To realise the product vision, storyboarding is necessary with Product Owner, Development Team, UX, and Stakeholders.

  3. You can either use a Whiteboard/JIRA to track your user stories which are part of your product backlog.

I find 1 and 2 a little confusing. Because a Product Owner will be creating all the story cards to initiate conversation with the team, and eventually achieve confirmation that they're done. But at the same time, a shared understanding must be achieved by doing storyboarding and involving different teams (i.e PO isn't the sole owner of all cards). Also, this is quite different in every organisation because not every team has a product owner (e.g. IT Operations where the team are the product owners).

Based on this, I don't believe there's no right/wrong answer - rather what fits. My question is “What should a product owner do with storyboarding/storymapping and the backlog”?

  • Scrum isn't well suited to IT Operations. Kanban works better there.
    – Bogdan
    Commented Jul 11, 2020 at 13:19
  • "Agile Scrum" - there's no such thing, it's like saying "quick oranges". Agile and Scrum are orthogonal, they are about different things - one is about changing the process to suit the situation, the other is just an example of a process that could be chosen. Commented Jul 13, 2020 at 15:17

2 Answers 2


When you need to build a product (or even some module, or feature), you need to have a list of items that are part of that product, so that you know what you are currently working on, what to build next, track and communicate progress, etc. In Scrum, these are items in the product backlog (usually expressed as user stories).

The product owner is the one responsible for managing the product backlog, to create the items in it, prioritize them, detail them, and make sure the items are clear enough so that everyone understands them.

The product owner can obviously just sit down and create a bunch of items and user stories and add them to the backlog. If they know exactly what they want, and know what they are doing, this approach can work. Sometimes though, this approach might be insufficient. Depending on the product's complexity, on how many stakeholders there are, etc, the product owner might miss some activities or interactions between user stories when they just write them down as a list. They might also have a harder time prioritizing them too, if there are dependencies between them.

Storyboarding and user story maps are techniques to better visualize stories, the interactions between them, the activities and roles necessary to build the product. They are good techniques to gather requirements from stakeholders, discuss with everyone what's needed, and create user stories from those discussions. With user story maps you can also decide easier on possible releases since you now have a map of stories instead of just a list of them, and you can more easily draw lines of separation between what's needed and important now and what can wait for later.

What should a product owner do with storyboarding/storymapping and the backlog?

The product owner use them to make sure the product is properly defined so that everyone knows what needs to be built. It's the product owner's job to manage these, but as you mentioned yourself, a shared understanding must be achieved (for ex, if the product owner knows what's needed but developers or stakeholders have no clue, then there is no point in doing storyboarding or story maps). Also, how this shared understanding is achieved differs from company to company; some companies use techniques like storyboarding/storymapping to do that, some don't. Whatever floats their boat.

  • Alas! I wish the so called "Agile Coaches" could understand what fits/doesn't fit for an organisation. It seems that by reading some books and going through a few website/search engine exercise examples it's possible to do everything using Scrum. But it isn't.....
    – ha9u63a7
    Commented Jul 11, 2020 at 16:38
  • Scrum is a tool. Tools work best when they are used for the proper job (for heavy product maintenance Kanban is better for example, while Scrum is good for product development). Storyboarding and story mapping are other examples of tools. I personally find user story maps useful, and storyboarding a little bit silly, but that's just my take on things. As for Agile Coaches, a lot of them have never run an Agile project in a real setting and all their experience is resumed to theory in the classroom.
    – Bogdan
    Commented Jul 11, 2020 at 16:55
  • @Bogdan, JIT (Kanban) is actually pretty good for Product Development: qala.io/blog/myth-kanban-is-for-maintenance.html. Much more effective than Scrum. Commented Jul 13, 2020 at 15:14
  • @StanislavBashkyrtsev: in my comment I was just offering an example of choosing an appropriate tool for the job, considering the OP mentioned IT operations in their question. I agree with you that Kanban works well for product development also.
    – Bogdan
    Commented Jul 13, 2020 at 15:38

One "non-traditional" technique that I used in a particularly technically-complex project was to construct a sort of "knowledge base" (KB) that was managed by the Product Owner (in association with Stakeholders), and provided to the team.

This KB was first used as a repository of authoritative information about the complexities of the underlying business. Then, as implementation-related technical decisions were made concerning the interpretation of these things, those were added to the KB as well – "footnoted to" supporting information elsewhere in the KB. The "user stories," then, referenced these particular added sections.

It seemed to work pretty well ...

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.