Written by

The User Story Map is a simple and yet powerful way to visualize the story about how the users are using your product or service – and to build the right thing.

It is simple because it offers support to move quickly from understanding the user and their problems – to building and shipping the product, and it can be done just with sticky notes on a wall, or in simple digital tools.

It is powerful because it tells a story, it gives context to the user story and it gives a clear overview of the backlog and what we need to build to be able to support the user scenarios over all relevant touchpoints. It also supports collaboration and both horizontal and vertical slicing.

I am forever thankful to Jeff Patton who is the creator of User Story Mapping and from who I learned it from about 13 years ago or so. Without it I don’t know where I would have been today. It has been one of the most valuable methods for me to enable deliveries of great user experiences although in very complex domains, real deadlines (like sports events that happens when it happens) with one or up to +20 teams 🙏

It is a living, transparent, and value-based backlog that support the Product Owners and teams to find thin slices to release that create real value based on user scenarios, and not features. If you are looking to become a value and product-driven organization, this tool offers a lot of support.

It might not come as a shock to you that the User Story Map is the most common tool used for Agile product planning with one or several teams.  Jeff Patton invented it and brought it in as a major part of the CSPO (Certified Product Owner) training when he first created that many years ago for Scrum Alliance.  Jeff Patton, with a background in UX and design, has been a great force in Agilizing customer-centric ways of working and finding ways to connect it in a natural way to Scrum and product teams.

User Story Map Concepts

A user story map tells a story about a type of person doing something to reach a goal. Make sure to include them in your map along with a little information about them. Try using lightweight personas or roles to describe your users.

User Tasks

User’s tasks are short verb phrases that are the basic building block of a map. If I ask you what you did earlier today when using email, you’ll likely respond with tasks like:

• Read an email message
• Respond to a message
• Mark a message as spam

User Tasks makes great User Story Titles
Write short verb phrases on cards or stickies. Use them later as your story titles. If you use the story template to write descriptions, the task fits
nicely right after “I want to,” the activity fits nicely right after “so that…”

Goal Level

The actions that users take in order to reach their larger goals have a goal level themselves that’s tied to user behavior.

Summary: lots of tasks done in support of a bigger goal.
Functional: I’d expect to complete this task before taking a break.
Sub-Functional: smaller things done in support of a bigger task.

As you read across tasks in the backbone, check to make sure that tasks are of a similar goal level. 


Activities organize tasks done by similar people at similar times to reach a goal. For your email software activities might include

• Going through my inbox
• Configuring my email client
• Organizing messages into folders

Narrative Flow

The left to the right axis in a story map is organized in the order you’d tell the story about your user to someone else.

Of course, any specific user might choose to do different things in a different order. Use conversation to explain the details and variations.

If you’re looking for the precision of a workflow model, flow chart, or UML model, then a story map isn’t your best choice.

A story map will take lots of conversation to use effectively. But then that’s the purpose of stories.

Details, Details…

Break down high goal level tasks into:

• Sub-tasks
• Alternative tasks
• Exceptions
• Details

It is ok to capture ideas for solutions are ok in the details of the user tasks or activities of what the UI might look like or what the system might do in the background. But preferably this is something that is done first with design studio or something to use the collective intelligence, and then as the team start to deliver in each sprint.

Release Slice

Draw a line across the map, or use a tape to identify slices of tasks that users might use your software to reach their goals. The smallest number of tasks that allow your specific target users to reach their goal compose a viable product release.

Use release slices to identify small experiments, minimal viable product releases, or a “walking skeleton” version of your product.

Identify the target outcomes of your slice in a sticky note or card on the side of the slice. 

Map Now & Later

Use a map to describe the world as it is today. Inject pains, joys and rewards, details and observations, and solution ideas. This can be done based on your Customer Journey, or your User Transaction Map, which are great tools to uncover the as-is-state of processes, complex interactions, and the experience.

Evolve the map using design and discovery activities such as storyboarding or design studio to describe the behavior you expect users to have in the future.

User story maps are for understanding now, and imagining later.

Map the Whole System

Map a whole process as it crosses through a number of types of users and touchpoints. Story maps are for looking at the big picture.

The Process of mapping

The story map evolves with your understanding of your users and your product solution.

1. Before mapping

Set the stage on what customer journey, product, service, and target users you most likely will have in your map. Remember this might be updated once you uncover the full story. This might tell you who to involve in creating it, and what customer journeys, user transaction maps, or personas that might need to be done before you move over to the user story mapping.

2. Map the big picture

Focus on getting the whole story. Think “mile- wide, inch deep” The activities and high-level user tasks that tell the whole story form the backbone of your story map. Look at the customer journey end to end, what they do before, during and after using your product.

Start with the user type most critical to your product’s success. Imagine a typical day in your user’s life with your new product, or use information from your user research and map it directly from your customer journey or user transaction map. Map the steps they take as user tasks left to right. It is ok to make assumptions at this phase, but all risky assumptions would have to be validated to make sure you deliver the right product and meet real user goals.

Identify user activities – groups of tasks that work together to support a common goal. Activities often emerge after you see more of the story. Make sure the user activity end with the user reaching its user goal in that activity.

Add in additional users. As you follow the typical use of your product, you may find other types of users enter your story. Continue modeling their story left to right.

3. Explore

Fill the body of your story map by breaking down larger user tasks into smaller subtasks. During this phase, you’ll add cards, split one card into two, rewrite cards, and reorganize them. 

Any tasks and sub-tasks that might not give value to a user will be out of scope and not prioritized to build or work on, but this will be discovered later in the process when you start to validate your ideas and release.

It might be a good idea to timebox this phase. Keep in mind that “good enough” actually will take you longer than having all the details in now when you have the least information.

4. Slice our viable releases

Slice your map into holistic product releases that span the users and use of the product. These slices form an incremental product release roadmap where each release is a minimal viable product release.

For each release name the target outcomes and impact. Outcomes and impact say how this release contributes to the overall goal in the “big why” that motivates building the product, and how users will behave in a way that helps us reach the goal.

Example of release goals:

Release #1
 enabling the user scenario “Start an account, put in money and use it online” for the persona “Millenial Millan” 

Release #2 enabling the user scenario “Send and receive money from friends” for the persona “Millenial Millan”

For each release, identify product success metrics. Answer the question: “what would we measure to determine if this product was successful?” Ideally, you’ll find specific changes in user’s behavior as they use the product the way your story map imagines.

5. Slice out a development Strategy

Slice the first release of your map into three or more delivery phases that allow you and your team to learn fast and avoid risk. Think of the opening, mid, and end-game phases of a chess game.

This development strategy will help you release the best product possible in the time constraints you have.

  • Opening Game builds a “functional walking skeleton” – the simplest possible functional version of the product. As you finish “Opening game” vet the product with users and other stakeholders. Begin validating wanted performance and scalability.
  • Mid Game completes all major functionality and makes existing functionality richer and more complete. Continue user testing and leverage feedback to adjust the product. Continue testing performance and scalability.
  • End Game refines the product in preparation for release. Continuously assess release readiness based on your release level product goals. Count on unforeseen work to emerge during this last stretch of development.

Once the User Story Map is up this is the living backlog that the Product Owner, or Product Owners use for continuous planning together with the team or teams. Based on the release goals the team(s) can plan what user tasks to cover, and the Product Owner(s) can re-plan the release goals based on feedback.

The User Story Map as the Product Backlog – with one, or several teams

A lot of times when using a User Story Map for a big project, you end up not doing about 50% of the storys. This is due to that those are not needed to reach our goals and satisfy our users. This of course saves a lot of time and money, that we can spend on the next prioritized goal.

When working Agile we want to keep our teams stable over time and they will release incrementally, and iteratively, and the teams always maintain what they built.

The user story map is a great way for the product owner to facilitate that ownership over time since the backbone of a process always stays the same they can add in new stuff when they learn about it, and re-plan their sprints and release goals. The map is also a great way to keep stakeholders in the loop on what the teams are working on, and what not. It is super transparent.

Want to learn more?

This content is part of our Agile Management In a Nutshell in our Digital Academy.

Agile Online Trainings at your own pace, in a fun, brain-friendly and engaging interactive format. Get access now!

Written by

Agile Product Management

Why do we need Agile Product Management you might think? The main reason is to ensure we are building the right thing. Having both customer focus, and understanding what the priorities are for the business is crucial for most product organizations to survive in a highly competitive market.

When delivering software, digital services, and products in traditional ways we often end up acting on every idea and need we can think of beforehand, without actually knowing if the needs are real and if the solutions would actually help the customer to solve a real problem.

Only half of what we build is being used!

Research shows that most digital solutions are poorly prioritized, where only 20% of the features are being used always or often and 16% sometimes, the rest is just clogging the user interface making it difficult to use, and the user experience terribly ineffective. On top of that, it costs a lot of money not just to build, but also to maintain that 100%. What if we could instead deliver only those 20% or 36%, and in the right order pleasing our users and giving us feedback on how it is being used? This is what good product management is about.

As seen in the graph above more features increase the complexity of the service both for the user, as the interface gets cluttered and it decreases the usability, but also for the developers who are maintaining and developing it. The cost increases for development and design, as well as for maintenance. 

This is something we often refer to as technical debt but it is also usability debt and it is one of the great reasons many want to start working Agile – to build the right things that help the users become happy with the product or service we deliver.

When working Agile we deliver value continuously, incrementally, and iteratively. This enables us to early on get feedback on both if we are solving the right problem and if we are solving it in the right way. To be able to do so the product management work needs to be done in an Agile way to be able to re-plan based on new learnings and always work on what is most valuable for the customer- because that is our business.

Making quick decisions and delivering high quality

Cross-functional Agile teams should have the competencies to both understand and deliver solutions that are truly valuable for the customer, for the business and that are feasible. Sometimes feasible might mean that you create a simple prototype that you then throw away and re-do after learnings, and other times feasible might mean scalable, sustainable and safe. An Agile Product team that has these competencies and the mandate to make decisions, can discover what is truly valuable, not delivering only on what users ask for. By making quick decisions, the team can keep a fast pace while still maintaining high quality. The Product Owner is needed in the team to work together in a shared process to discover what to deliver to make tactical decisions along the way to meet strategic goals.


Did you like this post? Read more on Product Management and Product Development

>> Product-Led Organization: What it is and Why it Matters to You

>> Strengthening your product strategy 1: assess

>> Strengthening your product strategy 2: action

>> The Product Organizational Design Patterns in a Nutshell

>> The Innovation Map – Go from a Snail to a Shark – Free Download

>> Agile User Experience in Nutshell- with a Dash of Lean UX – Free Poster


Follow us on LinkedIn for our updates >


Written by


Strategy is only as good as its ability to enable your product people to make smart decisions. It must evolve to remain fit for purpose. For those of you who want to make sure your product strategy serves your people, a collaborative approach helps you recognise and prioritise the most crucial gaps to work on.

The last post shares the product strategy health check template. Here’s one way you could work with it to align your POs, PMs, CPOs or whoever is in your product org chart. Co-creation is key to a shared commitment and conviction. Start with asking your product people to identify areas where they want more context. You can enable them a little better, each time, even if the official strategy is still in progress.

Treat it like a Kata, returning monthly or quarterly (but no less frequently) to prioritise the next biggest gap you want to close. A strategy isn’t grown in one night, so this is something that you can make more robust over time, piece by piece. Each time, gather product people to add what they know, then dot vote on which field they most need more data on to make informed decisions. Then split into pairs or small groups, choose one, and work on making it clearer before you next meet. This way, your strategy evolves over time, can gradually be strengthened, and benefits from collective effort. Don’t forget to remove old, irrelevant info as you go too. 

Written by

There are many ways businesses can organize to grow and deliver value, but not all of them are equally effective. Melissa Perri, the author of The Build Trap, acknowledges four primary organizational patterns that take very different approaches to achieve growth and value delivery, we have added a fifth pattern that is very common too, the budget-led organization.

Budget-Led Organizations

Budget-led organizations focus on long term planning and mitigate the risk of people working on the wrong thing by having everyone hand in their plans on an often yearly basis and having them reviewed and committed to. This is often a time consuming process, not only to plan, but also to follow up on how all parts of the organization are doing compared to the plan. Important metrics are often deviation from plan as well as obsession over if the work is maintenance or innovation (opex or capex). This type of internal focus gives the organization a locked focus. No matter if the target moves away, the structures are set up to make sure you stick to the obsolete plan. It does not allow new insights to impact what gets delivered and the organization cannot have customer focus nor compete on a fast moving market. Most times people in the organization spend most of their time trying to find ways to game the system to be able to have any success at all.

Sales-Led Organizations

Sales-led organizations work closely with clients to define the product roadmap, taking all of their requests, and sometimes customizing things especially for them. The challenge, however, is when it comes to scaling. Organizations with 50 to 100 customers or more cannot build everything uniquely to match the needs of each customer unless they want to become a bespoke agency. Most products delivered by sales-led organizations suffer from debts in all possible ways; product, usability and tech.

Written by

All product companies likely have a document titled Product Strategy, but do they have a real product strategy? Perhaps you’re in charge of the product strategy and want to test and strengthen it. Perhaps you’re a Product Manager feeling the consequences of a strategy that isn’t fulfilling its promise. Do you see any of these symptoms in your product company? 

  • Direct solutions coming from senior stakeholders, without space for product discovery
  • Teams and stakeholders feeling the costs of context switching, working on very different initiatives, and spread thin
  • Teams caught by surprises, needing to help other teams working on very different initiatives
  • Senior product stakeholders unhappy with PM decisions closer to the work, even if the PMs are technically making decisions that fit within the strategy
  • Slick presentations promising upcoming, unvalidated features, rather than focus on opportunities

Alignment is crucial. You can get alignment by directly reviewing decisions, Or, you can share the appropriate information and decision making framework so that others can make smart decisions without the direct oversight. To scale, product leaders can no longer rely on personally approving plans. A leader’s role is to enable their colleagues to make decisions themselves. Especially in the days of hybrid workspaces, it’s all about the flow of information. Your strategy plays a huge role in that information flow. 

Written by

In this poster, I have collected some organizational design patterns from Agile product organizations at scale. The highlighted questions might serve as an entry point to different topics, such as design principles for the organization, strategy for growing teams and individuals, how to enable autonomy and alignment and how to design the leadership teams to support and grow an awesome product organization that delivers products customers love.

Download the Product Organizational Design Patterns poster in high-resolution as PDF >

Buy printed A1 poster >

You can also download it in:

German >

Highlighted questions to reflect over in this poster

  • How do we measure success?
  • What are our guiding principles?
  • Are we optimizing for flow?
  • Are we optimizing for value?
  • What is the capability we need to scale?
  • How do we enable flow of information?
  • What is the Minimum Valuable Bureaucracy
  • What roles do we need in our leadership team?
  • How do we grow teams & individuals?
  • What type of teams do we need?
  • How do we enable both autonomy & alignment?
Written by

Agility is about adapting and delivering value. More and more organisations are discovering that they either need to get on the agile train or fall hopelessly behind. 

Many of them turn to frameworks to adapt agile ways of  working. But what they get is another framework that will sit  on top of  the others and cause more confusion and frustration. What they need is to focus on the real problems like organisation, leadership  and culture. I’m going to use SAFe as an example in this text (there are other frameworks trying to solve this out there but I know more about SAFe).

A framework with a clear hierarchical role chart, process arrows, planning cycles and new roles is a way of satisfying the controlling part of an organisation. And it is exactly this part that we need to remove, if we want to be truly agile. To dare go down the agile road you need trust from leaders and in many organisations that is the exact thing they are lacking. So their own fear of losing control drives them to turn to things their recognize, roles and hierarchy, processes and planning, things that are feeding the controlling needs and is satisfying their own fears.

When introducing a framework like SAFe you are forced to focus on roles and planning cycles instead of culture, organisation and leadership. To get the right people in these roles is not an easy task an one that is impossible if there are no people with an agile mindset in the organisation. When people without agile mindset take on these roles what we get is another gant chart and detailed planning that will not adapt to the changing needs of the customer.


Written by

When Agile becomes something for the whole organization leadership needs to adapt to support Agile values and principles. Take the opportunity to give energy and grow a leadership that supports an organization fit for the future. Let’s build an Agile Mindset that can change how leaders act in their daily activities, how they lead people and business, form organizations and governance.

Free Download of the English Agile leadership in a Nutshell poster in High resolution (PDF)

French Translation of this poster >

Portuguese Translation of this poster >

Spanish Translation of this poster >

Italian Translation of this poster >

Turkish Translation of this poster >

Buy printed A1 poster >

EDIT 2021: The poster is now updated to ver 1.2 with some improvements and better connection to transformational leadership and theory X and Y.

This poster is for me a way to visualize key concepts for how to lead with an Agile Mindset. At Dandy People we use it in our Agile coaching and training. We hope you as well can have use for it in your work. Please let us know if you have any feedback or questions on this poster.

To Lead in Complexity

The basis for Agile leadership is that we need to have a leadership that works in complexity – that support flexibility, transparency, collaboration and authonomy to enable the “workers” to make smart tactical and operative decisions to reach well defined impact goals. There are several common leadership concepts that support this kind of leadership;

  • Catalyst Leadership
  • Management 3.0
  • Systems Thinking
  • Servant Leadership

Three leadership Styles

In the poster there are three leadership styles visualized;

  • Catalyst Leadership (Best for Agile)
  • Achiever
  • Expert

The infographic contains numerous of illustrations to visualize some of the behaviours of each leadership style. I believe (without perhaps any support from research) that you can change leadership style to become a Catalyst Leader if  you make this decision, practice and work on it. I also believe that the environment we live and act in shapes how we behave and what we might see as good leadership.

Agile Mindset and what it might mean in Reality

When you understand that Agile actually is a way of thinking, a mindset, and not a process ot tools, it usually unlocks the “next level” in your game. But many leaders might find it quite difficult to put the Agile mindset to practice in reality. What does it really mean for governance? How do we build organizations, create good salary models, plan our projects, grow our staffs knowledge, build teams…? I have covered just a tiny part of that in this poster, the list could go on forever I know.

Need Coaching and Training for Agile Leadership?
Coaching Agile Leadership

If you need help to reshape the leadership in your organization to support your Agile journey, let us know and we’ll happily join forces with you to coach and train your managers and every one else who can become leaders. (more…)

Written by

Many Agile teams are struggling to connect user experience and the design process with Agile ways of working and often Scrum. In this Poster (and post) I´m trying to describe the connection, and how you can collaborate in the team to learn more about user needs and solutions to solve real user problems together. I´ve been using this poster for over a year in my combined PO and UX training (Build the Right Product – Innovation through Collaboration & Design Thinking) and in my Agile coaching.

Download the Agile User Experience in a Nutshell in high resolution (PDF) >

Download in Portuguese >

Download in Spanish >

Download in Turkish >

Buy printed A1 poster >

Agile User Experience in a Nutshell Poster

My hope is that this poster might give some guidance in how User Experience can work in an Agile setup in combination with the posters; Agile Product Ownership in a Nutshell and Agile in a Nutshell (with a spice of Lean UX).

What does UX mean?

UX stands for User Experience. Basically, the expected and needed user experience of the service or digital product to meet user and business goals. To connect user needs and business goals is basic when working with user experience, it is basic to meet users and understand who they are – and involve and understand stakeholders. Any team can work with UX as long as they get to do this, and have the methods and processes to do it in a structured and effective way. (more…)

Written by

To be able to stay focused on what really matters you need to have a clear strategy. When companies are small it is not always easy to have a clear strategy and act on it, but it is usually a lot easier than in big companies. To be able to do innovation and also stay customer focused even in big organisations a clear vision and strategy is essential. And every one in the organisation needs to understand the strategy.

There is a research done by Harvard Business School saying only 5% of the employees know about their business strategy. This is really scary for anyone running a business, and something everyone in a position to make strategic decisions needs to take really seriously. If people in the organisation don’t know about, or understand the vision or the strategy, how can they then make tactical and operational smart decisions making the business go in the right direction? There is only one answer to that question, they cant.

A Collaboration and Visualization tool to make Strategy Transparent

This fall I’ve been doing a talk around the topic “Customer Focused with an Agile Mindset” where I talk about how leaders of organizations need to grow an Agile mindset and make a strategic decision to become customer focused to be able to survive in the fast moving complex world of today, and how that can be done. The Innovation Map is one of the slides of my talk and I’ve been getting a lot of great feedback on it. Something many people feel is missing today is a holistic overview of the different strategies the organization have, and to be able to use it in their daily work making sure they are on the right track.

The Innovation Map is a great tool to be able to visualize what strategic initiatives the organisation have, or perhaps don’t have. Also it can be used to visualize the initiatives TOGETHER, ACROSS the organization. In this way when involving more people we can easier see the full picture of where we are going, and what we can do about it. By involving the people working front line with the customers knowing about their needs as well as those that can create the solutions to help the customers and not only management, you grow both an understanding of what the business strategy is – AND – you get their valuable knowledge of what the customer needs are and what can actually be possible to do or not do today and in the future. Then it will be up to management to prioritize the strategy based on different business scenarios.

Download the FREE Innovation Map Now (.pdf)

innovation map

Debt in any level will eat your business


Shopping basket
Our Trainings
Gratis frukostwebinar om postern “Inre motivation i ett nötskal”
Target Group: Nyfikna ledare, chefer, medarbetare, HR, Agila Coacher. Alla som har intresse av skapa rätt förutsättningar för sig själv och andra att växa som individer, att lättare förstå varandra och hamna i "flow" i vardagen.
Teachers: Mia Kolmodin, Desirée Rova, Frida Mangen
Online 15 februari 8.20 - 9.30