peer graded assignment story mapping

MEET US AT ATLASSIAN TEAM 24

Las Vegas | April 30 - May 2

Agile workflow

31 min read

The Ultimate Guide to User Story Mapping [2023 Guide]

Whether you’re planning your first user story mapping session or you’ve got a few under your belt, it can be a little overwhelming 🤯

• What’s the process?
• Who do I need to get involved?
• Why are we even bothering with this when we have a perfectly good backlog? (Okay… it might be slightly dysfunctional, but you know...)
• Why are there sticky notes EVERYWHERE?

Most product managers and Agile teams could benefit from a deeper understanding of user story mapping so they can create a more customer-centered view of the work that needs to be done.

Plus, over the last 15 years (since user story maps started to become a thing thanks to Jeff Patton), some of the processes and terms have evolved and there are new tools and apps that can make your life a whooooole lot easier.

We’ve put together this ultimate guide with all the info you need to get up to speed on the latest user story mapping definitions, techniques, and tools. Let’s start with some basics 👇

What is user story mapping?

Here’s a super simple user story mapping definition:.

User story mapping is a visualization of the journey a customer takes with a product, from beginning to end. It includes all the tasks they’d typically complete as part of that journey.

To expand on that, user story mapping takes all your user stories (across all your persona types) and assigns them to epics in the order that delivers the most value to the customer. From there, stories are prioritized and mapped to releases.

“User story mapping is a facilitated, curated conversation that brings everyone along for the journey. It’s an opportunity for the product manager to brain dump their insights (who is deep in this stuff day in, day out) and get it into the minds of the team who are about to deliver on it.”

What isn’t user story mapping?

While user story mapping might have a few things in common with other methods, it’s not the same as journey mapping or event storming.

User story mapping vs journey mapping

Journey mapping is a UX tool that helps teams visualize the journey a customer needs to take so they can accomplish a goal. Journey maps focus on the journey for a single persona or customer, based on the persona’s specific scenario and expectations. This is useful for aligning the team, getting them focused on the user experience, and basing decisions. Unlike user story mapping, it’s focused on the user experience and the vision for the product.

User story mapping vs event storming

Event storming involves running a workshop with key business stakeholders present. The attendees write down business events (things that happen), commands (things that trigger the events), and reactions (things that happen as a result) on sticky notes. These notes are organized sequentially to map out the business processes. Unlike user story mapping, which is focused on refining the backlog to deliver a working product for the user, event storming is more high-level and done early in the product planning process.

User story mapping for agile teams

User story maps can be useful for all agile teams, whether they’re full SAFe or Kanban, but especially if they’re working on a complex product.

User story mapping is a useful technique for agile software development teams because it can help your team deliver working software and respond to change.

This fits right in with the Agile Manifesto.

And let’s not forget the number one agile principle:

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

User story mapping puts the focus on the user, ensuring that the backlog contains stories that add real value to the customer by helping them achieve their goals.

Plus, story mapping allows your team to plan and order their work so that it delivers the highest value to customers first.

The anatomy of a user story map

User stories, epics, the backbone and story mapping - oh my! To break down the steps and processes involved in user story mapping down further, let’s define some of its moving parts.

User stories

A user story is a goal, from the user or customer’s perspective. It’s an outcome they want. It’s also the smallest unit of work in an agile framework with the purpose of articulating how a piece of work will deliver value back to the customer.

User stories usually follow the structure:

As a [persona type], I want to [action] so that [benefit].

For example:

Tip: it’s a good idea to focus on just one type of user/persona during your user story mapping session. If it’s your first session, choose your most ideal customer type and write our user stories that will deliver value to them. You can always come back to your other users in future.

Read ➡️ How to write good user stories in agile software development.

Stories can be associated with epics.

Epics have different meanings depending on who you talk to. But for the sake of this article, we’ll define epics as bigger, overarching stories or steps in the journey that contain user stories. An epic on its own isn’t small enough to become a work item or development task, but the stories it contains probably are.

For example, the epic “Sign up” might contain the following user stories:

• As a customer, I want to read the privacy policy before I sign up for my account so I can decide whether I trust the company with my details
• As a customer, I want to see a list of features and benefits on the sign-up page to remind me about what I’m signing up for
• As a customer, I want to sign up for an account using my Facebook login so I don’t have to remember my username or password
• As a customer, I want to sign up for an account using my email address so I can control access to my information
• And in this example, the next epic might be “Set up and customize my profile”.

The backbone

The backbone is the top row of your user story map. It outlines the essential capabilities the system needs to have.

Your backbone should show the customer journey or process from beginning to end, including all the high level activities the customer will complete while using your product. Depending on how you use your backbone and story map, it could be made up of epics.

The backbone is critical because it gives your team the “why” behind the journey, even if they’re just focused on a single step. It takes away ambiguity around what might lead up to that step and what might follow it, which gives important context for creating a smooth customer journey.

More on: The Anatomy of a User Story Map

Why do user story mapping?

The purpose of user story mapping is to make sure you understand the problem the customer has, and then find a solution to that problem.

You’ll know the answer to:

• Why are we building this?
• Who are we building this for?
• What value will it provide them?
• When do we expect to deliver this?

This will help align your teams, groom the backlog, and more quickly deliver a product that your customers want and need.

John Walpole explains the value of user stories beautifully:

“[There’s] one technique and tool which time and time again I’ve gone back to when I felt like a project maybe isn’t thoroughly understood by the team, or I’m worried that we’re going to end up shipping software that isn’t going to delight customers. This is my go-to technique. I believe it’s going to help you ship software that will delight your customers.”

Without user story mapping, there’s a much greater chance that your team will come up with complicated, non-customer-focused solutions to a problem.

User story mapping helps ensure the team is aligned around what problem the customer has, and how you, as a team, are going to try and solve that problem.

It will keep you focused on delivering the highest impact and greatest value pieces first, enabling you to iterate based on feedback.

Read ➡️ Why User Story Mapping

Benefits of user story mapping

“User story mapping is the best technique I’ve come across to gain shared understanding within an agile team. Alex Hennecke at Atlassian talked about being able to see the forest - instead of just the trees, right in front of him.”

There are so many benefits to user story mapping, like:

• Plan better - Seeing the user journey mapped out makes it easier for teams to see the big picture of your product and identify any risks, dependencies, and blocks ahead of time
• Greater empathy - It forces your team to see the product from your users’ perspective
• Better prioritization - Organize work into releases based on what’s most important to users and what will deliver a new or complete experience for users
• More value sooner - Frequently delivering new value to users is easier when you can order the stories based on value and map them to iterations or releases
• Realistic requirements - By breaking user stories down and visually mapping them, it’s easier to estimate work and see how all the pieces fit together
• Better collaboration - With all the upcoming work mapped out, marketing, sales, and other teams can see when you expect to ship new features and updates so they can adjust their marketing communications and sales conversations (without asking you for daily updates)

User story mapping helps your team understand the bigger picture, the why, and the end-to-end customer journey before they dive into the what and how.

Read ➡️ Understand what your customers want with agile user story maps.

The flat backlog vs user story mapping

Before we had user story mapping, we had the flat backlog. Actually, a lot of agile teams still use the flat backlog (no judgement if this is you!). So, let’s talk about what that looks like and how user story mapping has improved this practice.

Read ➡️ DEEP: The 4 Characteristics of a Good Product Backlog

What’s a flat backlog?

Essentially, it’s a to-do list. It includes all the items your team needs to do so they can provide value to your customers, ordered from most valuable to least valuable to the customer. The backlog may be split into current and future sprints to show what outputs are likely to be delivered when.

But I like our backlog!

A simple to do list might be fine if your product is simple, your team is small, and your to-do list is very short. But most products are complex, with multiple teams working on it. And most of the time, the backlog is massive (and constantly growing and changing).

Flat backlogs are complex at scale

If you’ve got hundreds of issues (or more), a flat backlog makes it impossible to see the big picture and surrounding context - which your team needs in order to refine the backlog, find dependencies, and prioritize the work into releases. It can also get pretty overwhelming!

• Specific challenges of using the flat backlog include:
• Arranging user stories in the order you’ll build them doesn’t help you explain to others what the system does
• It provides no context or ‘big picture’ around the work a team is doing
• For a new system, the flat backlog is poor at helping you determine if you’ve identified all the stories
• Release planning is difficult with a flat backlog - how do you prioritize what to build first when you’ve got an endless list?
• It’s virtually impossible to discover the ‘backbone’ of your product

User story maps were designed to overcome these challenges and restructure the backlog to add context, make it easier to prioritize, and put the focus on the customers’ needs. It introduces the X axis, with the backbone at the top to show the customer journey, and the user stories below.

When you go from a flat backlog to multiple axes, your team (and the rest of your organization) can understand what value we intend to deliver to the customer and when.

Read ➡️ The difference between a flat product backlog and a user story map.

When is user story mapping done?

So, when do you actually run a user story mapping session?

Generally, a team will collaboratively create a story map at the start of a project or product. It might be an entirely new product, or the product manager might want to pursue a new idea or feature as part of an existing product.

This involves getting subject matter experts and team members together to run a session where you look at your personas and overarching customer journey, then brainstorm ways you can provide the most value to customers. Then you’ll write user stories for each of your persona types and each step of the journey, based on their needs.

As we’ve already mentioned, it’s best to focus on one persona type per story mapping session to avoid confusion. So, start with the persona who is the best fit for your product or likely represent the largest chunk of your audience first.

Overall, the process could take several days or even several weeks, depending on the complexity of your product (and therefore, the number of steps in the customer journey) and the number of personas.

Getting the most out of User Story Mapping

Who should be involved in user story mapping.

Some folks you might invite to your user story mapping party session include your:

• Subject matter experts (whether product owner, product manager, customer support team member, or someone else who interacts with the customer)
• Business owner
• UX designer
• Facilitator or Scrum Master (it’s useful if you can get another product manager to facilitate the session)

Tip: Try to keep your numbers below 10 participants. Diverse perspectives are useful, but any more than that and it can get tricky to manage and get input from everyone. All the people present should be able to contribute insights into the personas/product/business, or help estimate how long tasks will take to complete.

Mapping the user stories

Once the backbone is established (and your team agrees on the order), you can put the flesh on it. Under each item in the backbone, go the user stories (steps, processes, and details) that support that activity. This involves some brainstorming and creative thinking.

Encourage your team to imagine the different options available to the user, how they might want to experience each step in the backbone, and actions they might take. It can't hurt to do a paper prototyping session alongside your user story map to mock up ideas as you go. Or perhaps that step will come later, depending on the scenario and maturity of your team.

Then you can put your user stories in a sequence to deliver maximum value to the customer as quickly and consistently as possible. So, put the most important user stories at the top, and the least important ones at the bottom.

Cut lines or swimlanes

Your team will get together and discuss and estimate the work involved in each user story. After that, you can add cut lines (usually sprint or version lines) to mark out what your team will deliver and when. At this point, you might shuffle some stories around if it makes sense for the user to get them in the same release.

Read ➡️ Anatomy of an agile user story map.

Tips for successful user story mapping

Involve the right people.

It can be tricky to get your team and stakeholders together. They’re busy and probably have a plate full of commitments. But it’s always worth getting everyone to set aside time and step away from the keyboard. User story mapping is important - and you’ll need input from everyone so you can:

• Brainstorm stories then prioritize and estimate them
• Get your team to commit to implementing them

Break it up

“Typically, I’d run these things to try and get as much of the planning, personas, and backbone done on day one as possible. By that point, most people are tapped out because the cognitive load is high. Then the team can go away and sleep on it. Once they’ve had time to reflect on it, they’ll come back with other ideas for user stories and thoughts about how they’d do the work before they start sequencing.”

You don’t have to do your whole user story mapping session in one go. Depending on the size, complexity, and phase of your product, you might not be able to fit it into one day, either.

Instead, break your session up into 2-3 hour chunks and do it over several days. You might do the first session in the afternoon and the next session the following morning. This comes with a few advantages:

• It means you don’t have to get your stakeholders and teams together for an extended period
• You might find it’s a lot easier to coordinate your calendars when you split your sessions up
• It gives your team time to reflect on the initial story map (they’ll probably think of a million new things to add on day two)
• Your team can get lunch after the session is done and debrief over food and drinks 🍻🍔🍕

A single facilitator

While you DO want all your team and stakeholders at your user story mapping session, you don’t want everybody driving the discussion (too many chefs in the kitchen = not a good idea). Instead choose one person to facilitate the session. Sometimes it even works better if you can choose a product manager from another team to run things.

No phones/laptops

For in-person user story mapping sessions, only your designated facilitator is allowed their device. To avoid distractions, ask folks to leave their phones and laptops in a stack at the door. That way, your team can be fully present for all discussions.

Start with data and evidence

Before you get stuck into user story mapping, bring in relevant data and supporting evidence. All of that is great context for what's to come. And of course, you can’t do user story mapping without a clear understanding of who your users are - and what their goals, objectives, problems, and needs are.

So, create your personas before you build out your customer journeys. That way, you’ll understand how your users will engage with the product, and you’ll be able to write user stories that more accurately reflect reality.

User Story Mapping Approaches

User story mapping example.

Let’s go through an example of user story mapping to help you visualize the process for your own product.

• Identify product/outcome

In this example, our product is a free online educational kids game. The outcome is for the user to find and play the game.

• List high level activities (in chronological order):
• Navigate to games website
• Log into account (or sign up if a first-time user)
• Search for game
• Choose game
• Share with a friend or on social media
• List user stories under each activity

For example, searching for a game could include the following options:

• Free text search - As a parent, I want to search for a specific keyword so I can quickly navigate to a game
• Browse by category: age group - As a parent, I want to find an age appropriate game that my kids will easily pick up
• Browse by category: type of education - As a parent, I want to find a game that will help my child improve their knowledge and skills in a specific area
• Browse by category: game type - As a parent, I want to find a new game that’s similar to one my child already likes
• Order by top rated - As a parent, I want to find a game that’s likely to keep my kid engaged for a while so I can get some work done
• Order by newest/oldest - As a parent, I want to help my child find a game they haven’t already played, to give them a new experience
• Order by most popular - As a parent, I want to help my child find and play the most popular games
• Order stories from most to least valuable to users

Value is identified from analytics on usage patterns, customer interviews, and other insights.

Your team might check feedback forms to see what parents’ top requested features are, and prioritize these first. That way, they’ll deliver more value, more quickly.

Sequence the work so you know what to deliver and when

Your team will estimate the work involved in each user story and decide what stories you can complete for upcoming sprints or releases. They may group stories that are needed to deliver an MVP, or stories that need to get released together - for example, all the “browse by category” features might go live at the same time.

Split it up over releases or sprints

The team sets your cut lines (for the sprint or version), allowing them to distinguish what they think they can deliver in that sprint/version. This will be based on their capacity and what they need to deliver to users for a minimum viable product (MVP).

A user story mapping… story

During his time at Twitter, our Co-Founder, Nicholas Muldoon, facilitated a session for another team whose goal was to figure out how they should fix an issue with the app. This example (in Nick’s words) shows another interesting application of user story mapping, including the types of issues you might work through and how you can hone in on a particular persona or subsection of your audience.

Step 1: Kick off

We started by getting everyone in the room. Attendees included several subject matter experts - not just the immediate team who were working on the project. This included someone from the user authentication team and a UX designer who had worked on password resets in the past.

The product manager kicked off the session by explaining the situation: “A whole chunk of users are having trouble getting into the app because they can’t remember their password. But in order to get them to go through the tedious password reset process, we want to give them value first to show that it’s worth doing. How?”

Step 2: Persona identification

To figure out the next steps and do user story mapping, we needed to narrow down the audience so we could use it as a framing reference or persona. After all, we were looking at a huge audience of 30 million people, not a single persona.

So we asked: who are we not targeting? Then we were able to take out any pro users and government users, which brought the audience size down to 28 million.

Next we asked: what’s the easiest place to experiment and test this? At the time, there was a feature we couldn’t access on IOS, so we went with Android. Plus, we had great relationships with the US-based phone carrier, AT&T. So we looked at our audience of Android users on AT&T in the US, which left us with a much more reasonable audience size of 3 million people.

We used this persona to experiment with this particular feature without touching all the different use cases.

Step 3: The big steps

Once we’d outlined the persona we were going to focus on, we could talk about what’s in or what’s out. So, we talked about the big steps, like:

• They’re on the Android home screen
• They open up the app
• They see all the features
• They attempt an action (Tweet, like, or retweet)
• They perform a password reset
• These customer-facing epics form the backbone of the user story map.

Plus, in this session, we also included technical epics for stuff we needed from other teams at Twitter. For example, this team didn’t control all the authentication, so they added a technical epic to have a conversation with another team to get that piece on their backlog so they had everything they needed for the experiment.

Step 4: The stories

As we fleshed out the epics, we built out the user stories below each of them.

Step 5: Cut lines

Typically, your team would do estimation and cut lines at this point, but we didn’t need to because timing was less relevant. We had to include all the essential stories to successfully run the experiment.

We did our user story mapping physically on a whiteboard, so we used tape to separate what was in and out of sprint one, two, and three. We had the backlog on the right hand side, which consisted of anything we’d discussed that we couldn’t include this time, but we wanted to come back to later. Maybe some items weren’t applicable to this persona, or we’d come back to it for IOS.

In other scenarios, we’d order the stories based on what we understood would provide the most value, estimate with story points , and then plan the capacity for a week or fortnight of work, based on historical velocity. Then we’d sequence the stories into sprint and versions. Sequencing might involve moving up something of lower customer value because you can fit it in. You might also need to break down a bigger or riskier story and split it into two user stories.

Throughout the process, everyone had the opportunity to voice their opinions (there’s nothing more frustrating than not being heard or listened to) and we’d put it on the board. One of my roles as the facilitator was to manage everyone in the room - from the quietest person to the most outgoing person.

If someone was being quiet, I’d pull them into the discussion and ask them for their thoughts directly. It’s important to pull in from different participants to get a holistic vision or understanding. Because at the end of the day, the purpose of user story mapping is to get the team on the same page. If the team sets off and they haven’t bought into the vision, they’ll soon find that everyone has a different understanding of what’s meant to happen. It’s less about the process, and much more about the alignment of the team.

As a result of this user story mapping process, the project took a new direction where the app would use the device identifier along with the username to figure out who the user was before they log in. This would allow them to get straight into the timeline so they can get value.

But if they wanted to complete any actions (like Tweet, RT, or like a Tweet), they’d need to put in a password (and would hopefully be engaged enough to complete the process). Overall, it was a very successful user story mapping session!

Physical vs digital user story mapping

So, now that you know the steps in user story mapping, how do you actually implement them?

Traditionally, user story mapping is done physically. You get your team in a room, write out the backbone and user stories on post-it notes, arrange them on a wall, and use a string to represent the cut lines or swimlanes.

It might look a bit like this:

But this process does come with some challenges:

• You’ll have to find and book a room for a day (or longer if you need to map a complex product and user journey)
• We all know that post-it notes have a tendency to lose their stickiness and fall off the wall (even if you totally nail your peeling technique)
• Even if you involve remote team members using video conferencing, it’s tricky for them to read post-its - and of course, much harder for them to contribute
• A team member will still need to enter all the data into Jira once your user story mapping session is done (it’ll look like the below screenshot, which doesn’t resemble your physical story map too much)

“When I worked at Twitter, they tried to do physical user story mapping over video conferencing to include distributed team members. It was challenging. There’d be a lot of ‘Hey Nick, what does this say?’ and I’d need to read it out or type it out on chat.”

That’s why it’s often better to use a tool or app to do your user story mapping digitally.

While there are a couple of user story mapping apps and software options, the most efficient approach is to use a user mapping tool that integrates directly with Jira.

That way, you don’t have to transfer your work into Jira - your team can move straight into working on their top priority stories as soon as you wrap up your mapping session.

Read ➡️ User Story Mapping for Remote Teams

If the last year is anything to go by, read more on: User Story Mapping for Remote Teams

Jira + Easy Agile TeamRhythm

Jira on its own doesn’t allow you to do user story mapping. It doesn’t replicate the physical session with sticky notes and an X axis. The best it can do is a flat backlog - and hopefully by now, you know that’s not good enough for most teams.

Fortunately, you can run a digital and collaborative story mapping session right inside Jira with Easy Agile TeamRhythm, which is an add-on for Jira.

Here’s how it works:

Add user story mapping capabilities to Jira

Add Easy Agile TeamRhythm to your Jira account. You can get started with a free 30-day trial.

If you open TeamRhythm from an agile board that’s already in use, it’ll automatically get populated with your board’s data, with current issues added to the backlog panel in the right hand panel. But don’t worry - you can easily edit this data. And if it’s a new agile board, you can easily add your backbone, stories, and swimlanes from scratch.

Set up your backbone

Across the top of the board you’ll create a horizontal row of epics (if you already have epics associated with your board, this will be pre-populated). Each epic represents an activity of the users flow through the product. This is often referred to as the 'backbone' of the story map.

These epics can be dragged and dropped and the order of the epics will be reflected on the backlog using Jira ranking.

Creating new epics right inside the story map is simple with Easy Agile. Simply click the “Create Epic” button in the top right of the screen. Add the name and description, then click “Create”. Scroll to the far right of your story map to find your new epic.

Don’t worry about getting everything perfect right away. You have the ability to edit them in-line later.

Add the flesh (or stories!)

Beneath each epic on the backbone, you’ll see any linked User Stories that are ordered by rank. To add a new story, hover over the space where you want to create your story and click “new”. Enter the name of your story and select your issue type from the drop-down (e.g. task, story, or bug). You can also access the Backlog panel to add existing stories or issues - simply click “existing”, search for your issue, and add it.

You can also drag issues in from the backlog panel.

And just like epics, you can edit your stories in-line by clicking on the name of the issue.

Order your epics and stories

Now, put your epics and stories in order. Your epics should reflect your customer’s journey from beginning to end. And your stories should be ordered by the value they deliver to customers.

In Easy Agile apps, you can click and drag to rearrange your stories and epics. And if you move an epic, the associated stories underneath will move with it.

Estimate work

Hover over the estimate field (the gray number on the bottom of each story item). Click to add or edit story points .

Read ➡️ Agile Estimation Techniques

Add and arrange swimlanes (version/sprint)

Now it’s time to decide what issues your team will tackle when by horizontally slicing up the work. Click on the swimlanes button in the top right. You can choose to sequence work by sprints or versions (depending on whether you’re Scrum or Kanban*). Your sprints or versions will appear in chronological order on the story map, and there’s an “add sprint” button at the bottom of the story map where your team can add additional sprints and versions.

* With Kanban, you’d typically sequence work into versions, as there is no sprint. This can help your team whittle down the long list of stories into the 'now' and 'future' buckets.

You can easily drag and drop stories, mapping them to the appropriate swimlane.

Check team velocity to avoid over committing your team during each sprint or version. Hover over the “Not started”, “In progress”, and “Done” indicators on the far right of the sprint or version swimlane to see how your story points are tracking across all the stories and issues. If you have too many story points , you can move some stories to the next sprint or version.

Read ➡️ Agile Story Points: Measure Effort Like a Pro

Try out different views

You can search or create a Quick Filter based on a text search (e.g. contains "As a parent"). Or if you’re using our other product, Easy Agile Personas, we have a tutorial on how you can create a Quick Filter by persona. That way, you can refine your story map and narrow in on what’s really important to you.

Get to work!

All changes made inside the story mapping session are automatically reflected in Jira, so your team can leave the story mapping session ready to start their work.

Get started with Easy Agile TeamRhythm

Easy Agile TeamRhythm works out of the box with your existing backlog (so getting started is super quick and simple). But it gives you that extra dimension to help bring your backlog to life. It’s aliiiiive!

Want to check it out for yourself? We have two options:

OR play around with our demo (no installation or sign-up needed) :-)

But don’t just listen to us. Here’s what some of our customers have to say:

Jira software is great for following activities and backlogs, but it’s easy to lose the vision of your product without user story mapping. Easy Agile User Story Mapping allows the teams to communicate - not only about activity but also the vision of the product. Some of our teams regularly refer to this tool for retrospectives, and it helps them make the product their product.

We’ve found that Easy Agile User Story Maps brings the team together in one room. As a result, we find ourselves mapping more as a group, which creates a common understanding. Since using the add-on, we’ve been able to speed up planning and more efficiently conduct large story mapping exercises.

Since using Easy Agile User Story Maps, we’ve improved our communication and team alignment, which has helped give us faster results.

Easy Agile User Story Maps has helped us visualize our workload and goals, as well as speed up our meetings. We love the simplicity!

See what all the fuss is about

Start your free 30 day trial

Psst: It’s the fastest growing and highest-rated story mapping app for Jira! You’re going to love it.

6 ways to keep your story map alive

Speaking of bringing things to life, we’ve got a few final tips...

Your user story map is designed to be a living, breathing thing so that it can help your team continuously deliver value to your customers. But you’ll miss out on these benefits if your team doesn't continually use it, reflect on it, and refine it.

Here are 6 ways you can keep your backlog alive:

1. Progress tracking

As your team delivers releases, they can visually track their progress against the user story map. With Easy Agile User Story Maps, updates in Jira are reflected directly in the user story map so you can check what percentage of work has been completed. This enables you to identify problems early on and adjust your team’s workload (and future versions/sprints) if needed.

2. Backlog grooming

The purpose of backlog grooming is to maintain a healthy, up-to-date product backlog, ready for efficient sprint planning. A few days before your sprint planning meeting, your product manager will:

• Delete user stories that aren’t relevant anymore
• Create new user stories as needs become clearer
• Assign and correct estimates
• Split user stories that are too big
• Rewrite stories to make them clearer
• Ensure stories are ordered by priority
• Make sure stories at the top are ready to be delivered

It’s much easier to do this using Easy Agile User Story Maps (rather than a flat backlog) because your product manager and team can see all the contextual information. They can shuffle the order around by clicking and dragging, and can quickly update issues with in-line editing.

3. Sprint/release planning

Sprint planning is done at the beginning of every sprint. It’s designed to help your team agree on a goal for the next sprint and the set of backlog items that will help them achieve it. This involves prioritizing backlog items (this should be straightforward, thanks to backlog grooming) and agreeing on what items your team has capacity for during the sprint. Sprint planning sessions tend to run a lot more smoothly when you refer to your user story map. With Easy Agile User Story Maps, you can update your story map with backlog items as you go, and all your changes are reflected in Jira so your team can start work on the sprint straight away.

4. Sprint reviews

At the end of each sprint, your team will do a sprint review to see whether the goal was achieved and that your increment led to a working, shippable product release. Your product manager will look at the “Done” items from the backlog, and the development team will demonstrate the work they’ve done.

The team talks about what went well, any problems, and how they were solved or could be solved. They review the timeline, budget, and potential capabilities for the next planned product release, which puts the gears into motion for the next backlog grooming and sprint planning session.

In Easy Agile User Story Maps, you can easily filter your view to show “done” issues, see sprint statistics, and update story point estimates. That way, you can do a quick and collaborative sprint review meeting, right inside Jira.

5. Roadmaps

You can use your story map to communicate your roadmap with stakeholders and share the product vision. With your upcoming releases and sprints mapped out, it’s easy to see which parts of the customer journey are going to see an update or improvement, and when.

6. Retrospectives

Retrospectives are often held at the end of your sprint or release. Or you might hold them after an event, presentation, every month, or every quarter. Retros are used to help your team reflect on what’s gone well, what could have gone better, and what they’d do differently next time. Your user story map can give your team a visual point of reference during retrospectives, and help them stay focused on the user.

How to learn more about user story mapping

We’re almost at the end, but don’t stop here! There’s so much more to learn if you want to go deeper with user story mapping.

Here are some resources worth looking into:

User story mapping books

Jeff Patton wrote THE book on user story mapping, called User Story Mapping: Discover the Whole Story, Build the Right Product . Jeff was the original user story mapper - at least, he’s credited with inventing the concept and practice.

User story mapping articles

Here are some articles written by us over the last few years:

Story maps - A visual tool for customer focused development (this one has a great video)

How to write good user stories in agile software development

The difference between a flat product backlog and a user story map

Anatomy of an agile user story map

That’s it! You’ve finished the user story mapping ultimate guide! 👏

You have all the tools and info you need to…

• Run your first user story mapping session
• Do story mapping more effectively (and confidently)
• Get more from your story map
• Prioritize your work to deliver maximum value to customers, as quickly and as often as possible
• Work more collaboratively
• Accurately schedule your work
• Understand the why behind the work

Go forth and story map! And let us know how you go.

If you have any questions about user story maps, we’d love to hear from you. You can contact us or send us a tweet @EasyAgile. We’ll update this guide as we come across more user story mapping tips, techniques, and frequently asked questions.

Don't forget to try

Easy Agile TeamRhythm

Online user story mapping for remote teams

Story Points: definition, how-to & why they matter

How Ubisoft fosters focused creativity with Easy Agile

Subscribe to our blog.

Keep up with the latest tips and updates.

Click one of the buttons to access our FREE PM resources >>>

Secret to Agile Story Mapping with 5 Examples

Story Mapping is an agile technique that finds itself applicable in the delivery of a new product or new feature in an already established product. Created by Jeff Patton, this method allows for a customer to visibly navigate through all of the user tasks it takes to utilize a product from the beginning till the end.

The assignment of these tasks are ordered in such a way that brings the most value to the customer. Nicholas Muldoon, the Co-Founder of Easy Agile, describes this process as “a facilitated, curated conversation” that essentially gathers everyone involved to navigate through it.

A user story mapping can be used whenever you need to create understanding of the future releases of your product while simultaneously maintaining the current state of the product vision.

• 3 C's in User Stories

The process of the agile user story map is most beneficial for agile teams. It is a useful tool in agile planning that assists in development and allows for the team to be able to receptively respond to change.  

When developing story maps, an agile team would take into consideration of the Agile Manifesto values that communicate the importance of collaborating with a customer in place of the negotiation of a contract and responding to change instead of following a plan.

These values creates the environment for the team to maintain flexibility as well as prioritizing the customer journey for a viable product. 

Flat Product Backlog vs Story Mapping

Flat product backlog is one of the most common tactics utilized in agile software development. It is essentially developed as a “to-do” list of things to cross off that will essentially bring value for a customer . It is designed with a top-down approach in mind which places the most valuable items at the top of the list with the least valuable items at the bottom.

This allows for things to be crossed off in order of priority. This differs from story mapping as story mapping contextualizes each list item into a bigger portion of the development task. Story mapping established the entire picture of a product while flat backlog simply does not.

Flat backlog makes it difficult for a product manager to make a determination of whether or not their team identified the necessary user stories. It also doesn’t give product managers the ability to explain how the system works and what it does.

User story maps creates a visual that allows for the agile development team to focus on the customer outcomes that are desirable. Agile teams are able to identify and execute a variety of features based on how each customer responds as well as track progression. This also produces less waste with improved outcomes for the entire product in contrast to flat backlog. 

Creating User Stories

One way to begin creating a user story would be to define what your goals are. The best way to initially format the user story would be to think about product interactions from this perspective: As a [type of user], I want to [action] so that [benefit]. 

A few user story examples of this would be:

• As a visitor of this site, I can type the color of the product I want in the search bar so that I can find what I’m looking for.
• As a returning visitor, I can have my previous history saved so that I can return to what I was looking for. 

According to the Jeff Patton, creating the user map in done is six steps:

• Establish your idea
• Create the big picture
• Develop a release strategy
• Develop a learning strategy
• Have a development strategy

It is important to first approach developing a backbone in your story to describe high-level tasks or high-level features from beginning to end. These steps creates the building block to producing a collaborative approach for the story map. 

Walking Skeleton

The walking skeleton is in essence the core of a user story and one of many parts that creates the entire story map. It is utilized to give a visual representation and descriptor of essential components that are required to release a valuable product.  They are stories provide a user experience with tasks that they can perform throughout the product. This particular set of stories allow for the product to be functional at the bare minimum and are interchangeably known as minimum marketable features. Combining the walking skeleton with other user persona type like the backbone and other stories underneath the walking skeleton, you will then have a full story map.

INVEST Criteria

Creating and assessing the quality of a user story in the initial story map is traditionally done through the INVEST criteria. If there is any part of a story that does not meet any of the criteria, it would be important for the story to either be readjusted or reworded. 

Independent – every user story should represent independent business values so that they can deliver those values if they were to be released alone. 

Negotiate – The method to achieving each goal should have the ability to being negotiable. Regardless of who is involved in the transaction. This could be between the product owner and the customer, or the product owner and the development team. Stakeholders can also find themselves involved in the negotiation process. 

Valuable – Each story should represent some form of value to any specific user type. 

Estimate –  There must be enough information readily available so that the story could be appropriately sized so that the plan can be properly implemented and there is commitment to completion. 

Small – Small stories are preferable for user stories so that they are able to be completed within a single sprint.

Testable – The entire team should be able to utilize precision as a means of verifying the completion of a user story. 

3 C’s in User Stories

Having an established approach in creating user stories is beneficial to this agile format. The most common approach is the Three C’s approach. This approach was coined by Ron Jeffries in Extreme Program Installed. The Three C’s specified are card, conversation and confirmation. Jeff Patton also discusses this approach in more detail at Flowcon .

Card The card portion of the Three C’s approach is essentially having a written description of a story that is utilized to plan. Having the ideas from your entire team written on a card, sticky note, or even a whiteboard launches the ability to put everything into a draft.

This is a collaborative exercise that is implemented by throwing out any information that comes to mind, including potential titles of the stories themselves. Be mindful that stories should be written in a manner that creates a statement of value and intent. This is known as user voice.

Conversation The goal of the conversation process is to discuss ideas and work together to develop solutions. It is important in this process to ask the who, what and why of a story. It is the responsibility of the product owner to answer these questions in the planning process. This is to ensure that the team as a common goal. 

Confirmation Confirming a story map gives the technical information of a story as well as confirms that the execution of a particular story is upholding its intended value. Having a unified team consensus on what is appropriate to build should also be recorded. 

Advantages and Mistakes in Agile Story Mapping

There are direct advantages of story mapping in the agile processes. Story maps allows for everyone in the development team to understand the entire construct of the application, especially the parts that finds itself to being the most difficult. This process also allows for your team to have a complete visual of the product, solving a major complaint that exists in agile teams. Teams are able to see where each part fits into the entire system. 

One additional benefits of user stories is that it assists teams in identifying what areas to develop first. If it appears when developing a website that the user journey of a website finds itself focused on a specific section of the about me page more often than other web pages, then it would be most beneficial to begin building upon it first.

It is important for product managers to be mindful of common mistakes that occur through mapping.

A common mistake that occurs in utilizing user story maps is that teams can find themselves working with a customer that is not familiar with their product. It is vital to have someone familiar so that you will have more certainty in the value that they provide when navigating. 

Not keeping the story map visible to your agile team is another mistake that appears in development. The story map is a reminder for the entire picture of an application. If it is not seen clearly and often by the team, a lot of goals can become lost in the process. 

Tools for creating agile story map

Finding the right tools is vital to creating an agile story map. Jira is considered one of the most useful tools for developing the map. Here is a list of mapping programs that integrate with Jira:

1. Easy Agile

3. StoriesOnBoard

4. Cardboard

5. FeatureMap

Skip navigation

World Leaders in Research-Based User Experience

Mapping user stories in agile.

January 24, 2021 2021-01-24

• Email article
• Share on LinkedIn
• Share on Twitter

In traditional product-development processes, teams often rely on wasteful and lengthy business requirements documents and functional design specifications to move from a vision for a digital product to outlining what it should include and how it should work. Instead of having an ongoing conversation about users, problems, ideas, and solutions, teams expect distributed documentation to suffice.

However, these documents usually fail; no one has the time or attention to read them, and even those who do read them end to end will likely come away with vastly different interpretations of what to build. Rather than propelling productivity, these heavy documents stifle creativity, communication, collaboration, and innovation from the start. As an alternative, user-story maps work much better as lightweight representations of the digital product that an Agile team intends to build.

In This Article:

User-story mapping defined, why it’s called user-story mapping, when and how to create a user story map, user-story mapping vs. customer-journey mapping, user-story maps in agile.

User-story mapping: (Also known as user-story maps, story maps, and story mapping) A lean UX-mapping method , often practiced by Agile teams, that uses sticky notes and sketches to outline the interactions that the team expects users to go through to complete their goals in a digital product.

Jeff Patton popularized the method, which replaces the lengthy, technical requirement gathering and siloed updating processes found in waterfall development. Story maps are intended to spark collaboration and conversation among Agile team members, while providing them with the bigger picture of how the digital product flows and fits together. This latter quality of story maps is important in the Agile environment, because losing sight of the product as a whole is a common challenge, likely to arise when teams work from a discrete list of user stories in a backlog.

A user-story map depicts 3 types of actions at different granularity: activities (the most general actions), steps, and details (the most specific actions). User activities and steps display horizontally across the top of the map, and the details stack vertically underneath their respective steps in priority order. To define each level of a story map, we’ll use a feature for depositing checks through a bank’s mobile application as an example:

• Activities represent the high-level tasks that users aim to complete in the digital product — for example, Check account balance or Deposit a check . Depending on the type of application or website you're creating, you may only have a few high-level activities. These can display in sequential order or in parallel if multiple paths for various user types exist. Exploratory research about top user tasks should inform this level of the map.
• Steps sit directly underneath activities and also display in sequential order. They represent the specific subtasks that users will go through in the product to complete the activity above. For example, the activity, Deposit a check can be deconstructed into the steps of Enter mobile deposit details, Sign check, Photograph check, Submit deposit, and Confirm deposit .
• Details are the third level of the story map and describe the lowest-granularity interactions that the team anticipates users will experience to complete the step above. For example, Enter username or email and Enter password appear as two separate details underneath the Log in step.

If you’re new to the concept of user stories , they are informal, natural language descriptions of features, UI elements, or tasks, written from the perspective of the user. They’re intended to get the team talking to each other about solutions in the context of end users and the benefit they’ll receive. These conversations help everyone arrive at shared understanding much faster than reading a requirements document. User stories can be written at a high level to describe a full product or feature and what it enables users to do or at low level, to outline an interface element and its value. For example:

• High-level user story: “As a checking account holder, I want to deposit a check from my mobile device , so that I don’t have to waste time going to the bank .”
• Low-level user story: “As a checking account holder, I want to save my credentials , so that I don’t have to input my username and password each time I log in . 

Agile teams commonly rely on small, high-value user stories to plan and estimate what to work on each sprint. In the user-story map, activities, steps, and details are captured as short, succinct verb phrases representing user actions. These serve as the basis for the first half of the user-story format, describing what the user needs or wants to do. The story can then be elaborated upon to include the key benefit to complete the second half of the narrative. Thus, the mapping method is called user-story mapping because it can be used to evolve the verb phrases captured on the map into fully fleshed-out user stories that can be discussed further, eventually paired with acceptance criteria, and added to the product backlog for prioritization and estimation.

Story maps can be used at any point in the product-development process to drive discussion and align the team. You can create a story map to plot the experience for a new product, after initial discovery work , or for an existing product, after usability testing . In either case, the story map begins to illustrate solutions to the problems uncovered in the research. Once created, teams will maintain and refer back to their story map over time; they add to it, modify it to reflect the actual state of the product, and use it to guide what to work on and release in subsequent sprints.

Story maps are best constructed by small teams with representatives from product, UX, development, and QA working collaboratively to discuss and shape the product plan. It’s important to establish the following context before beginning:

• User goals and needs: Outline what users are trying to do, why the product or feature(s) you are story-mapping are important, and what real problems you’re solving.
• Scope of the story map: State whether your story map will portray a current or a future iteration of the product and whether you will map an entire product, just one feature, or a section of the experience. Use caution in mapping massive products; breaking story maps up into manageable scopes and segments is often better than tackling an entire large-scale product in one story map. Being transparent about the scope of the story map upfront helps the team stay on topic and on task.
• Outcomes: Talk about what your users will be able to do as a result of launching the product or feature outlined in the map. This information will help the team maintain focus on the outcomes instead of getting too bogged down by specific solutions and tools. Focusing on outcomes also sets realistic beginning and end points for the map.

To create a story map, in-person teams use sticky notes, white boards, and open wall space; remote teams can take advantage of video conferencing and collaborative spreadsheets, presentation slides, or web-based programs. Everyone should work together on the map; no one person or role should dominate the others.

Assign differently colored sticky notes (whether real or virtual) to each row of activities, steps, and details to keep the story map visually organized. It’s also important to frame your activities, steps, and details by what the user is doing at that particular point in the product, not what the product is technically doing for the user. For example, if you were creating a digital product using artificial intelligence and machine learning, a step in the story might display as Share preferences , not Train the AI.

When I introduce user-story mapping during our UX Conference course Lean UX & Agile , practitioners often ask how it differs from customer-journey mapping . The key differences are that each map type is visualized from a different perspective and they’re used for a different purpose. A customer-journey map takes the user’s perspective, showing the steps she goes through to complete a goal, coupled with her thoughts, emotions, channels, and devices used along the way.

A user-story map takes the perspective of the product. It aims to guide the planning and implementation of features and functionality to solve users’ problems. Put simply, a user-story map connects what we uncover in customer-journey mapping to what we’re going to intentionally do about it in the product we create, beyond listing out general ideas and opportunities.

A customer-journey map can easily evolve into a user-story map by adding the activities, steps, and details. Similarly, a user-story map can morph into a customer-journey map if the users’ context, thoughts, and feelings are added. These two map types can work well when combined, but are also effective when used independently, as the research methods used to inform and create each of them are often the same.

User-story maps support the success of Agile product-development teams for several reasons:  

• Improved collaboration and team alignment. User story maps ease conversations and collaboration around what’s to be built, why, and for whom. They help everyone arrive at shared understanding and direction much more efficiently than creating and reading a 500-page document.
• Facilitating the creation and expansion of the product backlog. The second-level steps in your story map translate to epics in an Agile product backlog. An epic is a large user story that must be broken down into multiple, smaller user-stories and tasks. The third-level details in the story map are the inputs for those smaller user stories and tasks, albeit with a bit more detail and acceptance criteria added before they hit the product backlog.

• Minimum-viable-product slicing and well-informed prioritization. Story maps help teams see what their minimum-viable-product release could or should include, along with how and when to release end-to-end product increments with specific goals and outcomes in mind. Teams will often draw release lines directly on the story map, moving the details included in each release above the corresponding lines and leaving deferred details for a subsequent release below. Those deferred details, along with any new activities, steps, and details added to the map, become candidates for future sprints and releases based on what the team learns and prioritizes over time.

• Support identification of risky assumptions. Creativity can sometimes get the best of us: when we’re working with sticky notes and stories, we may add risky elements to the map — items that are not backed up by user data, aren’t technically feasible, or take our project’s budget or timeline off course. A story map helps us see where these risks exist. We can deprioritize these risky stickies in the story map and replace them with other low-risk ideas with the same value proposition. In this way, we can learn from the leaner alternative first before investing further in sophisticated or time-consuming design and development.

Story maps encourage productive, user-centered discussions about product creation, improve visibility for the backlog, and allow teams to see the bigger picture. If done properly, user-story maps reveal logical and releasable slices of product increments that meet users’ needs, while uncovering impacts and areas of risk ahead of development. This allows teams to learn early and often what works and what does not. Savvy teams use this knowledge to drive decisions about where to focus their time to maximize usability, value, and feasibility in subsequent iterations.

And finally, because Agile is all about embracing and reacting to change over following a concrete plan, story maps better facilitate efficient adaptation; it’s far easier to swap out sticky notes than it is to revise hefty requirements documents. Learn even more about how to create a user-story map, the benefits of collaborative user-story mapping, and how to use these maps in your Agile product-development practice in our Lean UX & Agile course at the UX Conference .

Patton, J., & Economy, P. (2014). User Story Mapping: Discover the Whole Story to Build the Right Product. Sebastopol: O’Reilly Media, Inc.

Related Courses

Lean ux and agile.

Applying Lean UX approaches for Agile environments

Related Topics

• Agile Agile

Learn More:

Sprint Reviews: Prioritize Your Users

Rachel Krause · 4 min

UX in Design Sprints

Anna Kaley · 3 min

Anna Kaley · 4 min

Related Articles:

Lean UX & Agile: Study Guide

Anna Kaley · 7 min

UX Mapping Methods: Study Guide

Kate Kaplan · 5 min

Tracking Research Questions, Assumptions, and Facts in Agile

Rachel Krause · 6 min

Service Blueprinting: Fails and Fixes

Alita Joyce and Sarah Gibbons · 8 min

UX Retrospectives 101

Discovery in Agile

• Learn center
• Design & UX

The importance of story mapping in Agile development

Georgina Guthrie

July 12, 2023

Story mapping is a powerful technique that helps teams visualize the user’s journey through a product or system. In the same way that you’d break a long car journey (or project) into smaller chunks, a story map allows you to break down the user’s experience into smaller, manageable pieces — called user stories .

Story mapping lets you see the big picture and the individual steps involved. It also helps you see the world through your users’ eyes, making it easier to prioritize features and spot areas for improvement. Essentially, it’s a crucial user-focused design that’s well worth your time. So let’s take a closer look!

What is story mapping?

User story maps are a visual representation of the user’s journey as they interact with your product. User story mapping is the creation of said map.

As a process, it helps you answer critical questions like ‘What are the steps users take to complete their goals?’, ‘What features are necessary to support these steps?’, and ‘How can we provide a coherent user experience?’

User story maps are specific 

To create a user story map, teams begin by identifying and defining the various user roles within the system. Each role represents a distinct category of users who share common goals and interactions. By understanding the different user perspectives, teams can better address their needs throughout the process.

Next, user stories are created to capture specific features that address user goals. These user stories serve as the building blocks of the story map. They encapsulate the ‘who,’ ‘what,’ and ‘why’ of user requirements, acting as a bridge between the user’s journey and the development tasks.

User story maps are structured 

User stories are then organized based on their sequence and priority in the user’s journey. This arrangement helps teams gain a holistic view of the product’s flow and identify any gaps or missing features. By structuring the user stories in a logical order, teams can ensure a coherent and intuitive user experience.

User story maps are flexible 

The beauty of user story mapping lies in its flexibility and adaptability. As the development progresses, the story map can evolve to accommodate changes in user requirements, emerging insights, or new discoveries, acting as a living artifact that continually informs and guides the development process.

What are the benefits of story mapping?

Underestimating the importance of understanding your users’ needs is a bad move. They’re the ones using your product or service, and if it doesn’t do what they want, they’ll jump ship faster than you can say ‘loyalty.’

This is exactly why user story mapping takes center stage. It’s an incredibly useful tool for organizations, project managers, and product owners who want to create user-centered products. Here’s why. 

A shared understanding

Story mapping fosters shared understanding amongst team members. It provides an opportunity for everyone — be it developers, designers, project managers, or stakeholders — to visually understand the product’s features and functionalities from the user’s perspective. This user-centered view keeps everyone on the same page, minimizing misunderstandings. 

Prioritization

Story mapping is a strategic tool for deciding what should be developed first. It helps you identify the most critical user stories that deliver the highest value and separate them from the ones that are not as urgent. This way, the development team can focus on high-value tasks, driving efficiency and delivering a product that resonates with users’ needs.

Traceability

One of the biggest challenges in project management is maintaining the connection between the project’s requirements and its deliverables. User story mapping solves this problem by creating a visible traceability link between the user’s needs, the development tasks, and the final product. This helps monitor progress, ensure quality, and validate the product against the original user requirements.

Enhancing communication

Story mapping serves as a common language that breaks down barriers between various roles in a project. It’s more than just a tool. When everyone sees the same map, discussions are more productive, feedback becomes more constructive, and ideas flow more freely. This enhanced communication fosters collaboration, leads to more informed decisions, and ultimately results in a better product.

Agile-friendly

In an Agile world where flexibility is key, story mapping is a sure-fire winner. It is not a static, one-time process. As the product evolves, so does the map. It allows for iterative and incremental development, aligning perfectly with agile methodologies. It also enables teams to adapt to changes, pivot when necessary, and continuously incorporate feedback, thereby fostering an environment of continuous improvement.

What’s the history of story mapping? 

Before we get into the ‘how’, let’s add some context. 

Story mapping came into its own around 2005. This happened mainly due to a man named Jeff Patton, widely recognized as the father of story mapping. He was heavily involved in the Agile community, and his work was about trying to solve a problem he noticed: projects often got too caught up in feature development, losing sight of the overall user experience.

To tackle this, Patton combined two seemingly disparate concepts: User Experience design and Agile software development. Story mapping was his way of trying to get these two worlds to understand each other a bit better. He started sharing his ideas and experiences at conferences, in blogs, and through other media channels. The Agile community quickly adopted his techniques, as they aligned well with the focus on user-centric design and iterative development.

The evolution of story mapping 

In 2008, Patton evolved the concept in a seminal article, The New User Story Backlog is a Map. This piece spelled out how teams could build a story map and use it to navigate their project. After the release of this article, the concept of story mapping took off.

When Patton published his book User Story Mapping: Discover the Whole Story, Build the Right Product in 2014, story mapping was already widely adopted in Agile development processes. His book only further fueled its popularity by providing a comprehensive guide on how to effectively use this tool.

Despite having its roots in Agile software development, the application of story mapping has since spread to many other fields. Businesses of all types have begun using story mapping as a way to better understand and navigate complex projects, from product development to marketing campaigns.

When should you use story mapping?  

Story mapping should be your go-to when starting a new project, particularly if it’s complex. Right at the start, when you’ve got a million ideas floating around, story mapping can help you visualize the important bits, ensuring nothing gets overlooked. It’s about giving your project a clear direction and ensuring everyone’s on the same page. No more “Wait, what were we supposed to do again?” moments.

Another perfect time to use story mapping is when you’re dealing with a project that needs to deliver a great user experience. With story mapping, you can record the user’s journey, piece by piece, through your product or service. Once you’ve done this, you can identify the key touchpoints and ensure they’re working to their full potential. 

Also, let’s say your project is meandering along, but things aren’t quite clicking. Maybe it’s hard to see the wood for the trees, or you’re losing sight of the big picture. Time to break out the story mapping! It’s brilliant for regaining perspective, realigning your team, and getting things back on track.

Story mapping isn’t just for large projects or teams either. Even if you’re a solo entrepreneur or working on a small project, story mapping can help you stay organized and focused. It’s like a road map guiding you toward your goals — who wouldn’t want that?

The bottom line

Story mapping is when you need a clear, visual way to plan and coordinate complex tasks. It’s your secret weapon to keep everything running smoothly and ensure you create the best user experience possible. 

How to prioritize roadmap initiatives 

Prioritizing roadmap initiatives is like figuring out which chocolate to pick from a giant box of treats. They all look so tempting, but you can’t have them all at once.

First, story mapping can help you identify your MVP, your Minimum Viable Product (the simplest version of your project that still delivers value to the user). Imagine you’re creating an app — your MVP might be as simple as logging in and performing one key action. By using a story map, you can visualize the user journey and pick out the key steps that form your MVP. It’s all about “What’s the bare minimum we need to get this show on the road?”

Next, story mapping can help you prioritize features based on user needs. Each story or task on your map is essentially a stepping stone on your user’s journey. Some of these are going to be critical. Others, while nice to have, might not be as important. Use the map to identify which features are must-haves and which ones are could-haves. 

Story mapping is also a great tool for risk assessment and mitigation. Use the map to spot potential bottlenecks or challenges in your plan. These riskier areas might need to be tackled first to ensure your project runs smoothly. 

Lastly, but definitely, not least, story mapping is a great way to ensure everyone on your team understands the project’s goals and their role in achieving them. By setting the roadmap and priorities together, everyone gets a voice, which boosts team collaboration and morale. So, it’s not just about getting the work done but about building a stronger team. 

Spike investigations  

A spike investigation is a type of user story that teams use in Agile project management when they need to explore solutions to a problem or answer tough questions that aren’t clear from the get-go. So, it’s a bit like an exploratory expedition. 

The term ‘spike’ was first used by the Extreme Programming (XP) community, but it’s now a common practice in other Agile methodologies as well.

Why are spike investigations important? Well, imagine you’re working on a project, and you encounter a roadblock. You’re not sure how to proceed or which tool to use, and the documentation doesn’t make sense. This is where a spike investigation shines. It’s like taking a pause to dig deep, find the answer, and illuminate the path forward.

The main idea of a spike investigation is not to deliver a tangible product but rather to gain the knowledge necessary to reduce the uncertainty in a project. It could involve things like proof-of-concept work, investigation of potential solutions or technologies, or even just experimenting with ideas.

Here’s how to run a spike investigation

1. Identify the knowledge gap : You’ll want to start by identifying the issue or question that needs answering. What is it that’s confusing? What knowledge do you need to move forward?

2. Define the scope and time box : Next, define what the spike investigation will cover and, importantly, how much time you’re willing to allocate. Since these investigations are exploratory, it’s easy to get carried away, so setting boundaries keeps you focused.

3. Do the research : Roll up your sleeves and dive into the investigation. This could involve reading up on new technologies, asking experts, running some tests, or creating a prototype. The idea is to gather the necessary knowledge to answer your question.

4. Document your findings : Keep a record of everything you’ve learned so far. This not only helps you remember the details; it also creates a useful resource for others who might face the same problem in the future.

5. Share your findings : Once you’ve completed your spike, it’s time to share your findings with the team. Chat about what you’ve learned and how it impacts the project. Now you’re ready to integrate this new knowledge into your user story map and plan the next steps. 

User story map examples 

Two real-world examples. 

Example 1: An e-commerce website

Imagine you’re designing a new e-commerce website. The first thing you do is establish the user’s journey, which might look something like this:

• Landing on the homepage
• Searching for a product
• Viewing product details
• Adding products to the cart
• Checking out
• Receiving the order confirmation

This journey forms the backbone of your user story map. Each step along the journey could be an ‘epic,’ and under each epic, you can identify several user stories. 

Let’s take a closer look at the ‘Searching for a product’ epic. User stories under this epic could be:

– As a user, I want to enter keywords in the search bar to find specific products.

– As a user, I want to filter products by category to narrow down my search.

– As a user, I want to sort products by price so that I can find something within my budget.

You’d do the same for all other epics, breaking them into manageable, implementable user stories.

Example 2: An online learning platform

Let’s think about an online learning platform. The user’s journey might look like this:

• Registering on the platform
• Browsing courses
• Enrolling in a course
• Taking lessons
• Completing quizzes or tests
• Receiving certificates

Again, each of these steps would be an epic in your user story map. Let’s zoom in on the ‘Enrolling in a course’ epic.

Here are a few user stories for this epic:

– As a user, I want to see a detailed course curriculum before I enroll, so I understand what I’ll learn.

– As a user, I want to preview a few lessons so I can gauge the quality of the course.

– As a user, I want to read reviews from previous students to make an informed decision.

Repeat the process for all the epics to create a comprehensive user story map.

In these examples, the user story map visualizes the user journey and breaks down the user’s interaction with the product into specific needs and goals. This helps teams prioritize their work, understand the context, and keep the user’s perspective in mind. Remember, the user story map is not a static document — it’s a tool that evolves and grows with your product and your understanding of the user. It’s a way of having a conversation about what’s best for the user and the product.

How to create a user story map

Once you’ve got your software ready, it’s time to start mapping using diagramming software . Here are the steps:

Identify your user’s journey

Start by figuring out the high-level steps that a user would take when using your product. Remember, this should be from the user’s perspective, not the system’s. Write these steps across the top of your diagram as epics. They will form the backbone of your user story map.

Break down each epic

For each epic, think about the individual tasks that the user would have to complete. These tasks become your user stories. Draw them under the relevant epic in your diagramming software. 

Prioritize the stories

Not all user stories are created equal. Some are crucial to your product, while others might be ‘nice-to-haves’. Use the software to arrange the user stories vertically, with the most important stories at the top and the least important at the bottom. This gives your team a clear sense of priority.

Add more details

For each user story, you can use the diagramming software to add notes, attachments, or even links to related tasks. This helps keep all relevant information in one place.

How to maintain a user story map

Creating a user story map is just the first step, though; the real magic comes in maintaining it. 

Iterate and evolve

User story maps are not set in stone. They should evolve as your understanding of the user deepens, and as your product grows. Don’t be afraid to add, remove, or move stories around.

Keep it visible

The power of a user story map comes from its visibility. Make sure your map is accessible to everyone on the team, and use the software to update it in real time. 

Use it for planning

User story maps can be a great tool for planning your sprints or releases. You can use the software to highlight the stories you plan to work on next, assign tasks to team members, and track progress.

Final thoughts

A user story map is more than just a diagram. It’s a conversation tool. It helps your team keep the user’s journey in focus, understand their needs, and prioritize work that delivers value. 

By visually organizing user stories, prioritizing features, and identifying dependencies, story mapping empowers teams to focus on delivering value to end users by creating a shared understanding of the product vision and breaking it down into actionable and manageable increments.

With its ability to adapt to evolving requirements and facilitate iterative development, story mapping is an invaluable tool for Agile teams seeking to deliver high-quality software that meets user needs and drives business success.

Your introduction to Agile and Scrum

Never include visuals in wireframes; here’s why

Subscribe to our newsletter.

Learn with Nulab to bring your best ideas to life

Story Mapping, Visual Way of Building Product Backlog

One of the key objectives of a project inception is to collect requirements collaboratively. But, many times, it is difficult to decide where to start and what to focus on. Story mapping is an engaging activity where all participants are involved in the process of building the product backlog on a wall, versus writing a dull 100-page requirement document. 

Story mapping was invented by Jeff Patton and introduced to me by Chirag Doshi and I find it very effective and useful tool to capture requirements during inception.

Building a story map

Story mapping is a top-down approach of requirement gathering and is represented as a tree. Story mapping starts from an overarching vision. A vision is achieved via goals. Goals are reached by completing activities. And to complete an activity, users needs to perform tasks. And these tasks can be transformed into user stories for software development.

Story Map Structure: Goals > Activities > Tasks > Stories

Lets take an example of an online store application’s one of the goal ‘Find product’ and build a branch of a story map to understand it better,

To achieve goal ‘Find product’ there are multiple ways such as ‘Browse through product category tree’, ‘Free text search’, ‘Promoted products’. Lets take one approach  ‘Browse through product category tree’ to build our story map,

now to complete activity of reaching a required product, user needs to do perform certain tasks,

now this tasks can be converted to user stories for software development,

like this continue to deep dive each branch of the story map starting from goals and build the whole story map. In my experience building full story map takes from 3 days to 2 weeks based on project size and complexity. 

For your reference, here is a sample branch of story map from real project,

and full story map after 5 days of activities looked like following,

Now we learned how to build story map, lets look at the advantages of it.

Advantages of story mapping

• Visual presentation of the product backlog (big picture) brings all the stakeholders on same page, in terms of  scope and complexity. It also indirectly provides a view of project size.
• Requirements captured in a physical format fosters collaboration and builds shared understanding.
• Since inception is usually a time boxed activity, the story map approach helps to deep dive and focus on important features of the application. Marking ‘nice to have’ features as ‘out of scope’ during deep dive sessions, helps the team save time.
• Interestingly, having all stories laid out on the wall assists the team to perform relative sizing of the stories quickly.
• Story map structure helps with prioritisation and allows for easy slicing of the backlog into releases and carve out MVP. Slicing can be done vertically or horizontally, such as few features or more features with MVP in each feature.
• Story map can be transformed to agile project management tools like Mingle as product backlog.

Enrich story map with more information

Sometime we need more information to be captured with story map e.g. nice to have stories, follow up questions, alternative approaches... This is like enriching the story map with more information. Following are few of the use cases of same,

• Use different colors to represent different levels in story map e.g. Orange for Goals, Blue for Features, Green for Epics and Yellow for Stories.
• Put wireframe next to the relevant area of story map.
• Marking out of scope features are important for shared understanding
• Identifying alternatives help to capture rich user experience and low cost alternative solutions
• Use small sticky to capture notes, assumption, follow-ups or questions

Alternative ways of structuring story map

In story mapping, defining a structure is important and then refine it as needed. The objective is to start with some structure in mind and evolve from it. Sometime it takes 2-3 iteration to get the structure right. 

One alternative structure is based on ‘User Journeys’. User driven approach helps to identify requirements from user perspective e.g. buyer, seller, administrator etc. The map is then structured as User > Goals > User Journeys > Actions > Stories . 

Another alternative, especially useful for NFRs (non-functional requirements) can use:  NFR > Requirement > Story .

Large projects may require up to 6 levels in a story map. However for smaller projects,  3 levels are usually sufficient.

Preparing for story mapping exercise

Now that you are convinced about using story map for your next gig, lets look at what you need to get ready for the activity:

• A large Conference room with empty wall space for full duration of inception. 
• Different color stickers, one for each level. 
• Thick marker pens (1.5mm thick permanent marker) 10+ nos - to read stickies from far.
• Stickers (dots or stars) - to enrich story map with more information.
• Use magic charts/whiteboard in case walls are not a good surface for stickies.
• A good camera to take photos of the wall.

While doing story mapping I ran into challenges and found ways to overcome those. Following are tips to avoid those traps and help you run the story mapping successfully. 

• Story mapping is a discovery phase for products requirements, follow principal of capturing everything with alternatives to avoid long running discussions. 
• Prioritise deep dives frequently to avoid spending time on less relevant topics.
• Tidy up and rearrange stickies frequently before it grows big and becomes very difficult to manage. Keep good walking space near walls. e.g. NFR story map wall photo shown above :-)
• While working with stickies, remember to remove stickies carefully to avoid folds, so it stays on the wall for the whole duration of the activity, and is readable in photographs.

Story mapping is an effective inception tool to create a product backlog in a visually structured way. It helps in building a shared understanding, identify gaps in the backlog, see interdependencies, perform better relative sizing. Further, it can also help in slicing and release planning activities.

• Book User Story Mapping by Jeff Patton
• Read more on capturing non-functional requirements using story map

Many thanks to Gurpreet for review and valuable feedback.

If you have tried story mapping on your project, please share your learnings, thoughts, photos using comments.

Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.

Related Blogs

Keep up to date with our latest insights

Navigation Menu

Search code, repositories, users, issues, pull requests..., provide feedback.

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly.

To see all available qualifiers, see our documentation .

peer-graded-assignment

Here are 6 public repositories matching this topic..., akash-goyal-github / coursera_user_experience_course.

Introduction to User Experience Principles and Processes by University of Michigan:100::boom:

• Updated Apr 9, 2020

i-asimkhan / google-project-managment-specialization

This repository lists the material of project managment courses of Google Project Managment Specialization.

• Updated Sep 8, 2022

marmello77 / FARS

Coursera's Peer-graded Assignment: Building an R Package.

• Updated Nov 4, 2020

honlimwong / final-project-html5

• Updated Dec 7, 2021

Dhanush-S-Gowda / module2-solution

Welcome to Module 2 Peer-graded Assignment for the "HTML CSS and JavaScript" course offered by Johns Hopkins University on Coursera.

• Updated Jan 28, 2024

Yashmenaria1 / IBM-AI-ENGINEERING-COURSERA

PEER GRADED AND GRADED ASSIGNMENT

• Updated Nov 4, 2023
• Jupyter Notebook

Improve this page

Add a description, image, and links to the peer-graded-assignment topic page so that developers can more easily learn about it.

Curate this topic

Add this topic to your repo

To associate your repository with the peer-graded-assignment topic, visit your repo's landing page and select "manage topics."

Help Articles

Submit peer reviewed assignments, learner help center nov 29, 2023 • knowledge, article details.

When you submit a peer-reviewed assignment, other learners in the course will review your work and submit feedback . 

You'll also need to give feedback to other learners. Your grade might be affected if you don't give feedback.

If you're having trouble with a peer reviewed assignment, check our troubleshooting page .

Steps to submit

To submit a peer reviewed assignment:

• Open the course you want to submit an assignment for.
• Click the Grades tab.
• Choose the assignment you want to submit work for.
• Read the instructions, then click My submission to submit your assignment.
• To save a draft of your assignment, click Save draft .
• To see what your saved assignment will look like when you submit it, click Preview .
• Before you submit, ensure the assignment is above the minimum word count. The default minimum is five words, but a course may have a unique minimum set.
• To make changes to your saved assignment, click Edit .
• To submit your assignment for peer review, click Submit for review .

By submitting a peer reviewed assignment, you confirm that you understand and will follow our privacy policies about peer reviewed work.

When will I receive feedback from my peers?

You'll receive a grade on your assignment within 7-10 days, as long as you've received at least one peer review.

When you get feedback, you may see the name of the learner who gave it. If your instructor has anonymous feedback turned on, you’ll see a notice at the top of the feedback for the assignment.

I can’t submit my assignment

If you can’t submit your assignment, make sure that your answers are all over the minimum word limit.

You may not be able to submit your assignment if your answers are too similar to another learner’s submission. Please keep in mind that plagiarism is against the Coursera Honor Code. 

If you see a notification letting you know that your assignment answers are similar to another learner’s submission, you’ll need to update your response before submitting. 

Once you’ve updated your answers with original work, the Submit for review button will appear.

If you need more time to work on your assignment, you can click Save draft and come back to it later.

If you think you shouldn’t be seeing this error, you can click the link below the notification to let us know. You’ll be able to submit your assignment after you edit your answers.

If you aren’t seeing any error messages, but are still not able to submit your assignment, try these troubleshooting steps.

Back to top

Attempt limits

Some private courses (such as courses in a Degree or MasterTrack program) may have a limit on how many times you can submit a peer-reviewed assignment.

If there's an attempt limit for your assignment, you'll see an 'Attempts' section listed near the top of the page when you open the assignment.

If you meet the attempt limit and need help with your grade, you can reach out to your program support team. You can find your dedicated support email address in the onboarding course for your program.

Save your work as a draft

If you want to start working on an assignment but you don't want to submit it yet, you can save it as a draft. When you save an assignment as a draft:

• You can work on your saved draft from any computer or device if you log in with your Coursera account.
• No one will be able to see or review your work until you submit it.
• You can save a draft as many times as you want before submitting it.

To save an assignment as a draft, click  Save draft when you're working on it.

Related Articles

• Number of Views 216.52K
• Number of Views 60.57K
• Number of Views 280.08K
• Number of Views 187.59K
• Number of Views 117.85K

© 2021 Coursera Inc. All rights reserved.

An official website of the United States government

The .gov means it’s official. Federal government websites often end in .gov or .mil. Before sharing sensitive information, make sure you’re on a federal government site.

The site is secure. The https:// ensures that you are connecting to the official website and that any information you provide is encrypted and transmitted securely.

• Publications
• Account settings

Preview improvements coming to the PMC website in October 2024. Learn More or Try it out now .

• Advanced Search
• Journal List
• HHS Author Manuscripts

A Story Mapping Intervention to Improve Narrative Comprehension Deficits in Adolescents with ADHD

Karen j. derefinko.

University of Kentucky

Angela Hayden

Margaret h. sibley.

Florida International University

Jake Duvall

Richard milich, elizabeth p. lorch.

The current study examined the effects of an 8-week Story Mapping Intervention (SMI) to improve narrative comprehension in adolescents with ADHD. Thirty 12 – 16 year-old adolescents with ADHD who were participating in a summer treatment program for adolescents with ADHD received the SMI instruction ten times and completed SMI homework ten times in a structured environment with teacher feedback. Recall of fables and story creation were assessed before and after the SMI. At post-test, fable recalls included more of the most important events, were more coherent, and included a greater number of plausible inferences than pre-test fable recalls. SMI homework scores accounted for increases in recall of important events and plausible inferences, suggesting that consistent practice and feedback with story mapping could contribute to important recall gains. In contrast, the inclusion of goal-based events and the rated coherence of created stories did not improve, suggesting that more explicit instruction in applying story mapping to story creation may be required.

ADHD is one of the most commonly diagnosed childhood behavioral disorders with prevalence rates as high as 10% ( Barkley, 2006 ). It is well documented that children with ADHD have academic difficulties, and that these difficulties are compounded over time ( Barbaresi, Katusic, Colligan, Weaver, & Jacobsen, 2007 ; Kent et al., 2011 ; Loe & Feldman, 2007 ). In middle school, individuals with ADHD experience substantially more academic impairment than their peers ( Molina et al., 2009 ; Schultz, Evans, & Serpell, 2009 ), and by high school, students with ADHD display lower grade point averages (GPAs), are placed in more remedial classes, are more likely to fail classes, and are more likely to drop out of school ( Barkley, Fischer, Smallish, & Fletcher, 2006 ; Kent et al., 2011 ). These findings are consistent with those found in other longitudinal studies that report grim academic outcomes for secondary school students with ADHD ( Barbaresi et al., 2007 ; Barkley et al., 2006 ), and these problems are likely contributors to employment issues that arise later in adulthood (Kuriyan et al., 2013). Because these academic problems do not appear to self-correct over time and have long-term consequences, intervention for specific academic deficits could be of tremendous benefit for adolescents with ADHD.

Children and adolescents with ADHD exhibit a broad range of academic difficulties, but a notable problem area is narrative comprehension ( Flory et al., 2006 ; Lorch, Berthiaume, Milich, & van den Broek, 2007 ). Narrative comprehension represents a skill set believed to underlie broad academic functioning relevant to later academic progress, above and beyond other traditional indicators such as word identification, semantic, and syntactic skills ( Feagans & Applebaum, 1986 ; Kendeou et al. 2005 ). Major theories of narrative comprehension point to skills needed to construct a coherent story representation. For example, story grammar theory ( Mandler & Johnson, 1977 ; Stein & Glenn, 1979 ) defines categories of story events according to the major role of each event in the story. Of particular importance from this point of view are a principal character’s goals (G), attempts to achieve goals (A), and outcomes of these attempts (O). Linking goals, attempts, and outcomes into GAO sequences is critical to building a coherent representation of story events, whether the task is to recall, narrate, or create a story. The causal network model ( Trabasso & van den Broek, 1985 ; Trabasso, van den Broek, & Suh, 1989 ) incorporates story grammar theory’s definition of events but also stresses the causal connections that link antecedent and consequent events. Understanding causal connections between story events is critical to creating an organized representation of a story and in guiding recall of important events. Development of skills in the construction of coherent story representations provides a basis for later comprehension of more complex information and organized writing skills ( Low & Durkin, 1998 ), both undoubtedly necessary for secondary school success.

Youth with ADHD exhibit several related, but distinct deficits in skills implied by these narrative comprehension models, including (1) difficulty making causal connections among story events, (2) difficulty using goal structure to create a coherent story, (3) difficulty identifying important events to guide recall, and (4) difficulty generating inferences ( Lorch et al., 2007 ). Importantly, youth with ADHD often do not differ from comparison peers when recalling discrete, factual story events, but consistently perform more poorly than comparison peers when answering questions testing understanding of causal relations (i.e., ‘why’ questions; Lorch et al., 1999 ; Lorch et al., 2000 ; Lorch et al., 2004 ). Relatedly, youth with ADHD have shown specific deficits in incorporating and maintaining a goal plan across a variety of storytelling procedures including telling a story (with and without prompts), narrating a wordless picture book, and recalling a story that they have previously heard or read ( Derefinko, Bailey, Lorch, Milich, & Riley, 2009 ; Flory et al., 2006 ; Renz et al., 2003 ). Difficulties understanding causal connections and maintaining goal plans suggest that youth with ADHD construct less coherent story representations whether creating or recalling a story.

Perhaps due to deficits in understanding causal connections and goal structure, youth with ADHD also demonstrate problems in identifying important information within a narrative. Given that goals and events with many causal connections are likely to be important to a narrative ( Trabasso & Sperry, 1985 ), it is not surprising that youth with ADHD are less sensitive to the importance of information than comparison peers. When recalling stories, recall generally increases as event importance increases, but this effect is smaller for individuals with ADHD ( Flake, Lorch & Milich, 2007 ). Unfortunately, these deficits are not eliminated with development ( Lorch, Milich, Flake, Ohlendorf, & Little, 2010 ), and may last into adulthood.

Finally, effective narrative comprehension requires the generation of reasonable inferences. Goals and causal connections between events often are not explicitly stated in stories, but must be inferred from story events ( Thurlow & van den Broek, 1997 ). Although inference generation among adolescents with ADHD has not been studied extensively, recent work suggests that children with ADHD produce fewer inferences that plausibly explain story events but produce more implausible or erroneous inferences ( Berthiaume, Lorch, & Milich, 2010 ). These findings suggest that youth with ADHD struggle to make implicit connections among story events that are vital to the construction of a complete and coherent story representation.

Intervention Strategies

Given the documented deficits in narrative comprehension, it is important to develop intervention strategies to remedy such deficits for individuals with ADHD. However, much research to date has failed to yield promising results in addressing a variety of academic difficulties. Given the frequency with which it is prescribed, the treatment efficacy of stimulant medication in particular has been investigated extensively in youth with ADHD ( Barkley, 2006 ; Loe & Feldman, 2007 ). Although many treatment studies have suggested that stimulant medication is successful in improving basic academic functioning, such as reducing disruptive behavior, increasing homework completion, and improving quiz grades ( Evans et al., 2001 ; Pelham et al., 2013 ), longitudinal research has shown that such treatment does not improve academic performance in the long-term ( Barkley, 2006 ; Langberg & Becker, 2012 ).

Three studies have examined the effects of stimulant medication on narrative comprehension and production. Two focused on the effects of stimulant medication on story recall. Francis, Fine, and Tannock (2001) asked 50 children with ADHD to retell stories from memory both on and off stimulant medication. Although children showed some improvement in including the story grammar categories of story characters’ internal responses and attempts, stimulants did not improve overall story recall length or accuracy of responses to comprehension questions. In another study of the effects of stimulant medication on free recall of children with ADHD ( Bailey, Derefinko, Milich, Lorch, & Metze, 2011 ), stimulant medication was associated with increases in the number of events recalled, but had no significant effect on recall of events central to the stories or on the coherence of recalls. A third study ( Derefinko et al., 2009 ) minimized memory demands by investigating the effects of stimulant medication on the inclusion of goal-based story events as children narrated wordless picture books. Children produced a larger number of clauses in the medication condition than in the placebo condition, but there was no significant effect of medication on the inclusion of goal-based story events. Taken together, these studies indicate that stimulant medication leads to little improvement in complex narrative comprehension and production.

A second general approach often employed to improve academic performance for children and adolescents with ADHD is instruction on improving organization of ideas through strategic studying, note-taking, and essay construction. Children with ADHD have difficulty organizing ideas into a coherent representation without instruction, even when given time to study and common study aids to help them (i.e., a highlighter, a piece of paper and a pen; Lorch et al., 2004 ). Approaches that do provide these children with instruction on organizing information into a coherent representation are not necessarily effective at addressing the deficits specific to comprehension in youth with ADHD. Children who were instructed on the Directed Note-taking Activity (DNA) procedure by Evans, Pelham, and Grudberg (1995) learned how notes should be organized using a format that stressed main ideas. Although adolescents were able to record over 80% of details from a lecture with the DNA instruction, they did not improve in identifying main ideas. One organizational technique that has been utilized successfully to address deficits associated with organizing thoughts into coherent writing is a technique described as self-regulated strategy development (SRSD; Harris & Graham, 1996 ). SRSD utilizes “instructional strategies” to addresses three deficits that may contribute to writing issues with ADHD, including goal-setting issues, poor self-regulation, and working memory deficits. Children and adolescents with ADHD have shown improvement with this procedure (e.g., Jacobsen & Reid, 2010 ; De La Paz, 2001 ). However, few studies have examined the use of SRSD as a stand-alone strategy to improve writing in individuals with ADHD.

Story Maps as a Potential Intervention

It appears that common treatment methods such as stimulant medication, practicing traditional study skills, and broad organizational strategies do not address the narrative comprehension deficits identified in youth with ADHD. However, these treatments were not designed to address these specific deficits. One treatment method, instruction in using the “story map” to guide the construction of a story representation, has been used successfully to address comprehension deficits in single-case design studies, as well as serving as a component of larger-scale interventions with youth with ADHD ( DuPaul et al., 2006 ; Jitendra et al., 2007 ). Story maps are visual-spatial displays that can be used during instruction to guide attention to important components of narratives using a specific structure ( Boulineau, Fore, Hagan- Burke, & Burke, 2004 ). The map provides readers with a space to record important story grammar categories including: Setting, characters, problem, goals, actions, outcome, and conclusion of the story. The purpose of instruction with a story map is to improve narrative comprehension by helping students to understand the structure of a coherent story representation, with emphasis on the causal connections between characters’ goals, their attempts to achieve goals, and the outcomes of those attempts ( Boulineau et al., 2004 ).

As mentioned, story maps have been effective for struggling readers in both single-technique intervention studies focusing on story mapping, as well as studies examining the combined effects of multiple techniques. In two studies that examined the effect of interventions focusing on story mapping, Idol and Croll (1987) and Boulineau et al. (2004) explicitly instructed struggling readers on story grammar categories and story structure using story maps. Students in both studies received extensive feedback from teachers on correct identification of story grammar elements through story map completion. Participants in Idol and Croll (1987) showed improved comprehension, and most maintained comprehension gains when story maps were removed. Students in Bolineau et al. (2004) improved in the identification of story grammar elements from pre-test to post-test, and accuracy of identification was maintained after removal of instruction. These studies suggest that interventions that focus on story-mapping as a technique may effectively improve comprehension. DuPaul and colleagues (2006) and Jitendra and colleagues (2007) utilized a story mapping technique as one available component among multiple components of a reading intervention package in large scale, long-term, academic intervention studies for children with ADHD. Both studies found evidence of improved comprehension for these struggling readers, although the unique contribution of story mapping instruction cannot be determined. As a whole, these studies suggest that instruction in the use of story maps is a promising technique for improving knowledge of story structure and potentially of narrative comprehension and production.

Current Study

Although improvements among children with learning disabilities as a function of instruction in use of story maps are promising, and story maps have been utilized as one component of multifaceted intervention packages for children with ADHD ( DuPaul et al., 2006 ), use of the story map in instruction to address narrative comprehension deficits has yet to be tested as a specific intervention in individuals with ADHD. The current study investigated the use of a Story Mapping Intervention (SMI) to improve the narrative recall and production of adolescents with ADHD. Utilizing a pre-post test research design, we sought to explore whether the use of the SMI would improve areas of comprehension previously shown to be deficient in youth with ADHD, including using goal structure to create or recall important events, generating or recalling coherent stories, and generating plausible inferences based upon story events. The SMI was designed to target the skills thought to underlie effective narrative comprehension and the construction of a coherent story representation, including attention to characters’ goals and the causal connections linking goals, attempts, and outcomes. This intervention was implemented in a group setting ten times over the course of an 8-week summer program. Both before and after the SMI intervention, recall of audiotaped fables and adolescents’ independent creation of novel stories was assessed. Given the focus of the SMI on the goal structure of stories and the connections among important events, we evaluated if adolescents with ADHD would show post-test improvement in recalling important events from the fable, in the global coherence of the fable recall, and in generation of two types of plausible inferences based upon story events. Similarly, for story creation we examined whether adolescents would show post-test improvement in the length of stories created, in the inclusion of goal-based story grammar events, and in the global coherence of stories created. Assuming that extensive practice in story mapping would be important ( Boulineau et al., 2004 ; DuPaul et al., 2006 ; Idol & Croll, 1987 ), we evaluated whether story map homework completion would account for any improvements.

Participants

Participants were 30 adolescents with ADHD between the ages of 12 and 16 years old. The adolescents participated in the Summer Treatment Program-Adolescent (STP-A) at a large university clinic. Participants were required to (a) meet DSM-IV-TR (APA, 2000) diagnostic criteria for ADHD, (b) be at least 12 years of age, (c) have a Verbal IQ higher than 80, and (d) have no conditions that precluded full participation in the STP-A activities. Demographic information is included in Table 1 . The STP-A is an intensive behavioral day treatment program for adolescents with ADHD that includes an active parent involvement component ( Sibley et al. 2011 ; Smith et al. 1998 ). During the STP-A, adolescents receive over 300 hours of treatment focused on improving skills in academic, social, and family domains. In addition, parents participate in 15 hours of behavior management training, 8-weeks of daily practice implementing a home behavioral contract, and ongoing daily support from a trained clinician. The STP-A shows evidence of improving the social behavior and academic functioning of adolescents with ADHD ( Sibley et al., 2011 , 2012 ).

Demographic information

Note. N = 30. WASI = Wechsler Abbreviated Scale of Intelligence WIAT = Wechsler Individual Achievement Test 3 rd edition. DBD = Disruptive Behavior Disorder rating scale. ADHD = Attention-Deficit Hyperactivity Disorder. ODD = Oppositional Defiant Disorder. CD = Conduct Disorder.

Parents and teachers of adolescents completed an application that contained behavioral rating scales, a demographic questionnaire, and a treatment history form. Parents also were administered the Disruptive Behavior Disorders Interview (DBD; Pelham et al., 1992a ), a semi-structured interview with supplemental probes for symptom severity and situational variability. Through dual clinician review, participants were accepted to the STP-A if parent and teacher reports indicated the presence of clinically significant symptoms (assessed by the Disruptive Behavior Disorder Rating Scale; Pelham et al., 1992b ) and cross-situational impairment (assessed by Impairment Rating Scale; Fabiano et al., 2006 ) consistent with a diagnosis of ADHD. Adolescents were administered the Wechsler Abbreviated Scale of Intelligence (WASI; Weschler, 1999) to obtain an estimated IQ score and the Word Reading, Spelling, and Mathematics subtests of the Wechsler Individual Achievement Test-II ( Wechsler, 2002 ) to assess achievement. Adolescents were excluded from the program if they qualified for a diagnosis of pervasive developmental disorder, or a psychotic disorder. Parents signed informed consent and adolescents signed youth assent forms prior to treatment.

One fable, The Knight and the Dragon , was read to the adolescents and recalled during the pre-test and a second fable, Silly Richard , was read to the adolescents and recalled during the post-test. The two fables had been used in previous studies for which each fable had been parsed by trained coders into individual story events. Initial agreement between the coders regarding division of units was 94%; disagreements were revised by consensus to determine the final set of events. Thirty-four adults then rated the importance of events from each fable using a 7-point Likert scale ranging from 1 (not important to the overall meaning of the story) to 7 (extremely important to the overall meaning of the story; Flake et al., 2007 ). The average ratings were converted to quartiles for each fable, constituting four levels of importance of events. Both fables include a main character who has multiple failed attempts at trying to reach a goal before actually achieving the goal. Silly Richard is 618 words long and contains 84 story events. This story concerns a young boy who wants to buy a skateboard. His mother tells him that he has to earn the money. Richard goes through a number of failed attempts before earning enough money. The Knight and the Dragon contains 640 words and contains 85 story events. This story is about a king who asks a knight to protect his people from a dragon that lives on a mountain. The knight encounters obstacles on his way to the dragon’s cave, but the problem is resolved when the dragon later helps the knight and accompanies him to the kingdom.

The story map was used as a concrete organizational aid during instruction, and helped to focus adolescents on important story grammar categories with a particular emphasis on goal structure. Blank spaces of the story map included Title, Setting, Characters, Outcome, and Vocabulary. Of particular importance during instruction were the blank spaces for goal structure elements, including the Major Goal, Problem, Sub-goals, Attempts, and Outcomes (see Appendix A ).

All procedures were approved by the university Institutional Review Board. The STP-A is an 8-week intensive summer treatment program for adolescents with ADHD. The program is fully described in a manual available from the authors ( Pelham et al., 2012 ). Adolescents attended the program from 8:00 am to 5:00 pm each day and participated in modules designed to mimic a secondary school setting. The STP-A teaches academic and organizational skills that are relevant to secondary school (i.e., note-taking, study skills, writing skills, daily planner use, binder organization) to foster generalization of therapeutic gains. STP-A modules also include daily jobs, substance use prevention (i.e., Life Skills Training; Botvin, 2004 ), and leadership training to teach life skills and prevent maladaptive outcomes such as deviant peer affiliation, substance use, and delinquency. The STP-A behavioral feedback system is sensitive to adolescent social norms. Because ADHD is a heterogeneous disorder, individualized treatment plans and adjunct treatments are used as needed to customize treatment to the unique deficits of each participant. Adolescents were in groups of 9 to 11 similar age peers and each group was staffed by a graduate student counselor and three undergraduate counselors. To promote treatment fidelity, staff members received 60 hours of pre-service training and were required to pass a STP-A procedural test. Staff were supervised by Ph.D.-level mental health professionals and trained fidelity observers. Supervisors and fidelity observers completed standardized dichotomous fidelity checklists and provided daily feedback about adherence to manualized procedures. Across treatment fidelity checklists, average fidelity scores were above 90%. Staff were also required to complete weekly treatment fidelity quizzes on STP-A procedures. If any score on a treatment fidelity checklist or weekly quiz was below 100 %, it was immediately addressed with remedial procedures.

Pre-test/ Post-test

Adolescents completed pre-test measures on the first day of the program before any instruction occurred, and post-test measures on the final day at the beginning of the Writing class. Pre- and post-test measures consisted of a fable recall task and a story creation task. During both the pre-test and post-test sessions, all adolescents listened to the same fable (pre-test was The Knight and the Dragon and post-test was Silly Richard ) and were instructed to write down what they remembered from beginning to end after the fable was read.

For the story creation task, adolescents were instructed to make up a story that they had never heard before within a 15-minute time limit. They were also instructed to write “The End” when finished. If the adolescent did not have any information written down within the first minute, the teacher would advise the adolescent to write down whatever they had thought up.

Intervention

The Story Mapping Intervention (SMI) took place during the Writing class in the academic portion of the STP-A. The SMI was explained to adolescents at the beginning of the course by the Writing teacher. The Writing teacher was a recruited from the local school system based upon experience in a mental health-related area. She was supervised by a Ph.D.-level mental health professional who attended every class period, completed standardized dichotomous fidelity checklists, and provided daily feedback about adherence to manualized procedures. Fidelity to the story mapping intervention averaged over 95%, and on the rare occasion that the teacher did not complete instruction on an aspect of the story map, the supervisor brought this to her attention immediately so that treatment integrity was maintained.

In the first class, the teacher began by asking adolescents to identify elements of a good story (e.g., organization, setting, characters, plot) and then introduced the story map. The teacher asked the adolescents to suggest definitions for each concept on the story map, with corrections made as necessary. The teacher then guided the adolescents in filling in the story map and using the story map to organize a summary of events, using the Introduction to the collection of stories that served as the material for the class. On later days, the teacher continued to guide the students in filling in story maps and correcting those they had completed as homework (see below). During this instruction, the teacher emphasized identification of the central character’s goals, the attempts motivated by those goals, and outcomes that followed from the attempts.

Story map homework was assigned during every other Writing class (10 total homework assignments). Time to complete homework was provided during camp hours under counselor supervision in a study hall to increase task adherence and concentration. The homework required adolescents to read a designated chapter from the book ADHD and Me: What I Learned from Lighting Fires at the Dinner Table ( Taylor, 2007 ), followed by the completion of a story map. Homework was turned in during the next Writing Class. Students who completed an entire story map accurately received a grade of “1”, those who attempted the story map, but did not complete at least 50% of it (or completed a section of it incorrectly) received a grade of “1/2”, and those who did not make an attempt to complete the story map or did not turn in the story map received a grade of “0”. The homework scores ranged from a minimum of 36% to a maximum of 100%. Homework was graded while the adolescents worked on an in-class assignment, and was returned immediately. The teacher then lead the class in a discussion of the assigned chapter by utilizing a blank story map on the overhead projector. This discussion served as feedback on the adolescents’ story maps as well as additional instruction in story mapping and its relation to goal structure. During the discussion, adolescents corrected their graded story mapping homework at their desk. Homework scores were averaged and used as a covariate in analyses.

Both fable recall and story creation assessments were transcribed verbatim from the hand written papers of the adolescents by a coder blind to the testing condition.

Fable recall

Fable recall protocols were parsed into individual events in a manner similar to that described for the complete fables (see above). The events in adolescents’ recalls were compared to the actual events in the story (determined as described in the Materials section above). Each actual event was scored 0 (not recalled) or 1 (recalled). The percentage recalled for events at each level of importance was calculated. Next, the global coherence of fable recall was rated by trained coders on a scale of 1 to 4. Global coherence represents the general logical flow of the entire recall as perceived by adult evaluators ( Habermas & de Silveira, 2008 ), and as such is related to how a teacher might grade an essay. A scoring rubric was derived from Habermas and Silveira (2008) , and interrater reliability has been consistently high for previous studies employing this coding system ( Flake et al., 2007 ; Freer et al., 2011 ; Lorch et al. 2010 ). A score of “1” indicated that the recall had no clear story line, had many gaps, had many flaws and ambiguities, or had no transitions. A score of “2” indicated that the recall had some story line, but poor transitions and many ambiguities. A score of “3” indicated that the recall had a story line, few ambiguities, and good transitions. A score of “4” indicated that the recall had a good story line, almost no ambiguities, and varied transitions. Finally, fable recalls were coded for 2 types of inferences: Explanatory and elaborative . Explanatory inferences are essential for narrative comprehension because they fill in causal connections between events or outcomes that have not been explicitly stated within the story. An elaborative inference adds information to the story line, but is not essential for narrative comprehension. Both types of inferences were coded for plausibility (i.e., was an inference reasonably consistent, given the explicit story events). Because implausible inferences were rare, only plausible inferences were utilized in the current study. To estimate the inter-rater reliability, two coders coded all of the stories for inferences and 25% of the stories for recall of events and coherence. The interrater reliability for event coding was K = .82 at the level of individual events, r = .85 for global coherence ratings, and r = .92 for total number of inferences.

Story creation task

The stories adolescents created were parsed into individual events, in a similar manner to that described for recall protocols. Story length was assessed via the number of events. Events then were coded for whether they fell into goal-based or non-goal based categories.

Goal-based categories included categories that are part of what Stein and Glenn (1979) described as the story’s “episode system”: goal-initiating events, goals, attempts, and outcomes. Goal-initiating events were events that motivated a character’s goal. Goals were coded as explicit statements of what the main character was trying to complete or attain. Attempts were events where the main character was making an effort to achieve goals. Outcomes were explanations of whether the attempt succeeded or failed.

Nongoal-based categories included settings, main characters, characters’ internal responses, and non-goal-related events ( Stein & Glenn, 1979 . The setting consisted of background information in the study; events such as time and place. The main character was coded as the protagonist if he or she caused the actions to occur in a story. An internal response was an emotional reaction from the main character. Nongoal-based events were actions that took place to move a story along but were not related to goal sequences.

Global coherence of the stories created was coded with the same 1 to 4 scale that was used for the fable recall. In order to estimate inter-rater reliability, two coders coded all of the stories for coherence and 25% of the stories for story grammar categories. The inter-rater reliability for story coherence ratings was r = .70. Interrater reliability was > .80 for all story grammar categories, including those related to goal structure.

Planned Analyses

Pre-post test designs were conducted to explore whether performance improved as a result of the SMI. For comparisons that utilized additional variables (e.g., importance of events during recall), ANOVAs were used. In all other instances, planned paired-samples t -tests were conducted.

To explore whether improvement was a result of practice in the SMI intervention, SMI homework scores were used as a covariate in analyses, and interaction terms were interpreted accordingly.

Effects of SMI on Fable Recall

Recall as a function of importance of events.

To examine the effects of the Story Mapping Intervention (SMI) on recall of events as a function of importance ratings, a 2 (Tests: pre-test, post-test) X 4 (Importance: 4 levels of rated importance) repeated-measures ANOVA was conducted. As seen in Figure 1 , adolescents recalled more events at post-test than at pre-test, F (1, 24) = 29.54, p < .001, d = 2.22, and overall, more important events were recalled more often, F (3, 72) = 56.03, p < .001, d = 1.72. These main effects were qualified by a significant test X importance interaction, F (3, 24) = 29.93, p < .001, indicating that the slope of the function relating recall to importance was steeper at post-test than at pre-test, F (1, 24)= 29.93, p < .001. Notably, adolescents recalled only 21.52% of the most important events at pre-test, but 41.72% during the post-test.

Fable recall as a function of event importance.

When story map homework scores were included in these analyses as a covariate, this accounted for significant variance in test (pre, post), F (1, 23) = 6.92, p < .05, and in the test X importance interaction, F (1, 23) = 10.49, p < .01. In addition, when homework scores were controlled for, the main effect of test (pre, post) and the test X importance interaction were no longer significant ( F (1, 23) = 0.61, ns , and F (1, 23) = 1.55, ns , respectively). This suggests that the higher the quality of homework, the greater the effect of the SMI.

Global coherence

To examine the effects of the SMI on global coherence of recall, a paired-samples t -test compared rated coherence at the pre-test and the post-test. Recall was significantly more coherent during the post-test, M = 2.80, than the pre-test, M = 2.04, t (24) = 3.37, p < .01, d = 1.37, but homework score was not a significant covariate, F (1, 23) = 0.38, ns .

To examine the effects of the SMI on the generation of explanatory and elaborative inferences, paired-samples t -tests were used to compare the number of these inferences generated at the pre-test and the post-test (see Figure 2 ). Adolescents generated more explanatory inferences during the post-test, M = 2.81, than during the pre-test, M = 1.81, t (23) = 2.61, p < .05, d = 1.07. When homework scores were controlled for, the covariate effect was significant, F (1, 22) = 4.95, p < .05, and the effect of the test was no longer significant, F (1, 22) = 1.89, ns , indicating that improvement in explanatory inferences is accounted for by accurate homework completion. Adolescents also made a greater number of elaborative inferences during the post-test, M = 2.83, than during the pre-test, M = 1.33, t (23) = 3.85, p < .01, d = 1.57, but homework score was not a significant covariate, F (1, 22) = 1.02, ns .

Fable recall: Mean values of inferences made.

Effects of SMI on Story Creation

A paired-samples t -test was conducted to examine the number of events in the stories at pre and post test. Adolescents created stories with a greater number of events in the post-test condition, t (22) = 5.26, p = .001, indicating that stories were longer after the SMI.

Goal-based categories

A paired-samples t -test was conducted for each goal-based story grammar category, including goal-based events, goals, attempts, or outcomes. There were no significant improvements in the inclusion of any goal-based categories from pre-test to post-test, all p s > .05.

Nongoal-based categories

A paired-samples t -test was conducted for each nongoal-based story grammar category. Adolescents included a greater number of nongoal-based events in their stories during the post-test, t (22) = 5.26, p < .001, and a greater number of settings in their stories during the post-test, t (22) = 2.64, p < .02, but there were no significant increases in main characters or internal responses, p s > .10.

Raters scored the global coherence of stories created with the same 1 to 4 scale previously used for the coherence of fable recall. A paired-samples t -test (pre-test, post-test) indicated that rated coherence did not significantly improve between pre-test and post-test sessions, t (22) = .30, ns . During the pre-test, coherence ratings averaged 2.91, whereas ratings averaged 2.98 during the post-test.

The current study represents preliminary work in the use of a Story Mapping Intervention (SMI) to improve specific narrative comprehension skills in adolescents with ADHD. Within the context of a broader clinic-based program, adolescents received ten sessions of the SMI and completed associated homework assignments. Pre-post test comparisons utilizing a fable recall and a story creation task were made to examine whether adolescents with ADHD improved on recall of important events, global coherence of recall, generation of inferences during recall, story creation events, goal and nongoal-based categories of story creation, and global coherence of story creation after repeated instruction and practice with the use of a story map.

Results indicated significant improvement in a number of narrative comprehension skills during the fable recall task. Specifically, adolescents demonstrated improvements in recall of important events of a verbally-presented fable and in the global coherence of their written recall, suggesting that they were attending to story events and processing these events in a way that helped them structure important information for future use. In addition, adolescents generated a significantly greater number of explanatory and elaborative inferences during recall of the post-test fable than during recall of the pre-test fable. The increase in the number of explanatory and elaborative inferences created during the post-test session suggests that the SMI assisted adolescents in making appropriate and reasonable implicit connections among story events that are vital to comprehension. Finally, when included as a covariate in analyses, story mapping homework scores accounted for significant variance in recall of story events and generation of explanatory inferences. These findings suggest that those who performed well in completing the story map homework made more significant improvements on pre-post assessments of narration skills. Although this was not a randomized controlled trial, these pilot results are very encouraging.

It is possible that these improvements in narrative comprehension skills are due to two important components of the current work: The visual-organizational component of the story maps and the repeated, guided teacher feedback with the story map during the intervention. The story map is a visual display of the story components. The teacher could use the story map to direct attention towards goal-structure categories with the purpose of improving attention to important information and organizing this information for later retrieval. In addition to the story map itself, this protocol provided repeated practice of skills and feedback on completed story maps across ten sessions, thereby ensuring that adolescents recognized and corrected errors in their use of the story map at regular intervals. Combined use of this strategy and reinforcement of skills over time may have worked together to promote gains.

In contrast to improvements in recall, adolescents did not show the same improvements in their creation of a story without use of a prompt. This is not surprising, given that free writing of a story without prompts is considered a challenging task for individuals with ADHD ( Freer et al., 2011 ). Although stories improved in length (significantly more events and nongoal-based events from pre- to post-test), they were not improved in ways that suggest a stronger adherence to the goal structure of a story. This may be due to the fact that the SMI was better adapted to the demands of a recall task. That is, the teachers discussed how using story maps could help the adolescents remember information and structure essays about existing stories. Although adolescents completed regular writing assignments, teachers had fewer opportunities to address how to create a story based upon character’s goal. Despite non-significant results, development of the story map intervention could be better adapted to serve story creation. For instance, like the self-regulated strategy development (SRSD) model ( Harris & Graham, 1996 ), the story map could be provided prior to writing and used as a development tool for the generation of story ideas. After the story is “mapped,” the adolescent can begin writing. Although exploratory, such tailoring of interventions could be very useful for task-specific skills.

It may also be the case that the SMI should be provided for a longer duration or with greater intensity for story creation gains to be achieved. The literature has consistently indicated that the intensity and duration of treatment for ADHD should reflect the chronic nature of the disorder (Pelham & Fabiano, 2008); limits on the effectiveness of the intervention may reflect the deep-seated nature of the narrative comprehension deficits for individuals with ADHD. Narrative comprehension deficits have been found at young ages in those with ADHD ( Berthiaume et al., 2010 ), with some evidence that the gap between individuals with ADHD and their non-ADHD peers may widen over time ( Bailey, Lorch, Milich, & Charnigo, 2009 ). By adolescence, long-standing narrative comprehension deficits are unlikely to be completely remedied with brief treatment.

One of the strengths of the current study is the use of an intervention directed at improving goal-based narrative comprehension in a population known to exhibit specific deficits in narrative comprehension. Previous interventions that have used a story map as a means to improve recall have shown promising results for children with specific learning problems ( Boulineau et al., 2004 ; Idol & Croll, 1987 ), and the story map has shown evidence of being a potentially useful contribution to efficacious reading treatment programs in the school system ( DuPaul et al., 2006 ). This is the first study to demonstrate that critical elements of recall may be improved among adolescents with ADHD by instruction and practice in the use of a story map as an organizational tool. The current results are particularly notable given what previous research has indicated about the typical effectiveness of interventions for those with ADHD. Though effective for some academic indices ( Evans et al., 2001 ; Pelham et al., 2013 ; Sibley et al., 2011 ), typical treatments for ADHD such as stimulant medication or studying and note-taking skills interventions appear ineffective for improving goal-based narrative comprehension ( Bailey et al., 2011 ; Derefinko et al., 2009 ; Evans et al., 1995 ; Lorch et al., 2004 ). Typical treatments seem to help children and adolescents with ADHD produce more information, but have not specifically improved goal-based narrative comprehension. Results from this study suggest that the SMI may help those with ADHD to build a coherent story representation, thus improving recall of important events, generation of inferences, and coherence of recalls. All of these improvements have promise for facilitating academic success.

Limitations and Future Directions

There were several limitations of the current study. First, due to the fact that this study was conducted within the context of a broader treatment program, there was an unavoidable sacrifice of experimental control. Because all participants were a part of this clinic-based program and the SMI was conducted as a mandatory part of the program, it was not possible to include a no-treatment comparison group. Therefore, although adolescents with ADHD demonstrated significant improvements in fable recall across tests, we were unable to compare these results with adolescents with ADHD who had received the intensive clinic-based program but had not received the SMI intervention, or with adolescents with ADHD who had received neither of these interventions. Future work should include comparison groups to better understand the magnitude of these gains over and above gains made by the summer treatment program, and gains made by simple maturation.

Relatedly, another notable limitation of the current work is that it is difficult to evaluate whether the SMI or the summer treatment program was responsible for improvements in narrative comprehension. For example, the summer treatment program for adolescents with ADHD included behavioral modification to improve attention and reduce classroom-incompatible behavior. It is possible that the other forms of intervention adolescents received may have had a cumulative positive effect on story narration; however, this was partly controlled for in analyses utilizing SMI homework grades. Further study in this area would benefit from utilizing the SMI in isolation (e.g., not as a part of a clinic-based program), or in other structured settings, such as an addition to the school curriculum, to determine the true effect of this treatment and possible cumulative effects of this treatment when combined with other intervention strategies.

The fact that the SMI was conducted in the context of a broader treatment program also limited the amount of experimental control over study factors such as the counterbalancing of study measures and additional interventions that were provided as a standard part of the summer program. Because classroom placement in the treatment program was based upon age and gender of the adolescents, counterbalancing measures could not occur without introducing other study confounds. Thus, one fable was used for baseline assessment and the other was used following the intervention. Future studies of the SMI should address this issue to ensure that the characteristics of a specific story were not responsible for gains. However, in the current study, the fables were very similar to those used in past research in which the effect of importance levels on recall did not differ as a function of the specific fables ( Bailey et al., 2011 ). Thus, it is unlikely that fable effects are responsible for the pattern of recall improvements.

In addition, the nature of this program allowed 8 weeks for the intervention, a considerable period given typical resources. Future work in this area could explore whether an SMI could be implemented in a setting where adolescents typically spend substantial amounts of time (e.g., school or after-school programs), or whether the effectiveness of the SMI could be maintained when much less time is available (e.g., as part of outpatient treatment or tutoring). These preliminary results suggest that 10 practice sessions was enough to make significant gains, but exploration of whether these gains can be achieved in fewer session would be valuable to understanding how and where this form of intervention should be offered.

It is also important to address narrative comprehension deficits among other age groups with ADHD. The current exploratory work evidenced improvements for adolescents aged 12–16, but introducing this type of intervention at younger ages may have the potential to ameliorate narrative comprehension deficits before they have incremental impacts on academic functioning. Alternatively, utilization of similar techniques for individuals entering college may be an important addition to their writing skills that will promote coherence in written assignments. To accomplish this, future work would do well to develop age-appropriate story maps and evaluate of the effectiveness of these maps in a broad range of age groups.

This study explored the use of a story mapping intervention to reduce narrative comprehension deficits in adolescents with ADHD in the context of an intensive, clinic-based treatment program for ADHD. The story mapping intervention improved several aspects of adolescents’ recall of a fable, including the number of events recalled, coherence, and the generation of inferences, and covariate analyses with homework scores suggest that these improvements were related to higher story map homework scores. Although preliminary, these results are encouraging, given the chronic nature of ADHD and the long-standing nature of ADHD-related academic deficits. Despite gains in recall skills, narrative comprehension improvements did not generalize to story creation. However, this intervention could be more effectively tailored to promote the focus of goal-based events in writing assignments by having adolescents develop ideas utilizing the story map as a guide before writing. Based upon the design of this study, it appears possible to use the story mapping intervention as an effective part of a writing class in a secondary-school setting, and future work would do well to use this intervention in more traditional education settings where this type of intervention is likely to be implemented as a part of special services for individuals with ADHD.

Acknowledgements

The authors gratefully acknowledge research support from the National Institute on Drug Abuse of the National Institutes of Health (DA007304 and T32DA035200) and from the Institute of Education Sciences, U.S. Department of Education (R305A120171) to the University of Kentucky. The content is solely the responsibility of the authors and does not necessarily represent the official views of the National Institutes of Health or the U.S. Department of Education.

Appendix A. Story map using goal-based categories

Contributor Information

Karen J. Derefinko, University of Kentucky.

Angela Hayden, University of Kentucky.

Margaret H. Sibley, Florida International University.

Jake Duvall, University of Kentucky.

Richard Milich, University of Kentucky.

Elizabeth P. Lorch, University of Kentucky.

• American Psychiatric Association. Diagnostic and statistical manual of mental disorders. 4th ed., Text Revision. Washington, DC: Author; 2000. [ Google Scholar ]
• Bailey UL, Derefinko KJ, Milich R, Lorch EP, Metze A. The effects of stimulant medication on free recall of story events among children with ADHD. Journal of Psychopathology And Behavioral Assessment. 2011; 33 (4):409–419. [ Google Scholar ]
• Bailey UL, Lorch EP, Milich R, Charnigo R. Developmental changes in attention and comprehension among children with Attention Deficit Hyperactivity Disorder. Child Development. 2009; 80 (6):1842–1855. [ PubMed ] [ Google Scholar ]
• Barbaresi WJ, Katusic SK, Colligan RC, Weaver AL, Jacobsen SJ. Modifiers of long-term school outcomes for children with attention-deficit/hyperactivity disorder: does treatment with stimulant medication make a difference? Results from a population-based study. Journal of Developmental & Behavioral Pediatrics. 2007; 28 (4):274–87. [ PubMed ] [ Google Scholar ]
• Barkley RA. A handbook for diagnosis and treatment. 3rd ed. New York, NY: Guilford Press; 2006. Attention-deficit hyperactivity disorder. [ Google Scholar ]
• Barkley RA, Fischer M, Smallish L, Fletcher K. Young adult outcome of hyperactive children: Adaptive functioning in major life activities. Journal of the American Academy of Child and Adolescent Psychiatry. 2006; 45 :192–202. [ PubMed ] [ Google Scholar ]
• Berthiaume K, Lorch E, Milich R. Getting clued in: Inferential processing and comprehension monitoring in boys with ADHD. Journal of Attention Disorders. 2010; 14 (1):31–42. [ PubMed ] [ Google Scholar ]
• Botvin GJ. Life skills training: Middle school. White Plains: Princeton Health Press; 2004. [ Google Scholar ]
• Boulineau T, Fore C, III, Hagan-Burke S, Burke MD. Use of story-mapping to increase the story-grammar text comprehension of elementary school students with learning disabilities. Learning Disability Quarterly. 2004; 27 :105–121. [ Google Scholar ]
• De La Paz S. Teaching writing to students with attention deficit disorders and specific language impairment. The Journal of Educational Research. 2001; 95 :37–47. [ Google Scholar ]
• Derefinko KJ, Bailey U, Milich R, Lorch E, Riley E. The effects of stimulant medication on the online story narrations of children with ADHD. School Mental Health. 2009; 1 (4):171–182. [ Google Scholar ]
• DuPaul GJ, Jitendra AK, Volpe RJ, Tresco KE, Lutz JG, Vile Junod RE, et al. Consultation-based academic interventions for children with ADHD: Effects on reading and mathematics achievement. Journal of Abnormal Child Psychology. 2006; 34 :635–648. [ PubMed ] [ Google Scholar ]
• Evans SW, Pelham WE, Grudberg MV. The efficacy of notetaking to improve behavior and comprehension with ADHD adolescents. Exceptionality. 1995; 5 :1–17. [ Google Scholar ]
• Evans S, Pelham W, Smith B, Bukstein O, Gnagy E, Greiner A, Altenderfer L, Baron-Myak C. Dose–response effects of methylphenidate on ecologically valid measures of academic performance and classroom behavior in adolescents with ADHD. Experimental and Clinical Psychopharmacology. 2001; 9 :163–175. [ PubMed ] [ Google Scholar ]
• Fabiano GA, Pelham WE, Waschbusch DA, Gnagy EM, Lahey BB, Chronis AM, et al. A practical measure of impairment: psychometric properties of the Impairment Rating Scale in samples of children with attention deficit hyperactivity disorder and two school-based samples. Journal of Clinical Child and Adolescent Psychology. 2006; 35 :369–385. [ PubMed ] [ Google Scholar ]
• Feagans L, Appelbaum MI. Validation of language subtypes in learning disabled children. Journal of Experimental Psychology. 1986; 78 :358–364. [ Google Scholar ]
• Flake R, Lorch E, Milich R. The effects of thematic importance on story recall among children with attention deficit hyperactivity disorder and comparison children. Journal of Abnormal Child Psychology. 2007; 35 (1):43–53. [ PubMed ] [ Google Scholar ]
• Flory K, Milich R, Lorch E, Hayden A, Strange C, Welsh R. Online story comprehension among children with ADHD: Which core deficits are involved? Journal of Abnormal Child Psychology. 2006; 34 (6):853–865. [ PubMed ] [ Google Scholar ]
• Francis S, Fine J, Tannock R. Methylphenidate selectively improves story retelling in children with attention-deficit/hyperactivity disorder. Journal of Child and Adolescent Psychopharmacology. 2001; 11 :217–228. [ PubMed ] [ Google Scholar ]
• Freer BD, Hayden A, Lorch EP, Milich R. The stories they tell: Story production difficulties of children with ADHD. School Psychology Review. 2011; 40 (3):352–366. [ Google Scholar ]
• Habermas T, de Silveira C. The development of global coherence in life narratives across adolescence: Temporal, causal, and thematic aspects. Developmental Psychology. 2008; 44 :707–721. [ PubMed ] [ Google Scholar ]
• Harris K, Graham S. Making the writing process work: Strategies for composition and self-regulation. Cambridge, MA: Brookline; 1996. [ Google Scholar ]
• Idol L, Croll VJ. Story-mapping training as a means of improving reading comprehension. Learning Disability Quarterly. 1987; 10 (3):214–229. [ Google Scholar ]
• Jacobson LT, Reid LR. Improving the persuasive essay writing of high school students with ADHD. Exceptional Children. 2010; 76 :156–174. [ Google Scholar ]
• Jitendra AK, DuPaul GJ, Volpe RJ, Tresco KE, Vile Junod RE, Lutz JG, et al. Consultation-based academic intervention for children with Attention Deficit Hyperactivity Disorder: School functioning outcomes. School Psychology Review. 2007; 36 :217–236. [ Google Scholar ]
• Kendeou P, Lynch JS, van den Broek P, Espin C, White M, Kremer KE. Developing successful readers: building early comprehension skills through television viewing and listening. Early Childhood Education Journal. 2005; 33 :91–98. [ Google Scholar ]
• Kent KM, Pelham WE, Molina BSG, Sibley MH, Waschbusch DA, Yu J, et al. The academic experience of male high school students with ADHD. Journal of Abnormal Child Psychology. 2011; 39 :451–462. [ PMC free article ] [ PubMed ] [ Google Scholar ]
• Kuriyan AB, Pelham WE, Molina BSG, Daniel WA, Gnagy EM, Sibley MH, et al. Young adult educational and vocational outcomes of children diagnosed with ADHD. Journal of Abnormal Child Psychology. in press. [ PMC free article ] [ PubMed ] [ Google Scholar ]
• Langberg JM, Becker SP. Does long-term medication use improve the academic outcomes of youth with Attention-Deficit/Hyperactivity Disorder? Clinical Child and Family Psychology Review. 2012; 15 :215–233. [ PubMed ] [ Google Scholar ]
• Loe IM, Feldman HM. Academic and educational outcomes of children with ADHD. Ambulatory Pediatrics. 2007; 7 (1 Suppl):82–90. [ PubMed ] [ Google Scholar ]
• Lorch E, Diener M, Sanchez R, Milich R, Welsh R, van den Broek P. The effects of story structure on the recall of stories in children with attention deficit hyperactivity disorder. Journal of Educational Psychology. 1999; 91 (2):273–283. [ Google Scholar ]
• Lorch EP, Milich R, Sanchez RP. Story comprehension in children with ADHD. Clinical Child and Family Psychology Review. 1998; 1 :163–178. [ PubMed ] [ Google Scholar ]
• Lorch E, Milich R, Sanchez R, van den Broek P, Baer S, Hooks K, et al. Comprehension of televised stories in boys with attention deficit/hyperactivity disorder and nonreferred boys. Journal of Abnormal Psychology. 2000; 109 (2):321–330. [ PubMed ] [ Google Scholar ]
• Lorch EP, Milich R, Flake RA, Ohlendorf J, Little S. A developmental examination of story recall and coherence among children with ADHD. Journal of Abnormal Child Psychology: An official publication of the International Society for Research in Child and Adolescent Psychopathology. 2010; 38 (3):291–301. [ PMC free article ] [ PubMed ] [ Google Scholar ]
• Lorch E, O’Neil K, Berthiaume K, Milich R, Eastham D, Brooks T. Story comprehension and the impact of studying on recall in children with attention deficit hyperactivity disorder. Journal of Clinical Child and Adolescent Psychology. 2004; 33 (3):506–515. [ PubMed ] [ Google Scholar ]
• Low J, Durkin K. Structure and causal connections in children’s on-line television narratives: What develops? Cognitive Development. 1998; 13 :201–225. [ Google Scholar ]
• Pelham WE, Evans SW, Gnagy EM, Greenslade KE. Teacher ratings of DSM-III-R symptoms for the disruptive behavior disorders: Prevalence, factor analyses, and conditional probabilities in a special education sample. School Psychology Review. 1992a; 21 (2):285–299. [ Google Scholar ]
• Pelham W, Gnagy E, Greenslade K, Milich R. Teacher ratings of DSM-III-R symptoms for the disruptive behavior disorders. Journal of the American Academy of Child & Adolescent Psychiatry. 1992b; 31 :210–218. [ PubMed ] [ Google Scholar ]
• Pelham WE, Sibley MH, Evans SW, Smith BH, Gnagy EM, Greiner AR. Summer treatment program for adolescents. Available from authors. 2012 [ PubMed ] [ Google Scholar ]
• Pelham WE, Smith BH, Evans SW, Bukstein O, Gnagy EM, Greiner AR, Sibley MH. The effectiveness of short and long-acting stimulant medications for adolescents with ADHD in a naturalistic secondary school setting. Journal of Attention Disorders. 2013 Mar 4; [ PubMed ] [ Google Scholar ]
• Mandler JM, Johnson NS. Remembrance of things parsed: Story structure and recall. Cognitive Psychology. 1977; 9 :111–151. [ Google Scholar ]
• Molina BS, Hinshaw SP, Swanson JM, Arnold LE, Vitiello B, Jensen PS, Epstein JN, Hoza B, Hechtman L, Abikoff HB, Elliott GR, Greenhill LL, Newcorn JH, Wells KC, Wigal T, Gibbons RD, Hur K, Houck PR. MTA Cooperative GroupThe MTA at 8 years: prospective follow-up of children MTA Cooperative Group The MTA at 8 years: prospective follow-up of children treated for combined-type ADHD in a multisite study. Journal of the American Academy of Child and Adolescent Psychiatry. 2009; 48 (5):484–500. [ PMC free article ] [ PubMed ] [ Google Scholar ]
• Reid R, Lienemann TO. Improving the writing performance of students with ADHD. Exceptional Children. 2006; 71 :361–377. [ Google Scholar ]
• Renz K, Lorch EP, Milich R, Lemberger C, Bodner A, Welsh R. On-Line story representation in boys with Attention Deficit Hyperactivity Disorder. Journal of Abnormal Child Psychology. 2003; 31 (1):93–104. [ PubMed ] [ Google Scholar ]
• Rogers L, Graham S. A meta-analysis of single subject design writing intervention research. Journal of Educational Psychology. 2008; 100 :879–906. [ Google Scholar ]
• Schultz BK, Evans SW, Serpell ZN. Preventing failure among middle school students with ADHD: A survival analysis. School Psychology Review. 2009; 38 :14–27. [ Google Scholar ]
• Sibley MH, Pelham WE, Evans SW, Gnagy EM, Ross JM, Greiner AR. Evaluation of a summer treatment program for adolescents with attention deficit/ hyperactivity disorder. Cognitive and Behavioral Practice. 2011; 18 :530–544. [ Google Scholar ]
• Sibley MH, Smith BH, Evans SW, Pelham WE, Gnagy EM. Treatment response to an intensive adolescent-directed intervention for ADHD. Journal of Attention Disorders. 2012; 16 :443–448. [ PubMed ] [ Google Scholar ]
• Smith BH, Pelham WE, Evans SW, Gnagy E, Molina BSG, Bukstein OG, et al. Dosage effects of methylphenidate on the social behavior of adolescents diagnosed with attention-deficit hyperactivity disorder. Experimental and Clinical Psychopharmacology. 1998; 6 :187–204. [ PubMed ] [ Google Scholar ]
• Stein NL, Glenn CG. An analysis of story comprehension in elementary school children. In: Freedle OR, editor. New directions in discourse processing. Vol. 2. Hillsdale, NJ: Erlbaum; 1979. pp. 53–120. [ Google Scholar ]
• Taylor BES. ADHD and Me: What I Learned from Lighting Fires at the Dinner Table. Oakland, CA: New Harbinger Publications; 2007. [ Google Scholar ]
• Thurlow R, van den Broek P. Automaticity and inference generation during reading comprehension. Reading & Writing Quarterly: Overcoming Learning Difficulties. 1997; 13 (2):165–181. [ Google Scholar ]
• Trabasso T, Sperry LL. Causal relatedness and importance of story events. Journal of Memory and Language. 1985; 24 :612–630. [ Google Scholar ]
• Trabasso T, van den Broek P. Causal thinking and the representation of narrative events. Journal of Memory and Language. 1985; 24 (5):612–630. [ Google Scholar ]
• Trabasso T, van den Broek P, Suh S. Logical necessity and transitivity of causal relations in stories. Discourse Processes. 1989; 12 (1):1–25. [ Google Scholar ]
• Wechsler D. Wechsler abbreviated scale of intelligence. Psychological Corporation. 1999 [ Google Scholar ]
• Wechsler D. Wechsler individual achievement tests. 2nd ed. San Antonio: The Psychological Corporation; 2002. [ Google Scholar ]

• Peer Graded Assignment - Maps
• by Raga L G
• Last updated over 3 years ago
• Hide Comments (–) Share Hide Toolbars

Twitter Facebook Google+

Or copy & paste this link into an email or IM: