in-app

Agile is about empowering teams to take ownership, feel truly engaged, and foster a culture of collaboration. More than ever, teams are required to deliver with greater adaptability, speed, and engagement. The future is more ambiguous and complex, and Agile teams must know how best to respond to these changing conditions.

Agile experts John Walpole, Dean MacNeil, and Nick Muldoon share their success formula behind the high-functioning Agile teams at Lyft, Valiantys, and Easy Agile. You will learn:

• How to create a compelling 'why' that the whole team can get behind
• How to empower your teams
• The qualities of high-performing Agile teams

WATCH NOW

Create a compelling 'why' that the whole team can get behind

‍

I think Agile is not a silver bullet. We have people who look at Agile and say, "Oh, well, this is going to solve all of our woes." And it's not; it's certainly not a turnkey thing.

Nick Muldoon, Co-CEO at Easy Agile

Agile is not a silver bullet. It is not a methodology that will solve leaders, teams and individuals' problems. Agile is a continuous improvement journey of "adaptability in evolutionary theory; it's about responding to either a new environment or changes in your environment to again, not just survive but to thrive," said Dean.

Set your Agile teams up for success by teaching them to thrive by empowering them to lead change, make mistakes, build a solid foundation, and be open to learning, changing, and communicating the meaningful 'why' behind their work. You will see an explosion in Agile team success when you have a "cohesive team aligned to a common mission with a growth mindset."

Motivate your Agile teams by connecting their work with a meaningful 'why.' Schedule a meeting to ensure you constantly discuss their work's more profound purpose. Bring up a real-life customer example. John shared, "At Lyft, we share stories in a fortnightly meeting. We offer free accessible rides to those in wheelchairs or those who struggle to pay for a ride but need access to transportation to get to work or school.

"Bring your personas to life with these real-life examples, so it's front and center in your employee's minds," said John.

‍

Empowering your teams

Culture eats strategy for breakfast

Peter Drucker

Your employees need to lead the change. "If you look at great leaders in recent Agile transformations, you might want to look at a company like Porsche," said Dean. Dean shares how Porsche has inspired Valiantys because "every employee at Porsche is leading the change. So they're all bought into it; they all have that sense of leadership to drive it.". Porsche's employees are leading the change because their leadership communicates the 'why' well. "Fun is number one when their CIO lists off the top three reasons 'why' everyone is so fired up about the Agile transformation. Because you can have fun on the job, your job is not supposed to be a grim duty. It's supposed to be something you look forward to."

"Empower your teams to make mistakes," said John.

Empower your Agile teams to fail and make mistakes through powerful questions. Leaders have to change their tone from "oh no, who do I fire?" to "what's the challenge? What can I do to help?". Express to your team that you're on a journey to learn as much as they are. In doing so, the leader humanizes themselves and becomes more vulnerable.

Leadership sets the tone. As a company scales, the responsibility to create the culture and the risk appetite falls more on leadership.

Qualities of high-performing, Agile teams

1. Create a solid foundation

Set your Agile team up for success with a stable team unit. Don't keep moving teams around; create long-term Agile teams to allow individuals to get to know each other and humanize one another. "I think stability is key to having the tacit knowledge keeping together and this open mindset where they're willing to learn; I love that," said Nick.

2. Open to learning and adapting

For Agile teams to continuously improve, they must constantly be learning and adapting. "You can't get that learning and adaptation if you keep just stirring the pot. Because you're going to keep scattering that knowledge, you want to take hold, and then, of course, you want to spread the knowledge to the organization then," said Dean.

3. Share feedback and do the retrospective

Ensure your Agile teams are demonstrating working product on a regular occurrence. If you're practicing Scrum, make sure you are doing the weekly sprint review. This allows the team to receive feedback from stakeholders and keep iterating and moving forward, ensuring they stay in movement. "Do your retrospective," said Dean." We're looking at what we delivered, and now we're going to look at how we delivered it." It is imperative that Scrum teams gather at the end of each sprint to discuss what went well, what didn’t go so well, and what can be improved on for next time. Otherwise, you invite complacency and stagnation into your Scrum process — the antithesis of Agile.

Using Easy Agile to set your Agile teams up for success

Easy Agile TeamRhythm supports your team's Agile practices in Jira. The user story map format in TeamRhythm transforms your flat product maps into a dynamic and flexible visual representation of work. Watch the highlights tour to see how Easy Agile TeamRhythm makes sprint planning, managing your backlog, and team retrospectives easier. Visit Atlassian Marketplace to start your free, 30-day trial today.

‍

“The people who plan the work do the work” is the unwritten rule of the Scaled Agile Framework.

Yet, this can be easier said than done when we’re looking at multiple teams of people needing to plan together.

Add in the complexities of large enterprises that face their own unique challenges - ranging from product development to budget to implementing feedback to final delivery - and suddenly the idea of how to bring teams together for planning can feel harder again.

If you’re familiar with the Scaled Agile Framework, you will already be aware SAFe is designed to facilitate better collaboration and communication between multiple cross-functional groups. The core way to do this with SAFe is Program Increment or PI Planning (Planning Interval Planning in SAFe 6.0)

A plan can take on so many different forms - even just between teams - but with SAFe it is easier to see what ‘good’ looks like when it comes to efficient PI Planning.

The SAFe program board or ART planning board (SAFe 6.0), is a critical tool and output of PI Planning. It is a visual summary of features or goals, cross-team dependencies, and other factors that impact their delivery. Not only does this help with transparency, but it also increases flexibility that, in turn, helps minimize delays and unhealthy dependencies.

What is often overlooked is that PI Planning plays a crucial role in setting teams or the entire program up for success - including implementing other SAFe ceremonies or events.

In this article, we’ll discuss everything you need to know about program boards, including why they’re important in the planning process and how larger teams can use them in PI Planning and beyond.

We’ll also explore exactly how Easy Agile Programs digitises the SAFe program board, not only allowing the people who plan the work to do the work, but also allowing you to plan the work in the environment where the work gets done - in Jira.

NB: while the program board is referred to as 'ART Planning Board' in the updated 6.0 version of the Scaled Agile Framework, it is the same artefact and plays the same role in PI Planning and beyond.

What is a program board?

What does your teams plan or schedule typically look like?

Would it indicate to you what work was being done? Who was doing it? Perhaps even an indication of when they would and any key deadlines these teams are working towards?

The headline here is that a program board is all of this, but also more.

The program board is a visualization of the work being committed to during the Program Increment / Planning Interval or PI. It is simultaneously the facilitator of planning as well as the plan itself.

A typical idea of a program board - especially for collocated PI Planning sessions - is literally a physical board on a wall.
It would show:

• Columns: marking the iterations for the increment
• Rows: representing different teams within that increment
• Sticky notes: describing the features that teams are working on or used to indicate milestones that they’re working towards
• Strings: between these features to indicate if there are any dependencies

But how does a program board help the planning process?

A program board facilitates better team collaboration because it streamlines project communication and planning, while also ensuring better communication between the involved teams.

Moreover, program boards help define the responsibility of each team involved in making the idea a reality, which in turn, helps to streamline the process as a whole.

During PI Planning, the program board supports teams to visualize and manage dependencies across the PI; giving them greater clarity of the work in detail, how the work relates to what the business is trying to achieve and to each other, what tasks need to be done, and crucially, whether there are any issues that may cause delays.

A program board is simultaneously the facilitator of planning as well as the plan itself.

To understand how program boards help with the planning process, let’s go over the different components found on them.

How to set up your SAFe program board for successful PI planning

According to Scaled Agile, there are two primary outputs of PI Planning:

1. Committed PI Objectives
2. Program board - with new feature delivery dates, dependencies among teams and relevant Milestones

So if you’re following SAFe and doing PI Planning you should finish PI Planning with a program board.

During PI Planning, not only do teams discuss and define the features and dependencies, but they also establish milestones across the PI.

This is where a digitised PI Planning tool can really benefit remote or hybrid teams doing PI Planning - the same information is planned in the same place.

Here are a few tips to help you create a SAFe program board.

1. Setting up the board itself

Not to be underestimated, the bare bones of the program board need to be set up.

There are two key elements here:

• Sprint or iteration columns:
  • The right number based on how many iterations/sprints will be in your PI, including a final one for iteration planning
• Rows or swimlanes:
  • One for milestones/events - typically the first
  • One for each team
  • May also have a swimlane for shared services, suppliers or other teams not in the Agile Release Train (ART)

Here is what this may look like:

If you were at this stage of your program board in Easy Agile Programs, your board would look like this:

In Easy Agile Programs, each team represented in a dedicated swimlane represents an agile board in Jira. So the issues that you will be scheduling for this team in sprints during PI Planning and beyond, will be reflected on their agile board and vice versa.

The start and end date for the PI and the number and length of your sprints can all be edited to suit your organisation’s workflows.

When you are in editing mode and are ready to schedule features, the shared team features swimlane also appears at the top to visually indicate if there is work to be scheduled across multiple teams.

2. Start with features and milestones

During PI Planning, Product Management shares the product/solution vision and this commonly also means the next top 10 upcoming features for the teams to take into the PI from the backlog. (We know from our customers that sometimes this can be a lot more!)

We also want to start by knowing which milestones we are working towards. Often these can represent product release dates, external deliverables or deadlines like preparing a demo or showcase for a trade show, marketing launches or events. Having these visualized on the program board helps teams to easily see what they are working towards, but also to inform prioritization of the specific features needed to help meet delivery of that milestone.

If you are working with a physical or simple digital program board, features and Milestones are represented by ‘sticky notes’ - placed in the appropriate swimlane and/or colour to indicate this information as well as the team responsible for it and the time frame:

So what does this look like in Easy Agile Programs at this point?

Milestones are highly visual

• Milestones can be customised to indicate start/end date and colour. They run across all team swimlanes so teams can easily see how their work relates to an upcoming deliverable or event.
• Milestones still have a dedicated place at the top of the program board but this can be collapsed if desired

Features are native Jira issues

• Features in Easy Agile Programs are native Jira issues, commonly epics. You can easily click on the issue key from the program board to see more information via the issue view.
• Features can be easily scheduled from the backlog into a swimlane through drag and drop, or created via the program board. To indicate when a feature is intended to start and be completed, simply drag and drop the edge of the issue:

Join a product tour to walk through Easy Agile Programs

Want to bring your Program Board into Jira?

Join a demo

3. Identify dependencies

With the features done, the next thing that teams should look for is dependencies. Remember the strings we mentioned before?

Dependencies between features and teams are represented with string on a program board when it’s on a wall or lines between those features in a digital tool.

Sticky notes in a different colour, like red, indicate a significant dependency. For example that feature may have more than one feature relying on it to go to schedule.

To explain this, let’s consider an example.

Imagine Team X realizes they cannot develop a feature until Team Y develops an API thanks to the program board. So, what both teams can do is talk to each other and come up with a solution that works for everybody, leading to better collaboration among the teams.

After an agreement is reached, a dependency will then be placed on the board so everyone has the same understanding about the dependency, and how it’ll be resolved. A piece of string will be attached to each card to demonstrate this:

The nature of dependencies mean that something is required to be completed in order for something else to be done.

To be able to more easily see when dependencies are scheduled, Easy Agile Programs has a traffic light system of red, orange and green dependencies to indicate dependency health.

Dependency health is represented as follows:

• A red line indicates the dependant issue is scheduled in a sprint after the dependency (conflict)
• An orange line indicates the dependant and dependency are scheduled in the same sprint (a risk)
• A green line indicates the dependant issue is scheduled in a sprint before its dependency (healthy)
• A black line indicates the dependency exists with issues outside of the current view. Whether this is the current Agile Release Train / Program, or with a future or past increment.

This easily indicates to a Release Train Engineer or a Program Manager where they ought to focus and to be able to address any scheduling issues during planning.

Easy Agile Programs also allows you to visualize dependencies between issues within and across teams from the Team Planning Board. This provides a really focussed view of the work for a particular team for the PI, and how that work relates to other teams:

Program boards are needed for better collaboration

The power of the program board lies in having a single view of what a collection of teams are committing to - together - and exactly how that work relates to each other. It helps organize planning sessions by summarizing future dependencies across all teams and sprints. As a result, scrum masters, release train engineers, product managers and business owners can easily identify and prioritize cross-team conversations that matter the most.

Running a scaled planning session or PI Planning ceremony, especially for the first time, can be daunting.

But if you’re successful in developing a solid program board as part of your PI planning process, you won't have to worry about chasing down your co-worker or team member to meet deadlines. The key here is to make sure you’ve scheduled the most important features to take into the PI, identified cross-team dependencies, and have visualised any milestones or deadlines to ensure they can be realistically achieved.

The program board can become more impactful though, when it is more than just a plan. Building a program board in an online tool with the added capability of it representing the actual work that’s planned to be done means that it has a life beyond PI Planning; it becomes the living document of the teams progress and a means to identify when there are any blockers to that progress.

In order for agile teams to be agile and continuously and iteratively deliver value, they need to be equipped with a program board that can help them respond to any changes so that they can plan for success but also progress towards it.

Ready to take your Program Board off the wall and into Jira?

You can with Easy Agile Programs

TRY NOW

‍

Should you form cross-functional agile teams?

In large, conventional organizations, multiple departments manage specific functions. Marketing, finance, HR and sales teams work in silos, often focused on their own outcomes rather than being primarily driven by the customer and the market.

Yet even before the pandemic hit, organizations recognized the need to manage change and make decisions quicker than ever before to keep up with competitors. Along came covid, and those needs vastly intensified.

To thrive in an uncertain, complex, and ambiguous world, many organizations are moving away from silos and racing towards enterprise agility, forming networks of empowered cross-functional agile teams.

But the change from siloed departments to agile teams means change, and change can be difficult.

In this article we weigh up the pros and cons of each operating model.

Key points

• Communication, collaboration, and employee engagement are often better in cross-functional teams.
• By iteratively testing solutions quickly, cross-functional teams can boost productivity, cut costs, and deliver better results.
• There may be bumps along the road before a newly formed cross-functional team matures and reaches its potential, but you can take steps to help them succeed.

"The two most urgent reasons for adopting Agile are the speed and flexibility required by working environments that continue to be bother unpredictable and volatile." State of Agile Report

What are cross-functional agile teams?

Cross-functional agile teams (sometimes known as cross-functional scrum teams) are a key element in any organization’s agile development.

The team brings together people from across the business with different expertise and skillsets. Together, the team works toward a common goal.

Usually made up of 5 to 11 people, the team defines, builds, tests and delivers projects in sprints or iterations.

"The ability for the team to support each other, collaborate with each other and align to the goal are wonderful ways to measure agile."

William Rojas, Adaptavist

What are the benefits of cross-functional agile teams?

There are many benefits of having cross-functional agile teams in your organization. Here’s our top five.

1. Cross-functional teams communicate and collaborate better

Siloed teams can spend many hours a week in unproductive meetings as they negotiate resources and manage conflicting priorities. On the other hand, Agile teams align on goals and objectives from the beginning of each project. This helps make their subsequent meetings brief, productive and transparent. Each person is accountable and empowered to share progress and solve problems. As a result, agile teams are often more engaged and passionate about their work.

2. Cross-functional teams are responsive

In silos, each team is responsible for an aspect of a project with limited visibility into what other teams are doing. This can lead to blockers or conflicting priorities, creating rework and delays. They may also find they lack specific skills as the project goes on, leaving teams rushing to fill the gaps and causing further delays. Moving to agile teams means having the necessary skills and resources available, as well as identifying conflicting priorities and blockers early. This helps agile teams rapidly iterate, continually improve, and deliver results.

3. Cross-functional teams are innovative

In siloed organizations, employees can get caught up in their departmental group think. The limited exposure to other teams makes employees less likely to question established practises or suggest improvements. In cross-functional agile teams, perspectives from people across multiple teams are shared from the outset. Because people from different skills approach problems in different ways, this can lead to great ideas and business innovation.

4. Cross-functional teams help the business adapt to change

With their iterative approach and frequent communication, cross-functional agile teams can problem solve and change directions fast. They don’t face the renegotiation, reprioritization, and delays that can hold siloed teams back. Instead, businesses with cross-functional teams can better respond to changing market and customer needs.

5. Cross-functional teams consistently focus on the big picture

Cross-functional agile teams understand the ‘why’ behind the work they’re doing, and they come together with a focus on the customer experience. This shared focus dissolves the barriers between the different functions within the team. Deliverables are mapped to high-level business objectives which deliver greater value to the end-user.

What are the downsides of cross-functional agile teams?

If cross-functional teams are done right, there really are no downsides. What organization doesn’t want increased collaboration, innovation, customer focus and faster delivery?

That said, there can be bumps and conflict as people learn to adapt to the agile mindset – and this is where cross-functional teams can fail to deliver. Here are some of the common challenges large organizations face when moving to cross-functional agile teams:

• Cultural resistance with people reluctant to let go of the old way of doing things.
• No clear accountability, leaving teams unable to make quick decisions and people clinging to a sense of ownership over their work.
• Lack of alignment with goals which can lead to misunderstandings, rework, and potential conflict.

With this in mind, it may take a little time and support for a newly formed agile team to find its wings.

"Often the way teams become agile is just by doing it, trying it, and continuing to evolve and committing to that approach. So, if you haven't started - just get started. That's often the biggest struggle."

William Rojas, Adaptavist

The first step is to just get started

Being agile means changing an organization’s processes and people structure, and it can seem like a lot of hard work. But if businesses don’t transform so they can capture the productivity, speed, customer, and employee engagement benefits; they’re at risk of being left behind.

Cross-functional agile teams can be your key adapting fast and getting ahead. There’s no doubt they can deliver outstanding results – if you take the right steps to set them up for success.

For concrete advice on how to drive successful cross-functional agile teams and avoid failure, sign up for our free on-demand webinar - ‘Do’s and Don'ts of Agile Teams with Adaptavist’.

The webinar will take a deep dive into the SAFe agile team together with our partner and SAFe expert Adaptavist.

Keen to scale agile and form successful cross-functional teams?

Come along to a free, 40-minute on-demand webinar to find out how

‍

What is User Story Mapping? And more importantly, WHY would you want to run a story mapping session with your team?

Let’s start off by talking about the origins of User Story Mapping.

It’s now a common practice in agile software development, but it wasn’t always that way.

If you have experience with a Scrum or Kanban backlog, you've likely run into the dreaded flat backlog.

Why Story Mapping

In its simplest form, a flat product backlog is a laundry list of stuff 'to do' that will ultimately provide some form of value to your users/customers. At least we hope so.

Many of us have contributed to making these backlogs longer and longer, and they inevitably become overwhelming.

Regardless of whether the team pulls work from the backlog one-by-one or groups it into sprints, prioritizing work in a flat backlog comes with its challenges.

The flat backlog is a 2 dimensional view. It’s like a shopping list, which doesn’t provide context for the work.

Enter, the User Story Map! The concept of a User Story Map was born out of a desire to kill the flat backlog and create a more holistic, customer centric overview of our work.

A user story map is a visualisation of the journey a customer takes with a product, and includes the activities and tasks they would typically complete.

Usually conducted at the beginning of a Project, a user story mapping session is done with the sole purpose of creating a shared understanding amongst the team of who your customers are and how you should focus your time working on stories that provide the most value for them.

You can do this on a whiteboard with sticky notes, or you can do it in Jira using our app, Easy Agile TeamRhythm.

How to build a user story map

To create a visualisation of the journey a customer takes with a product, start by identifying each stage, and then list the activities and tasks the customer would typically complete for each.

Next, begin to associate each item of work in the backlog with its corresponding touchpoint in the customer journey.

At this point in a User Story Mapping session, a matrix should begin to emerge, containing a list of tasks or stories to which the team has committed to delivering, organized according to the steps in the customer journey.

From there, the map is divided into the time blocks the team uses to plan their work. For example, in sprint 1, the team might commit to 5 user stories, which are attached to 3 epics.

This helps build understanding of how progress will be made against larger pieces of work.

Why user story mapping is better than a flat backlog

Connecting the work in the backlog to the customer journey in this way begins to answer key questions like:

• WHY are we building this?
• WHO are we building this for?
• WHAT value will it provide them?
• WHEN do we expect to deliver this?

User story mapping essentially converts the 2D flat backlog in a three-dimensional view, because it gives us a way to say, “ok I’m currently working on building this user story, and I can visualise what piece of the customer journey this will be directly impacting AND we know when it will be delivered.”

Also, by putting the focus on the user, a story map ensures that the backlog contains work that add real value for the customer by helping them achieve their goals.

How to run a user story mapping session

Now that you have a better understanding of the value of a User Story Map, let's look at how to create one. First, you’ll need to set up a Story Mapping session with your team.

But whatever you do, don’t make it an open invite. This is really important, because if you don’t have the right people in the room then it won’t be effective.

People you could consider inviting are:

The product owner for the team

• a tech lead
• a user experience designer
• a marketing lead
• a data analyst and,
• someone from customer support

It’s also important to set some ground rules for the session.

There should be one person facilitating the session. A good practice is to involve a Product Manager from another team to run the session.

Depending on the scope of the story mapping session you may want to take a whole day or spread it out over a couple of days.

The scope all depends on how big your team is and how many user stories you need to add to your map.

There should be no phones or laptops out except for the facilitator.

Also, everyone in the room should be familiar with the user stories being discussed.

Now that you know the benefits of a user story map and what to consider when setting up the mapping session with your team, start thinking about who you can invite to participate in and facilitate the session.

Backlogs are so full of potential, right? Ideas and possibilities for your product to become bigger and better than ever before.

But when you’ve got more than a few items on your list, backlogs are also overwhelming.

Without some kind of clear structure or prioritization, your team won’t know what to work on first.

They might work on whatever they feel like, whatever’s easiest, or most interesting, or not do anything at all.

You need a way to figure out what you should work on first. Not only that, but you need to make sure that what you’re doing delivers value to customers, makes sense for each release, fits into the bigger picture of your organization’s goals.

That’s where user story mapping comes in.

What is user story mapping?

User story mapping is a useful way to organize and prioritize your user stories so that you can schedule your work and design your releases.

It helps you visualize the customer’s journey through your product from start to finish, including all the tasks they’d normally complete along the way.

What’s a user story mapping session?

User story mapping is usually done in sessions over 1-2 days where you bring key people together in the same room.

During these sessions, your product manager (and sometimes other stakeholders) shares their customer insights with the team, who also share their ideas for the product.

Together, you brainstorm user stories, unpack the steps in your customer journey, list out any current issues, and put these onto a user story map. Your user story mapping session gets everyone on the same page about what needs to happen.

What’s a user story map?

A user story map is the artefact or visual board you produce as a result of a user story mapping session.

Your teams will refer to this map throughout each sprint to make sure they’re on schedule, coordinate dependencies, and keep sight of the big picture.

What’s a user story?

In order to understand what a user story map is, it’s important to take a step back and define one of the key components: the user story.

A user story is a goal or outcome that the user or customer wants to achieve. Usually, you’ll write user stories like this:

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

A user story should be the smallest unit of work that can deliver value back to the customer.

You might also consider a user story to be a task that’s written from the user or customer’s perspective. User stories are usually added to your backlog, and from there, you can arrange and prioritize them, and plot them on a user story map so that they’re scheduled to a release or sprint.

Read more about user stories in our blog: How to write good user stories in agile software development.

What does a user story map look like?

User story mapping is traditionally done on a physical story mapping board:

But increasingly, companies are doing their story mapping digitally. If you use Easy Agile User Story Maps, yours might like more like this:

Whether you do your user story mapping physically or digitally, you’ll see both approaches have a few things in common:

• A backbone (the row along the top of the sticky notes), often consisting of epics
• Cards or sticky notes with user stories under each item in the backbone
• These stories are sequenced vertically from most important (to the customer) at the top, to least important at the bottom
• Horizontal cut lines or swimlanes define where your releases or sprints start and stop

(Psst: read more in our blog, Anatomy of an agile user story map.)

What’s involved in a user story mapping session?

A user story mapping session involves discussing and planning all the parts that make up your story map:

1. Your team will get together and decide on the backbone - the big steps that make up your user journey.
2. Next they’ll brainstorm user stories - all the little steps that make up the user journey and any issues (bugs or ideas) and add them to the backlog.
3. They’ll organize these stories under the backbone item they’re associated with.
4. Next they’ll discuss and estimate the work involved in each user story, assigning story points.
5. After that, your team can add cut lines to mark out what they’ll deliver and when - either by sprint or release. At this point, you might shuffle some stories around if it makes sense for the user to get them in the same release.
6. If everyone’s happy with the plan, the story map is done (for now) and it’s time for your team to start the first sprint.
   

That seems like an awful lot of effort. So, what’s the point?

What’s the point of user story mapping?

User story mapping benefits both your customers and your team.

Customers get more value delivered, sooner

helps you understand what your customers want. Because the focus is on the customer journey and what tasks they’d need to complete in order to use your product, it helps you prioritize work that’ll help fill in the gaps for customers and deliver value to them.

Teams prioritize and collaborate better

A three-dimensional view helps with prioritization because your team can see what user stories should be grouped within a release to deliver a new experience for users. For example, adding the ability to customize your profile isn’t all that meaningful unless you have a community aspect where users can view other profiles and/or interact with one another. User story mapping helps you fit all the pieces together - and make sure you can realistically deliver them within the sprint or release.

Plus, you can more effectively plan your work and collaborate as a team with your user story map. That’s because you can see the big picture and full customer journey before you start the work.

For more insights, check out our blog on why user story mapping.

What’s the alternative to user story mapping?

If you haven’t done user story mapping until now, you’ve likely been using another method to understand customer requirements and plan/prioritise your work.

The most common approach is known as the “flat backlog”. Essentially, this is a task list that’s ordered from highest to lowest priority, and might be broken up by cut lines for sprints or version releases. The flat backlog is simple (it’s basically a to-do list) but if you have a complex product, lots of teams working on it, dependencies, and a massive, ever-changing backlog… you’re going to need something more robust so that you don’t lose sight of your goals, customer-focus, and priorities.

Speaking of alternatives, check out this little story from one of our customers…

What user story mapping can do for teams

"Our teams were looking for an alternative view to the standard Jira backlog/board view, which doesn't lend itself to organizing and grooming massive backlogs with lots of epics.

The Easy Agile User Story Maps app allows our teams to better organize their work. The user interface is logical, and product owners (who are usually non-technical folk) like the layout of cards in columns under their respective epics.

This vertical view seems to foster better communication doing planning meetings and does a great job of providing a visualization of what comes next."

- Christopher Heritage, The Atlassian Team @NextEra Energy

So, as you can see from this example, a lot of teams start with flat backlogs or board views, but find that they outgrow this as their backlog gets bigger.

How user story mapping can upgrade your flat backlog

What makes user story mapping different from the flat backlog is that it has a whole other element. It’s not flat, but more three-dimensional.

You’ve got the list of activities/tasks, but they’re first sorted by how they impact the customer journey. Only then are they prioritized and broken up by when they’re being released.

User story mapping is a little more complex to set up than the flat backlog, but it makes the work more meaningful, customer-focused, and impactful. With a user story map, you can see the big picture and collaborate on it.

We talk more about this in our blog, The difference between a flat product backlog and a user story map.

Try user story mapping inside Jira

Want to know the best way to understand what user story mapping is?

You can’t learn how to ride a bike by reading about it. And you can’t *really* learn what user story mapping is without doing it and experiencing the benefits firsthand.

So, give it a try!

If your team uses Jira for project management and workflows, you can get an add-on that helps you turn that flat backlog into a three dimensional user story map.

Easy Agile User Story Maps for Jira creates the X-axis so you can add your customer journey backbone and organize your stories to fit into this journey. That way, your team gets the big-picture view of what they’re working on, and they can prioritize tasks to deliver maximum value to your customers, sooner.

Best of all, you can do all your user story mapping inside of Jira so that it’s digital, collaborative, and constantly available to your team - even if they’re working remote/distributed. And since it fits in with your existing backlog, you can hit the ground running with pre-filled user stories. In other words, you can expect to save a whole bunch of time.

You can get started with Easy Agile User Story Maps for Jira, with a FREE 30-day trial today or check out the demo here.

Try now

Hopefully, you’ll find it just as useful as our customers…

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.

- Mike Doolittle, Product Director @Priceline

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

- Casey Flynn, Distribution Forecast Analyst @adidas

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

- Rafal Zydek, Atlassian Jira and Confluence Expert Administrator @ING Tech Poland

With Easy Agile User Story Maps, we find it much easier to use and navigate Jira. Our favorite features include the ability to drag and drop stories across the Epics, being able to view the work using FixVersion and Sprint Swim Lanes, and Excel export. We’ve been using Story Maps functionality for quite sometime now and I recommend it to other project teams, as well.

- Sathish K Mohanraj, Lean-Agile Coach @Equifax

Learn more about user story mapping

Want to learn more about user story mapping? Check out our User story mapping ultimate guide - it has everything (and we mean everything) you could possibly want to know.

We’re always happy to answer your questions. Just send us a tweet @EasyAgile or contact us if you’re not sure about what user story mapping is, how to do it, or how it could help your team.

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.”

Nicholas Muldoon, Co-Founder @Easy Agile

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 espond 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.

Moreover, 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. This flexibility ensures that your team can swiftly adjust priorities and modify plans as new information or changes arise, maintaining alignment with Agile principles.

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.

Epics

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.”

Nicholas Muldoon, Co-Founder @Easy Agile

User-story maps are powerful tools in product development, particularly when it comes to identifying and managing risky assumptions.

Visualizing risk

User-story maps provide a visual framework that highlights potential risks. By mapping out user stories with sticky notes or digital alternatives, it's easy to pinpoint areas where assumptions might not align with real user data or technical feasibility. This visualization helps teams identify elements that could derail a project’s timeline or budget.

Prioritization and resource allocation

Once risky assumptions are identified, user-story maps allow teams to reorganize priorities effectively. Risky elements can be moved to a lower priority, ensuring that resources are allocated to ideas that offer high value with minimized risk. This strategy ensures that projects remain on track, focusing on what's realistically achievable.

Encouraging lean alternatives

Story maps encourage teams to explore lean alternatives first. By testing simpler ideas with similar value propositions, teams can validate concepts without significant investment. This approach allows for learning and iterating, reducing the likelihood of costly failures later in the development process.

Fostering collaborative problem-solving

The process of creating and updating a user-story map is inherently collaborative. It invites diverse team members to contribute insights, leading to more comprehensive risk identification and resolution strategies. By pooling knowledge, teams are better equipped to address assumptions that might otherwise go unnoticed.

Incorporating these practices into your product development cycle can help mitigate risks early, ensuring a smoother path from inception to launch.

There are so many other benefits to user story mapping too, 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
• 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 cross-functional 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 participate 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
• Developers
• Testers
• Marketer
• 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.

Sequencing

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.”

Nicholas Muldoon, Co-Founder @Easy Agile

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
• Play 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.

Results 🏆

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.”

Nicholas Muldoon, Co-Founder @Easy Agile

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

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:

Easy Agile TeamRhythm Free Trial

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

TeamRhythm Highlights Tour

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.

- Paul Flye Sainte Marie, Agile and Tools Referent @Kering

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.

- Mike Doolittle, Product Director @Priceline

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

- Casey Flynn, Distribution Forecast Analyst @adidas

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

- Rafal Zydek, Atlassian Jira and Confluence Expert Administrator @ING Tech Poland

See what all the fuss is about

Start your free 30 day trial

Easy Agile TeamRhythm

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.

A sprint backlog is like an agile team's treasure map — checking off each item is like visiting a different place on the map. By the end of a sprint or iteration, the team will have delivered previously agreed outcomes and ultimately achieved their sprint goal. This is like getting to the ✖️ on a treasure map.

Join us as we find the answers you need to successfully complete each sprint. You'll learn about a sprint backlog’s purpose, plus who creates, owns, updates, and uses it.

What's a sprint backlog?

A sprint backlog consists of the items that need to be completed in order to get to the sprint goal. It should go into artifact during the sprint planning meeting. A sprint backlog has three parts:

• The sprint. Each sprint backlog targets a specific iteration.
• The sprint goal. This is the higher level aim for each sprint. To achieve it, the development team completes certain items from the product backlog.
• A plan. The sprint backlog represents a plan to deliver a product increment by the end of the sprint. It's organized to allow for progress tracking with to-do, in-progress, and done items, plus effort estimations and remaining workload.

The sprint backlog should always be accessible and up-to-date so that the development team understands the work and can see what is coming up next. It should also have enough detail to allow tracking work progress.

Each sprint starts with a sprint backlog, and the artifact's lifespan equals the sprint's duration. You may expect to find work items — user stories, tasks, or bugs — in it.

The sprint backlog is the development team's go-to home to find all the ideas for what to work on. At every Daily Stand-Up,, the team looks at it to let others know what they did the day before. Additionally, they recall or adjust priorities based on what they need to do for the next day(s).

🧐 During the Daily Stand-Up, developers also use the sprint backlog to evaluate the sprint's progress.

The sprint backlog is not only a way of keeping the development team's eyes on the prize. 👀 It's also a way to discuss how well they achieved the sprint goal.

At any point in a sprint, to-do, in-progress, and done items are included in the sprint backlog for anyone to review and use to calculate the remaining workload. This helps verify if the development team is on track to achieve the sprint goal. ✌️

Jira provides a burndown chart to check the development team's work. This displays the remaining workload for the current sprint. In addition, the chart shows:

• Work in progress
• The distribution of work throughout the iteration

A Jira burndown chart also helps evaluate whether additional items fit into the sprint and effort estimations were accurate.

🛑 Keep in mind that you don't need a sprint backlog if you follow the Kanban framework. That’s because Kanban isn’t about working in timeboxes (the sprints).

Now, the sprint backlog isn't an off-the-shelf artifact that you can use in your project — every project is unique. So, someone must be responsible for populating the sprint backlog with work items.

Besides defining what a sprint backlog is, we should discuss what sets them apart from product backlogs.

Sprint backlogs vs. product backlogs

Though their names are similar, a sprint backlog and product backlog serve different purposes. A product backlog is:

• A collection of work items to either bring a new product to the market or improve an existing product
• A list of work items to tackle in the future
• A set of work items arranged by priority, with the most priority at the top
• The source of the sprint backlog items

On the other hand, a sprint backlog is:

• A subset of work items from the product backlog
• A group of items to work on during the next sprint

Here’s how the two backlogs meet: The product backlog provides work items for a sprint backlog. And, by the end of a sprint, the team might transfer incomplete work to the next sprint or the product backlog. If the work items have high priority, they should go into the next sprint. If not, they should go into the product backlog for a later sprint.

Essentially, a product backlog covers a greater amount of time than a sprint backlog. However, like the sprint backlog, the product backlog might evolve to reflect changes in the market or customer needs and, the development team needs both in order to deliver product changes.

Now, the sprint backlog isn't an off-the-shelf artifact that you can use in your project — every project is unique. So, someone must be responsible for populating the sprint backlog with work items.

Who owns and creates sprint backlogs?

Here are the team members involved in creating sprint backlogs:

• The Scrum Master. During the Sprint Planning ceremony, the Scrum Master uses the product backlog to create the sprint backlog — the output. However, the Scrum Master doesn't do it alone.
• The development team. When moving product backlog items to the sprint backlog, the Scrum Master considers the development team's input. ⚖️
• The Product Owner. The Scrum Master needs the Product Owner's agreement to include product backlog items in the sprint backlog. 👌 And if the development team has questions about the product backlog, the Product Owner is the one to ask.

The sprint backlog's creation is one part of the agile workflow that shows how essential teamwork is to agile. Nevertheless, the sprint backlog must always be owned by someone throughout the workflow. Otherwise, these artifacts can get lost and become outdated.

Scrum methodology says that the whole agile team owns the Sprint Backlog. And by "agile team," we mean the Scrum Master, the Product Owner, and the development team.

That’s because all agile team members contribute:

• The Product Owner knows what the development team should deliver by the end of the sprint. Plus, they order product backlog items by priority. In other words, the Product Owner constrains the product backlog items that should go into the next sprint backlog.
• The Scrum Master has enough experience to distribute the development team's work throughout the sprint. When considering sprint backlog item dependencies, that distribution makes the most sense.
• The development team knows how long similar Sprint Backlog items take to complete. ⏲️ This means they can determine the sprint goal's feasibility within a certain time frame.

Remember, the sprint backlog is a living document, so team members should update it as needed. Let’s look at how a sprint backlog can change.

Updating the sprint backlog

The sprint backlog should adapt to answer market trends and customer needs as they arise. Those changes might influence items in the product backlog and how they’re prioritized. As a result, the sprint backlog changes.

Let's have a look at what may cause a sprint backlog to change and who makes the updates:

1. Effort estimations were not accurate enough. If the development team realizes that some work items will take longer than expected, they should raise a 🚩. They should then negotiate the scope of the sprint backlog with the Product Owner without compromising the sprint goal.
2. A new, higher-priority user story, task, or bug comes up. If that happens, the development team should add it to the sprint backlog. That might impact the sprint's duration or push some items to the next sprint.
3. Progress in completing a user story or a task or solving a bug changes daily. As this happens, the development team should keep updating the remaining workload they estimated for the current sprint. And they should do it during the Daily Stand-Up or Daily Scrum meeting. Once the development team finishes all the work in the sprint backlog, they achieve the sprint goal. This means the development team implemented the product increment, which is ready for delivery. 📦
4. A sprint backlog item is no longer needed. This might be due to a shift in the market or customer needs. If that happens, the development team should remove the item from the artifact. 🗑️
5. The development team better understands sprint backlog requirements as the sprint continues. So, they might realize that to achieve the sprint goal, they need to include more items in the sprint backlog.

The sprint backlog: A guide for sprint success

A sprint backlog is a guide for completing a sprint goal. This means that its lifecycle is short and equals the iteration's duration. It's a visual representation of the sprint that supports Scrum team discussions on in-progress and to-do work.

This backlog may also be the most reassuring Scrum artifact for developers, as it assures them the work is organized and no additional work items will fall from the sky without their knowledge. If the workload must increase, the team will debate it and weigh the developers' experience-based opinion.

With a sprint backlog, the team perfects its ability to plan sprints, estimate effort, and allocate resources. They learn how long work takes and how much of it fits into a sprint. And by learning this, the team learns the resources they need to get to the finish line.

Easy Agile TeamRhythm is collaborative sprint planning tool that helps your team with the shared context that the story map format provides. TeamRhythm helps your team to:

• Visualize a meaningful picture of work on the user story map, sequenced into sprint swimlanes
• Create, estimate and prioritize user stories right on the story map
• See comitment at a glance with sprint statistics and sprint goals displayed on each swimlane

Try planning your sprints with Easy Agile TeamRhythm. We’re confident it will help your team collaborate even more seamlessly.

Do your teams have a clear understanding of what needs to be done – and why?

One of the keys to being agile is to focus on the work that matters. This means working on projects that add value to the business and contribute to performance. But for many organizations, teams can get caught up on the latest feature or development, without understanding how that relates to the bigger picture of what the business cares about.

To keep your team focused on what they have set out to achieve in order to deliver value and achieve business outcomes, setting smart PI Objectives is essential. We look at why they’re so important, what makes a good PI objective, and how you can use them in your organization.

At a glance:

• PI objectives help teams understand how what they’re doing matters to the business.
• Good PI objectives are SMART – specific, measurable, achievable, relevant and timebound.
• Linking features to PI objectives within the same tool makes it easier for teams and stakeholders to see how work is achieving business objectives.

What are PI objectives?

When an agile team gets together for a PI planning session, there are two key outputs:

1. The Program Board (ART Planning Board in SAFe 6.0) covers big picture information such as features, dependencies between teams, and milestones. A feature is an agreed upon piece of work identified as being important to meeting business needs. For software development teams, this might be a new product feature. For marketing teams, it might be a website refresh or an advertising campaign.
2. PI objectives link the scheduled features to broader business objectives and value. This helps align work that needs to be done with broader business goals. They are then broken down into committed and uncommitted objectives.
   1. Committed objectives are those the team is confident they can deliver within the Program Increment. These objectives have been committed by the team through a confidence vote.
   2. Uncommitted objectives are those the team have low confidence in delivering but can help to build a buffer into the PI. This is because while the outcome of these objectives may not be certain, they are included in the teams capacity and plan for the PI should capacity remain after delivering on committed objectives.

The benefits of having smart PI objectives

PI objectives link what teams are working on to what the business cares about. They create alignment with business objectives by clearly connecting features to business value. As a result, teams know how their work is adding value.

Smart PI objectives provide a framework for this. They help build trust, create a shared language, and provide a clear direction. Everyone in the team can then understand what they’re doing, why they’re doing it, and why it’s important.

Without smart PI objectives in place, teams can spend time on tasks that aren’t adding value to the business and impact agility.

PI objectives are essential to your ability to measure success. Completing features alone isn't enough - they must drive a business outcome. They help get teams clear on why the work they do matters and define what success looks like.

What makes a good PI objective?

We’ve talked about why PI objectives are so critical, and now we’ll explain what makes a good PI objective.

Good PI objectives:

• Allow the business to see deliverables in a set timeframe
• Provide clarity on how scheduled work  fits into the big picture
• Enhance communication between teams and stakeholders
• Include no more than 7 to 10 objectives in total
• Aligns with what the business cares about
• Are clear on why it’s important and what it will deliver
• Are understood by anyone who picks them up

Are SMART – that is, specific, measurable, achievable, relevant and timebound

PI objectives need to be SMART

Using the SMART goal-setting framework to write your PI objectives helps keep your objectives clear and concise. Under this framework, your PI objective needs to be:

• Specific – Clearly and explicitly state the intended outcome of your objective.
• Measurable – Describe what your team needs to do to achieve the objective and how they will quantify success. Stakeholder feedback should form part of this.
• Achievable – Ensure the objective is realistic and within your team’s control and influence.
• Relevant – Align the objective with overall business objectives.
• Timebound – Set an appropriate timeframe to achieve the objective within the PI.

Team PI objectiveEnsure Easy Agile server customers have a seamless option to migrate to cloud by implementing JCMA and site import/export by the end of Q3.

Tips for writing SMART (and smart) PI objectives

Typically, many teams will run PI planning sessions in one tool, and then use another tool (like Confluence) to record PI objectives.

But separating PI objectives from the planning sessions makes it hard for the team and stakeholders to see how the work is shifting the dial for the business.

With the Easy Agile Programs, you can directly link your features to your objectives within the same tool. You're also able to describe the objective within Easy Agile Programs and assign business value:

By connecting features to PI objectives within the same tool, teams and business stakeholders gain clear visibility of work. They can see how their work is helping to achieve business objectives.

Learn more

Using the SMART framework to define PI objectives helps your teams focus on the right work. They align projects with broader business goals while providing a shared understanding across teams. By working towards the same purpose, they help keep your teams and organization productive and agile.

You can with Easy Agile Programs

Ready to bring your PI Objectives into Jira?

Watch Demo

I was fortunate enough to travel to San Diego for the recent Global SAFe Summit. It was there that the folks from Scaled Agile Inc. unveiled SAFe 5.0 to the audience of 2,100 people from all around the world.

Like many in attendance, I was both excited and overwhelmed with all the changes including the refreshed Big Picture, renewed focus on customers and concepts of Business Agility just to name a few.

After the long flight back to Australia, and having had time to share my learnings with the team, we're super excited about what these changes mean for scaling organizational agility and we wanted to share a few of them here with you.

What's new in SAFe 5.0

1. Introduction of Business Agility

How is this different? Business agility now incorporates the whole business in the move towards value streams rather than individual departments.

2. Refreshed look and feel to the SAFe Big Picture

3. New SAFe Overview

4. SAFe 5.0 'revamps' 2 of the Core Competencies of the Lean Enterprise:

• Agile Product Delivery from DevOps and Release on Demand
• Enterprise Solution Delivery from Business Solutions and Lean Systems Engineering

Plus, Addition of 2 new Core Competencies:

• Organisational Agility
• Continuous Learning Culture

5. A 10th SAFe Principle was announced

NEW: Principle #10 - Organise Around Value

Why are we excited about SAFe 5.0?

It's not the updated Big Picture diagram, or the more approachable and "business friendly" overview that has us excited about SAFe 5.0. What we're more excited about than anything, is the renewed focus on customers - hooray!

While we enjoyed playing a customer version of 'Where's Wally?' in previous SAFe Big Pictures, this renewed focus on customers represents a shift in the level of maturity of organizations adopting SAFe.

They are no longer at a point where "doing" agile is their primary objective. This shift towards customer-centricity embodies what it truly means to be agile, where satisfying the customer is our primary objective.

We've also seen this shift more broadly, as customer/user satisfaction was cited as the #1 success metric for both agile initiatives and individual agile projects in this year's #StateOfAgile report.

How does SAFe 5.0 encourage customer centricity?

The revamped Core Competency of Agile Product Delivery (previously called DevOps and Release on Demand) is what really has us using emojis like ❤️ and has us feeling jazzed.

The DevOps and Release on Demand competency was all about "delivering value to customers" by forming value streams and optimizing continuous delivery pipelines to ship stuff into the hands of customers quickly.

The idea that value to customers = shipping working software more regularly is 💩.

A bad feature is still a bad feature no matter how much faster it lands in the laps of customers. Worse still, a bad feature that your customers don't use, didn't want, or doesn't make them better at their job...... I think you know where I'm going with this.

This revamped Agile Product Delivery competency instead places the focus waaaaaayyyy before anything is actually built - the first order of business should be having a customer-centric mindset by:

• focusing on the customer
• understanding their needs
• thinking and feeling like the customer #bethecustomer
• building a whole product solution
• knowing the customer lifetime value

How do we achieve customer-centricity?

Putting customers at the center of all decisions and incorporating Design Thinking practices into the mix well before we even think about building anything is key to achieving customer-centricity.

This all sounds great, but what does this look like in practice? The diagram below is probably our favourite asset in the entire SAFe catalogue and we think it showcases practical examples of Design Thinking in practice:

Our personal favourites

Personas 💁🏽‍♀️

It might seem trivial at first, to come together as a team, creating what seem like fake dating profiles for your customers.

However, this exercise sets the foundation for other agile practices down the track, and its perceived benefits are often undervalued.

Teams that have a shared understanding and alignment around the types of people using the solution they are delivering are more likely to succeed.

We want to make sure we're building the right solutions, for the right people, to help solve the right problems at the right time, otherwise we risk the following scenario:

Knowing the customer deeply is no longer the sole responsibility of a (traditional) Sales and Marketing team. Agile practices have called for the development of cross-functional team members to step up and help connect with customers.

Related blog post: how to create personas with your team.

It's no secret as the makers of Easy Agile TeamRhythm that we love user story maps (shameless 🔌).

So what about this agile practice do we love so much that we decided to form a business off the back of it?

The purpose of engaging in this activity is to create a shared understanding of who our customers are, how they interact with our products and how we should focus our development efforts on stories in order to provide our customers with the most value.

In other words, it gives us a way to say, ok I'm working on building this user story, I know who the user I'm building this story for is, and I can understand which part of the customer's journey this will be directly impacting.

We believe this shared understanding is incredibly powerful for both building with empathy and putting our customers at the heart of of all our development decisions. We believe this practice exemplifies what it means to be customer centric, and that's why we ❤️ it.

Verdict

Easy Agile welcomes the big changes introduced in SAFe 5.0, especially calling out customer-centricity, design thinking, and business agility. We can't wait to see how our customers start introducing this to their teams.

Get ready for remote user story mapping.

Whether you've done user story mapping before (in person) or you're new to user story mapping, there's a very good chance that you'll need to do remote user story mapping for the first time in 2020.

Even before the pandemic, 4.7 million people in the US worked remote, and an estimated 31% of US workers employed in March 2020 were working from home by April 2020.

And after lockdown ends, it’s likely we’ll see permanent changes to the way we work. Surveys show that 80% of employees are keen to work from home at least some of the time. Plus, more organizations are realizing that offering flexible, remote work options can lead to better work-life balance for employees, lower overheads, lower environmental impacts, and improved productivity.

...which is all to say that remote user story mapping is about to be the norm.

So, what do you need to know before you run your first online user story mapping event? Let's go through 8 things you should consider for successful remote user story mapping.

1. Get the basics right

First thing's first: you need your basics sorted. Make sure your team understands what user story mapping is, why user story mapping is important, and how to do it.

This will help get them onboard - which is critical, because you'll need them to commit two full days to the process.

If anyone on your team is new to user story mapping, send them to our user story mapping ultimate guide. It's got everything they need to know 👌

2. Set your agenda

User story mapping should be a scheduled event. You should know what's happening and when to make sure that your team stays on schedule and completes all the steps required to produce a finished story map. Here's a fairly standard agenda:

Knowing your agenda is especially important for remote story mapping, because it's a lot easier to veer off track when people aren't physically in the room.

Sally might head to the kitchen for a long lunch and miss the most important bit. Or Bob might need to coordinate his schedule so that his partner can mind the kids for a solid hour or so while he's involved in estimating the work.

Setting the agenda ahead of time will also help your team start thinking about the session and user stories before the event. That way, they’ll feel more prepared and ready to participate in discussions.

By the way, if you’re not familiar with all the items in the above agenda, we talk more about the specific steps and how to do user story mapping in our ultimate guide to user story mapping.

3. Plan your session

When are you going to hold your live online user story mapping session? Most teams need a full two days to work through all the steps, so you'll need to find two days (ideally in a row) when everyone is available.

If your team is located across multiple time zones, you'll also need to consider what times give you the best crossover so that team members aren't working at 2 am (unless they want to).

4. Decide on who

Remote user story mapping could present you with a bit of a conundrum. Unlike in-person events where you're limited on space, you could technically have unlimited people chime into your virtual session. But you definitely don't want that - too many people will make you inefficient (and they could use their time to add value to your business in other ways).

It’s a good idea to cap your numbers at around 12 people. Include team members and stakeholders across multiple departments, along with your product manager, UX designer, and developers.

Also decide who is going to lead the session and who will be responsible for creating the story map.

The good news is that online user story mapping makes it easy to record sessions - you'll have a digital record of your conference calls and your story mapping board. So anyone who's curious can easily catch up on the highlights once your event is over.

5. Make some rules

Working and collaborating remotely can feel a bit like the wild, wild west - especially the first few weeks or months. Everyone's still figuring out how to make this thing work - and how to get things done effectively in a new environment.

We've all been to conference calls where somebody didn't know proper etiquette or their audio/video ended up distracting other attendees.

So, with that in mind, here are some rules you might like to share ahead of your remote user story mapping session to make it a little less chaotic and a lot more productive:

• Don’t be late
• Put your camera on
• Save your food for a designated break
• Don’t take your device for a walk
• Close your door, if you can
• Stay focused on the task (no checking emails!)
• One person talks at a time
• Wait until everyone has had a chance to provide input before moving on
• If you’re not talking or participating in the conversion, mute yourself (to avoid interference or background noise that could stop people from focusing)

Of course, be realistic. Your team members are likely working from home in less-than-ideal circumstances, whether they're quarantined with family members, stuck at home with a sick child, or dealing with a bad-mannered house dog.

There will be noise and disruptions - and despite their best efforts, someone will be late. As long as people do their best to hit the mute button at the right time and consider others, your session should run smoothly.

6. Get your tech ready

Previously, you might have been able to show up to a user story mapping session with just your brainy self and a pen 🧠🖊️ You'll still need your brain for remote user story mapping, but you can ditch the pen.

Instead, you'll need to make sure you and your team have access to the technology they need to participate and collaborate online. Things like:

• Zoom, Google Hangouts, or Skype access - Everyone should have their account ready to go, along with some experience using the platform
• Slack or Microsoft Teams - Set up real-time chat for when you’re not in a video conferencing session
• Headphones & Microphone - These should be working well and tested ahead of time
• Webcam - While not strictly necessary, a webcam will help you replicate the feeling of being in the room together
• Internet - Ask your team to test their connection and make sure it's reliable - and ideally, have at least one backup option (like a local cafe, friend's house, or mobile hotspotting)

The right technology will allow you to adapt the user story mapping process to work for your remote team.

7. Get user story mapping software

A physical user story mapping session usually involves a long sheet of paper or cardboard, with hundreds of tiny post-it notes for each story and backbone item, and string to show cut lines.

The good news is, if you're doing remote user story mapping, you won't need to clear out your nearest stationery supply store 🎉 But you will need to equip yourself with some digital tools to replicate the physical story mapping board online.

There are a few user story mapping tools on the market, but we're partial to Easy Agile User Story Maps. It plugs straight into your existing Jira workspace, allowing you to:

• Visually map your customer journey
• Assign stories to epics
• Prioritize and sequence stories
• Arrange stories into sprint and version swimlanes
• Add story point estimates

It’s just like physical user story mapping, but done digitally inside of Jira. That makes it perfect for running a remote user story mapping session.

Okay, so we may be a little biased, but these people aren't:

Want to give it a spin for your upcoming remote user story mapping session? Sign up for our free 30-day trial to see the benefits for you and your team. We’re confident you’ll love what you find!

Try it now

8. Integrate your workflow

Last but not least, make sure that your remote user story mapping session integrates with your workflow

Good news! If you use a digital user story mapping tool (like Easy Agile's), you'll find it much easier to integrate your story map into your workflow. Once your user story mapping session is finished, your user stories are already set up in Jira, and organized into sprints or versions so that your team knows exactly what they need to work on next.

(Although they might want to take a day or two to ease back into it...😴)

Set yourself up for success!

With the right preparation and tools, you'll set yourself up for a relatively smooth remote user story mapping session. And after that? You'll be set to do your future story mapping events in a more streamlined, digital way, whether you're required to work remotely, collaborate with a distributed team, or work from the office.

And based on the way work is changing in 2020 (and beyond), that's a very good skill to have.

We often get questions about why product roadmaps are considered an agile tool. To some, it seems quite “un-agile” to set concrete dates for a long list of tasks you will likely never get done.

That assumption couldn’t be more wrong. It presumes that a product roadmap is an old, overdone practice more akin to Waterfall predecessors like the *cough*Gantt Chart *cough*. This is not the case. Gantt Charts are for task dependency, and they assume that work will be completed in a linear fashion.

On the other hand, a true product roadmap is completely subject to change. It’s a living document meant to serve as a guide. The roadmap shows what a team needs to accomplish to create specific features or otherwise complete tasks that will provide the most value to customers in a certain timeframe.

This flexibility allows product development teams to make the most informed choices. To help teams do this, we built the simplest and most flexible roadmapping tool for Jira (more on this later). Here, you’ll learn about the benefits of using product roadmaps, the guiding principles of the roadmapping process, and how to use roadmapping tools effectively.

What is an agile product roadmap?

Agile is a broad term for a non-linear way of working that prioritizes flexibility and collaboration. This working style helps teams iterate as they go rather than stick to a rigid plan that doesn’t adapt to new information.

Think of agile as the complete opposite of an assembly line process for making a product. An assembly line has a strict plan where one step happens after the next. Each piece falls into place one after another without extra input or iteration.

🖍 Great for an assembly line of Crayola products, not so great for software development. 📱

Rather than use the assembly line approach, agile teams work collaboratively and iteratively on new products in order to detect roadblocks early, before they can cause a delay. And, Product teams use agile tools to provide clients and stakeholders value on a consistent basis.

Basically, agile product roadmaps are key to producing a great product.

They provide a smooth and collaborative planning process for development teams while maintaining the strategic objectives and product vision stakeholders expect. On top of all that, the flexibility provided by agile product roadmapping delights customers by consistently meeting their evolving needs, whims, and desires.

The benefits of roadmapping for product management

There are many benefits of roadmapping for everyone involved. Roadmapping assists product managers, helps the development team collaborate, gives stakeholders a clear view of the process, and ensures customers are continually pleased with product features and functionality.

Effective roadmap tools can provide the following benefits:

• Enable teams to align their vision around product features
• Provide a clear visual of the most critical prioritizations
• Ensure short-term product goals are met as soon as possible while monitoring and adjusting long-term goals
• Align all team members on what’s most important at any given time
• Keep track of specific product launch and release dates
• Maintain the product vision and business goals
• Ensure all stakeholders can view and give feedback on the current product plan
• Ship a product and solve issues relatively quickly
• Bring constant value to stakeholders and customers

For most teams, it’s truly the beating heart of product development.

4 guiding principles to get the most out of your product roadmaps

We’re obsessed with roadmapping and the many agile strategies that help teams work more effectively. So, we pulled together a list of the most important guiding principles that will ensure your agile team gets the most out of your product roadmap.

1. Focus on themes of work, not features

In the simplest form, themes represent high-level groups of work (like epics). In an agile product roadmap, themes should be customer-focused, unlike traditional waterfall roadmaps where themes tend to focus on business objectives.

Examples of themes include:

• Customer onboarding experience
• Reducing tech debt
• Customer satisfaction and engagement

By grouping work into themes, teams are able to tell a story about where they are headed as well as the goals, objectives, and outcomes that will get them there. User stories provide high-level visualization so that teams can answer critical questions:

• What are we doing?
• Why are we doing it?
• How does it link back to our Objectives and Key Results (OKRs)?

2. Think of the roadmap as a living document

Product managers need to educate their stakeholders on the true purpose of the product roadmap to manage expectations and ensure everyone is on the same page.

A product roadmap is not a promise. It’s a living document that’s meant to serve as a flexible guide.

You need to teach all stakeholders that the roadmap represents chunks of work, such as new features, functionality, and metrics customers value most at a specific period of time. It’s inevitable and expected that customer needs and preferences will change. The roadmap should be adjusted and amended to reflect these changes as time goes by.

The agile product development process should change to maximize the value customers experience. This is what it’s all about!

3. Actively collaborate with stakeholders

Involve everyone in the process, including internal stakeholders, external stakeholders, and the full development team when planning, reviewing, or adjusting the roadmap.

The product manager doesn’t need to be the only one representing the customer’s voice. By gaining the perspective of developers, the sales team, customer support, and engineers, you get a holistic view of the customer experience. This will give you a clear view of what your customers value to determine what should be done when.

4. Ensure the roadmap is accessible to all stakeholders

The product roadmap should be the team’s single source of truth, representing the plan of execution against the company's Objectives and Key Results (OKRs).

Understanding what’s going on and why each person is doing what they’re doing is crucial to establishing transparency and confidence in your team.

The roadmap represents the team’s overall vision for a period of time. Ensuring the roadmap is accessible to all stakeholders achieves organizational alignment.

Product strategy with Easy Agile roadmaps for Jira

We teased above that we’d tell you more about Easy Agile Roadmaps. We designed the simplest and most flexible roadmapping tool for Jira. Our roadmap software helps teams align around a product vision to sequence the most critical features for customer delivery.

Easy Agile Roadmaps are designed for everyone involved in the product development process from the product manager to the dev team to key stakeholders and customers. It works seamlessly with both Scrum and Kanban Jira Software boards. And, of course, it’s completely agile. Like, Simone Biles flexible.

Say goodbye to clunky Excel sheets, one-off Powerpoint presentations, and static Gantt Charts. Easy Agile Roadmaps can create a visual roadmap timeline that’s flexible, iterative, and easy to use. Split scheduled work, add date markers, use Quick Filters, track your progress, and export the roadmap as needed. The tool uses a simple drag-and-drop functionality for a clean user experience, no matter the needs of your team.

We’re so sure you’ll love it, you can try it free for 30 days. If you have any questions, our team is ready and waiting to hear from you, or watch an on-demand demo of our roadmapping app in action.

There are infinite learning opportunities available when it comes to using Jira to help you make the most of the tool. From Jira tutorials to Udemy courses to an Atlassian certification, you can continue to hone your skills and learn from others.

There’s always more to discover. Brush up on skills, advance your career, and gain certificates that can land you your dream job. Continued learning can make you an indispensable MASTER of all things Jira within your organization and around the world.

Read our list of recommended Jira tutorials, training, and certifications that will start you on the path to Jira mastery.

Why agile teams choose Jira

Jira is an agile project management tool developed by Atlassian. It began as a software development application for devops teams but has evolved to help modern workplaces practicing agile methodologies augment their process.

The software is widely used for bug tracking, issue tracking, and addressing performance improvements based on real-time data. And the online functionality reduces the physical dependencies of managing a project as a team — something that grows more important to businesses every year.

Fun fact: The name Jira is the truncation of Gojira, the Japanese name for Godzilla. Atlassian recommends yelling it loudly as if you were charging into battle!

Jira is widely used by nearly every development team because it takes a customer-first approach to designing products. Jira allows for extensive customization to help teams meet the needs of their customers.

How to choose the Jira learning that's best for you

Follow these tips when selecting how to receive further Jira training and education:

• If you are pursuing training to advance your career, you may want proof of course completion, either from an Atlassian University training course or a Udemy course, to provide potential employers.
• If you are interested in becoming an Atlassian Certified Professional, you’ll need certification through Atlassian University.
• If cost is a barrier, begin with the free tutorials available from Atlassian University.

Jira tutorials, training, and certifications from Atlassian

Our list will begin with learning opportunities from Atlassian University (since they know Jira best), and then we’ll expand to tutorials, training, and courses from other online sources below.

Atlassian University

Atlassian offers several free Jira tutorials for both beginners and pros, so you can gain confidence with product skills that cover exactly what you need to get started and beyond. The Jira tutorials are clearly labeled with a timestamp to help you plan your schedule.

Each short Jira tutorial is grouped into a series based on a range of topics, beginning with the very basic to the more specific, including:

• Getting started with boards in Jira Software
• Jira Essentials with Agile Mindset
• Getting More from Jira Workflows
• Automating Jira

Some tutorial series are short enough to complete on a lunch break, whereas others will take a few hours. So instead of doomscrolling while you eat your sandwich, pull up a quick tutorial to advance your skills! 🥪

If you hope to earn a certification, but you’re not entirely sure which specific training courses will get you there, Atlassian has role-based learning paths to guide you on your way.

Atlassian University — Jira certifications

To finally and officially cement yourself as a Jira Jedi Master, you can become an Atlassian Certified Professional and the go-to expert for all things Jira. Plus, all Atlassian certifications are globally recognized, so wherever you find yourself, Atlassian will be with you.

A number of different certifications are available depending on your chosen skillset. To achieve a certification, you’ll need to take the courses available through the above training link, gain real-world experience, and take an exam.

Other Jira tutorials, training, and courses

While Atlassian University is filled with learning opportunities, plenty of other resources will help you grow from beginner to expert and from expert to master.

Top Udemy Jira courses

Udemy Jira courses offer a wide variety of topics at a range of prices for those just starting out with Jira and old pros. Students can access broader topics like agile and project management as well as Professional Scrum Master (PSM) courses to prepare you for your certification.

Courses come with a rating based on the experience of past students. And considering that over 200,000 students are learning Jira on Udemy, you’ll be able to see which courses are well-reviewed to help you decide.

From beginner crash courses to more advanced or niche topics, there’s something for everyone. They also offer free “bite-sized” Jira lessons with videos 3 to 11 minutes long, so you can fit them into any busy schedule. Plus, all courses come with a 30-day money-back guarantee.

Expium’s Atlassian courses

Expium offers workshop-based Jira training for enterprise Atlassian customers. The courses aim to equip students to competently configure Jira with a range of workshops covering beginner basics to more specific topics.

The hands-on learning is available for public, private, or online classes. Expium is a Platinum Solution Partner, which means, according to Atlassian, they meet the highest training criteria and have a proven practice that can scale from small to large customers.

Guru 99 Jira tutorial: How to use Jira software for beginners

Guru 99’s free online resource is for beginners as well as those who need to brush up on the basics. It provides a step-by-step guide for using the Jira dashboard.

The resource outlines detailed use cases with annotated screenshots from the Jira tool. The detailed imagery shows the basics of creating issues and managing issue attributes as well as more specific uses, like how to set up workflows, clone issues, and create custom fields.

Guru 99’s Jira tutorial includes:

• Jira issues and issue types, such as new features, sub-tasks, bugs, etc.
• Jira issue attributes, such as in progress, open, closed, resolved, etc.
• Jira components
• How to create issues in Jira
• How to create sub-tasks, workflows, plugins, epics, and clones
• Security schemes and permission schemes
• Jira reporting and burndown charts
• How to generate a pie chart of priorities

Now it’s time to get out there and learn! Successful people know that learning never stops.

Bonus resource: Continue learning on the Easy Agile blog

And hey, we’ve got extensive learning resources on our Easy Agile blog, too! From understanding the difference between Kanban and Scrum, using epics to maximize performance, and knowing best practices for Jira workflows; you're in the right place.

Easy Agile is dedicated to helping teams work better with agile. Our apps for Jira are designed to keep the customer top of mind through every step of the product development process. They’re simple, collaborative, and made by a development team that lives and breathes Jira.

Contact our team to learn more or request a demo tutorial to see our plugins in action.