User Story Mapping

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.

Do you know your customers? As in, really know them?

🥞 What do they eat for breakfast?

😎 Who’s their favourite James Bond villain?

🛁 Do they shower in the morning or at night?

Okay, so you don’t have to get that creepy…

But you do need to know a lot about the customers you’re developing products for. Otherwise, the features you’re working on might not be useful or valuable.

This is pretty important stuff, so let’s take a look at 7 reasons why it’s good to have a healthy level of customer obsession in your agile teams...

1. Agile and customer focus go hand-in-hand

Agile is all about the customer. At least, it should be.

It’s right there in the first two agile principles:

(1) Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

(2) Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

You can’t really call yourselves agile unless you put your customers at the centre of what you’re doing.

2. Each sprint should deliver a better product for your customers

One reason why agile should (🤞 in theory - we’ll expand on this shortly) benefit your customers is that every two to four weeks, your users will usually get new features and upgraded products.

This is kind of a big deal when you compare it to traditional project management approaches.

Pre-agile, customers could be waiting many months or even years before they would see any changes. In many cases, by the time updates were released, customers, technologies, and requirements had moved on.

But when you’re agile, it means that:

• Your customers can request updates, features, and changes at any time
• Users should potentially see new features added to a roadmap and rolled out in weeks or months, not years.
• If something’s not working, your customers can report the issue and provide feedback right away
• Users can see how the product is developing and growing
• Your product is moving forward and the customer is moving forward with it
• The product becomes more valuable to your customers over time

… but it’s important to note that all of these really awesome benefits only really apply if you’re prioritising your backlog and choosing features with your customers’ best interests at heart 💞

3. Agile teams need to know what’s valuable to their customers

As we’ve talked about previously, “there is a chasm between the output of a team and successful outcomes for their customers. And the success of a team is measured by outcomes, not code.”

Fact is, your customers have different priorities to your developers.

Your developers likely want to work on projects that they find exciting or fulfilling. But the best agile teams know they need to prioritise the features that matter to their customers. Because if you’re not solving their most important problems, your customers will find someone else who will solve them 😨

4. Customer focus leads to better quality products

When you’re obsessed with your customers, you deliver products that actually matter.

One study found that “quality is influenced by top management’s commitment through customer focus”.

And this makes sense - if your team stays focused on your customers, there’s a much better chance that they’ll build the right things at the right time for the right people. And this is critical to the success of your product and organisation.

It’s also a great way to avoid building bloated products with unnecessary features.

5. Do better planning and prioritising

Your backlog shouldn’t simply be a to-do list. It needs to include feedback from your customers and attempt to tackle their greatest pain points.

Program Increment (PI) Planning in scaled agile relies on a healthy customer obsession to inform your product requirements.

During PI Planning, you’ll discuss the backlog with other teams in your Agile Release Train (ART), prioritise your features, and schedule work for the upcoming iterations.

Without a solid understanding of your customers to inform your backlog, you could end up planning an entire increment that doesn’t deliver anything useful or move the product forward for users. And that’s a pretty costly risk, if you ask us.

6. Do everything better with customer feedback

Teams who are obsessed with customers love getting customer feedback, whether it’s via customer interviews, surveys or just having a chat about their experience 🤓

Customer feedback is incredibly powerful because it can help you:

• Understand your customers - Know what their biggest problems are and what they care about most
• Motivate your agile team - Help your team understand the problems they’re solving, the difference they’re making, and that their work is meaningful
• Spot trends and patterns - Ensure your product adapts to what’s in demand right now and what your customers will need in the future
• Make better products - Find out what’s not working so you can fix it
• Track your progress - See whether customers are happier with your product over time
• Stay relevant - Because products and companies that solve problems stick around long-term
• Get buy in - When your customers are involved in the process, they’ll feel more committed to the product, which can reduce churn
• Improve retention - Reduce churn and keep your customers for longer when you incorporate their feedback and ideas into your product
• Make data-informed decisions - Stop relying on your assumptions and let the data drive your strategy

So customer feedback is obviously awesome, but what do you actually DO with it? How do you share it with the team and turn it into actions? Well, that’s where user story mapping comes in.

7. Agile user story mapping is all about the customer

Most agile teams run user story mapping sessions to discuss what functions and features are needed in the product. User stories are a visual tool for customer focused development, ensuring your customer journey stays front and center throughout development.

This is where customer feedback comes into play. When your team can access a wealth of feedback from users, they can write user stories informed by real data. This gives them a much better chance of prioritizing features that will add value to users right away. And it means they’ll always know what features to work on next.

Plus, it makes it much simpler for your team to reach a consensus, compared to your team of developers butting heads about which features they think should be prioritised 😬💥

By the way, one of the best ways to help your team be more user-focused is to help them streamline the way they do user story mapping 👇

So, if the paper and sticky notes approach isn’t working for you, try a digital user story mapping tool like Easy Agile TeamRhythm.

Simply enter your stories, click and drag to move them around, organise horizontally and vertically, and arrange stories into sprint and version swimlanes. Plus, the Jira integration means that any changes are automatically saved in Jira so that your team can get straight to work.

Sign up for a free 30-day trial of Easy Agile TeamRhythm and let us know what you think!

Being more customer-focused is a solid strategy.

If your team isn’t exactly obsessed with your customers, maybe it’s time to change that?

Because at the end of the day, if you’re focusing on your customers, you’ll make more of the right decisions about what products, features, and requirements you need to work on. Which means your team will find it easier to make decisions, you’ll waste less time, your users will stay loyal, and you’ll build a better product that gets better all the time.

It’s a solid strategy. Everybody wins! 🎉

Storytelling is an excellent way to describe anything because stories conjure detailed images. Once you create a visual association, cognitive processes leap into action to make the story in the user journey map a reality that is easy to track.

This is what the customer journey map (CJM) is all about—epic storytelling that involves comprehensive planning to capture the design process and deliver a unique customer experience.

Creating a customer journey map (also called the user journey map) involves planning a project from the user’s point of view and using personas, epics, features, user stories, and tasks. This visualization process also involves several stakeholders as user personas on the road to planning perfection.

By the end of the project, your CJM should help achieve business goals and exceed customer expectations with enough touchpoints along the way to motivate satisfaction. The process is a little like rubbing Aladdin's lamp to manifest your deepest wishes.

What is the user journey map?

In contrast to the flat backlog, the customer journey map makes the vision for your project come alive in real-time. You get to use creative storytelling to generate a magical customer experience through visual representations.

Project team members accomplish this by developing an empathy map to an almost-perfect plan from the customer’s perspective. User journey mapping captures the customer’s emotional state, which helps identify touchpoints and pain points. Teams then use these points to elevate the customer experience.

Unlike rubbing a genie’s lamp for results, you get to use convenient software to develop a service blueprint where design thinking reflects a shared vision between stakeholders.

The starting point is to anticipate customer interactions with the mobile app or other e-commerce project development story. That’s why user research is another vital element in developing the customer journey map template.

This customer journey map template should also draw valuable information from the empathy map and the experience map. An in-depth understanding of the KPIs and metrics that go into storytelling helps direct product usability through appreciating customer interactions with the product.

Customer interactions generate feedback, which leads to understanding customer's needs. Additional touchpoints can then be included or modified to build on the overall project outcomes.

Essentially, you use hierarchical storytelling on a magical customer journey map template to meet real-life expectations that resonate with the customer experience.

The customer journey mapping hierarchy

When beginning the journey to create the ideal customer experience, team members should visualize the project from the user’s current state. Once you capture the essence of the current customer perspective, you can better understand what needs to change and improve.

A simple example may be a travel app that encompasses services such as travel agent services, flight bookings, and accommodation in a geographical area (present state). The client wants to create a future state app which contains tourist activities to augment the customer experience. The basic process will then look like this:

For app customers who want a value-add experience with our travel app which is a helpful resource that provides tips on local tourist activities.

Your user journey map hierarchy involves four building blocks to meet customers’ needs:

1. Understanding user personas or buyer personas
2. Developing themes and epics to address touchpoints
3. Using steps or features to support epics and the narrative flow
4. The stories in the customer journey map

1. Understand user personas or buyer personas

The user journey map starts with defining the user personas or buyer personas as vital stakeholders in project development. These customer personas represent the top of the hierarchy, which is the starting point of the customer journey map.

A detailed visual reflection of the user persona is vital to getting your final product right. To deliver this, you need to walk through the story mapping journey from the customer’s perspective. This helps avoid the nasty consequences of inadequate planning that results in sub-optimum deliverables and unhappy teams and customers.

To understand user personas, you need to identify the various potential touchpoints in the journey and customer pain points through use cases and feedback. You’ll need to anticipate as many potential scenarios as possible from the buyer persona’s perspective.

Although the “who,” “what,” and “why” are instrumental in defining the user story, it all begins with visualizing user personas and thinking about customer behaviors, demographics, needs, and goals.

Once you define who your customer personas are, you can follow up with themes and epics to deliver on customer expectations. The epics are the heroes or heroines in this story visualization method.

2. Develop themes and epics to address touchpoints

The customer journey map positions epics at the top of the storyboard because they are vital to creating a great project.

Team leaders must consult with the client and relevant stakeholders to develop an overarching project theme, to translate into epics. Epics flow through this theme from left to right. These epics show large bodies of work broken down into smaller features which can meet continuous delivery value.

Epics are also strategic directives that begin with the current state of an issue and move the situation into a desirable future state. This epic future state is built on tactics, or features and tasks, which team members use to clarify project requirements and move toward that magical future state of project success.

Before team members can move forward, they need to get the epics right. Epics cover three fundamental foundations: user persona, product, and design requirements, which reflect visually on the user journey map.

The epics should meet several foundational requirements:

• Follow through by aligning the overall business goals with detailed buyer personas and demographics
• Broadly outline the user persona’s needs
• Meet specific customer needs by addressing touchpoints and pain points
• Include specific functions, features, and benefits
• Produce a future state ideal project

After designing your heroic epics to cover the project's primary goals, you can start breaking these into steps that integrate with the overall narrative flow of the user story.

3. Use epics for highlighting the narrative flow

Once you clearly define your epics, it’s time to generate narrower steps or features.

As your epics move from left to right, you must define each of the necessary steps to accomplish business goals. This customizable process uses epics to relay the user journey over the project duration to reflect project outcomes.

The customer journey map template also forms the basis of the ideal user story as you transition from epics to features. The features originate from the epics, which is why the epics are the heroes in this story. They “save” customers with excellent planning and deliverables.

At its most basic level, features should include the following elements:

• Deliverables that add value and support epics completion
• Generate business value by considering KPIs, metrics, customer acquisition, and retention
• Demonstrate sufficient definition for team members to follow through on time estimates and complete tasks within one to three sprints
• Team members must be able to test the results of their features
• Establish test criteria for each feature to set acceptable quality standards that meet customer expectations before moving to the next step

In short, the user acceptance criteria (UAC) in the user journey map should include a brief item value description, a feature benefit explanation, and the feature quality completion points that team members must achieve.

Only once you nail these details can you tell the user stories from the customer's perspective. Similarly, only once you complete these three fundamental building blocks in the customer journey map can you focus on user stories and business goals that include customer satisfaction and retention.

4. Begin storytelling through the user journey map

After the third step in the hierarchy of the user journey map, the actual user stories begin. This is the final step in design thinking related to the visualization of epics into manageable stories and tasks.

To state the buyer persona case, team members must understand the “who,” “what,” and “why” of the customer experience. Understanding and defining the customer personas forms the basis of user story creation, enabling delivery of the most acceptable product possible.

Developing the best story relies on creating user stories that highlight the customer experience and use cases that highlight the finer details of system performance.

In the story creation phase, team members assume the customer’s perspective to define requests. Team members can consider exploring social media to understand customer behavior and experiences to use as story inputs. User stories can also include enabler tasks to augment feature completion.

Team members typically write their user stories to complete these in short sprints. Sprint completion involves task completion for release before completing one epic and moving to the next, except where concurrent work is possible.

Ultimately, the user journey map must tell the customer’s story of how their need will be met by creating or modifying a product, process, service, or system feature. New developments must follow through on the formula of “as a…” “I want…” “so that...”

As a new Agile team member, I want to understand my and other team member's roles so that I am clear about my tasks and the responsibilities of other team members.

After generating user stories, team members can break tasks into even smaller parts to facilitate work deliverables and reduce potential churn that negatively impacts customer retention.

As the user journey map progresses, the stories should clearly outline the activities for completion, always linking these back to buyer persona goals. The smaller, granular tasks then relate to user behaviors, and the outcomes link to each step of the process to reinforce what deliverables will meet customer needs within set timeframes.

During the customer journey map, stories can be split further to accomplish greater clarity.

Bottom line: The customer journey map

Through the customer journey mapping process, you should capture the primary epics of the user journey in the story map visualization.

You will need to develop the user story map holistically and interrupt it with additions and subtractions in an iterative fashion. This iterative user story mapping process helps minimize churn as you continue to update your story as you move forward.

Once the project is done, you need to test the product on potential customers, gather customer feedback, and improve the user journey map.

The benefits of carefully planning the customer experience through a visual format are exponential.

Tell your project story with Easy Agile User Story Maps for Jira

The customer journey should highlight the ideal user experience. To do this, the user story map should incorporate the project from user personas to achieve stories with valuable touchpoints as markers along the way.

Once the visual representation is done, it should validate the service blueprint for the customer journey mapping process through the current and future states of the project.

Throughout the project, your team should create a unique user journey that delivers the ultimate customer experience and exceeds customer expectations.

Try Easy Agile TeamRhythm and Personas today to make your customers' stories come alive with magic.

The notable quote from Alistair Cockburn, co-author of the Agile Manifesto, reads, “A user story is to a use case as a gazelle is to a gazebo.” This sheds light on the immense differences between use cases vs. user stories for agile teams. They may sound similar in name, but they are very different and often used in completely different industries.

While both use cases and user stories help teams plan work and determine what’s needed to complete work, the format for how they are used is quite different. User stories are simple, short descriptions from the customer’s perspective. They are the beginning of a larger process that describes a customer's actions as they use or interact with your product. Use cases contain much more context. Creating detailed use cases is a much more in-depth process that’s designed to help teams understand how a user or customer interacts with a system. We’ll dig deeper into both of these processes below.

If you’re in agile software development, chances are you’re more familiar with utilizing user stories. In this post, we’ll dig deeper into use cases vs. user stories differences, including why today’s development teams have migrated towards user stories and why there’s still valid reason for utilizing use cases in the development process.

What’s the difference between use cases vs. user stories?

Use cases vs. user stories: What’s the difference, and how do you decide what’s best for your team and development process?

Use case vs. user story: Past and present

Use cases were the standard for many years, and they were often used in business analysis, systems analysis, software requirements, and iterative development. With the rise of agile, software projects began to favor user stories in place of use cases because they allowed for improved incremental thinking and agility.

What is a use case?

A use case is a description of each of the ways a user may want to interact with a system, a device, or a piece of equipment. They describe how the system design will respond to requests from its end-user, commonly known as an actor. These actors could be human beings or other systems.

Take an online shopping site and a food delivery service, for example. A customer placing an order or checking if a restaurant is open are two different use cases. Or, on the less technical side, consider a toaster. Say someone (the actor) only wants their bagel toasted on one side. Choosing the “bagel” toaster setting is a use case.

Use cases help teams structure all of the different functional requirements and determine the scope of the project — which means they’re full of details.

These details include:

• The goal of the use case
• Whether the actor is a human or another system
• Preconditions, or the state the system has to be in for the use case to occur
• The regular series of steps the system will take
• Alternative paths the system could take
• Postconditions — actions the system takes at the end of the use case or the various states the system could be in after the use case concludes

Take the “bagel” setting on a toaster.

• Use case title/goal: Bagel setting
• Actor/user: This is someone who likes their bagel only toasted on one side.
• Preconditions: There needs to be a “bagel” function/button.
• Regular steps/standard path: The actor cuts their bagel in half and places each half in the toaster. They push the lever down to toast the bagel. Then, they press the button titled “BAGEL” and wait for their bagel to be toasted the way they like.
• Alternative paths: The actor may forget to activate the “bagel” setting, resulting in a poor user experience.
• Postconditions: The toaster returns to its usual state (bagel setting not set).

What is a user story?

A user story is the who, what, and why of a goal or outcome that the user or customer wants to achieve. It’s the smallest piece of work that can give value back to the customer. It’s written from the point of view of the end user, often on an index card.

Here’s an example of how a user story is typically written: “As a [persona type], I want to [action] so that [benefit].”

A user story is designed to be as simple as possible, sparing the team as well as stakeholders from having to decode a lot of technical lingo. But, that doesn’t mean the process for creating a user story is easy. A lot of information is condensed into a single sentence. And before writing a user story, the team first has to identify and create their user persona and assemble all of the product requirements

Easy Agile co-founder Nick Muldoon describes user story mapping as “a facilitated, curated conversation that brings everyone along for the journey.”

A project or product developed in an agile environment will involve a lot of user stories that are each added to the product backlog. There, they can be arranged and prioritized on a user story map according to the scheduled release or sprint.

Use cases vs. user stories: The case for use cases

While use cases are far less common in agile development, they do have some advantages to consider. After all, the true spirit of agile means questioning your assumptions and trying new methods.

1. Use cases provide a summary and planning skeleton

Use cases provide anyone involved, such as managers, leadership, product owners, developers, or stakeholders, with a summary of what the system will offer. What will the system contribute to the users and the overall business? They provide a planning skeleton to help teams prioritize, estimate timing, and execute actions.

2. Use cases provide context for each requirement

The use case provides enough detail and context to ensure everyone is on the same page. It’s an agreement between team members about what the system will and won’t do.

3. Use cases provide a look ahead at what could slow work

The alternative paths portion of use cases provides an advanced look at what could go wrong. Small bottlenecks can take up a huge amount of time and money, so the sooner you can recognize and address these issues, the better.

4. Use cases provide answers for specific issues and scenarios

Use cases answer the specific questions developers or programmers could have along the way. The use case process ensures all questions about issues or possible scenarios are answered at the outset before these questions begin to bog down work or slow down a team’s progress.

5. Use cases provide a model to think through all aspects completely

The use case model ensures developers have fully thought through all aspects of development. Use cases dig into the details of user needs, system goals, possible issues, and various business variants.

Use cases vs. user stories: Bottom line

So, use cases vs. user stories? How do you decide which is better for your team? If you have a lot of experience with agile projects and working on agile teams, you know the undeniable value of user stories. They convey what the user or customer wants to achieve so that teams are always considering the needs of the user.

That said, even though use cases are a bit dated, they can provide much-needed context surrounding how a system is used. They describe how a user interacts with a system, answering many questions in advance to help manage complicated processes. Plus, it wouldn’t be very agile to discount a solution simply because you haven’t tried it before. 😉

Using Easy Agile TeamRhythm

We’re passionate about building tools that help agile teams work better together. Easy Agile TeamRhythm is designed to help product owners and development teams bring value to customers fast and frequently. Supporting user story mapping, backlog refinement, sprint planning, and team retrospectives, you can plan and manage your work right from the user story map, then come together as a team to share actionable insights that will help you work better together each time.

TeamRhythm integrates seamlessly with your agile boards in Jira for both Scrum and Kanban methodologies. Try it yourself in our sandbox demonstration; no need for a login or installation.

This past May John Walpole of Twitter presented Story Maps: A visual tool for customer focused development at the Facebook Technical Program Manager event in Silicon Valley. And our product, Easy Agile User Story Maps for JIRA, got a shoutout — thanks John!

Watch John’s lightning talk now:

John Walpole is a Technical Program Manager at Twitter in San Francisco. Prior to joining Twitter he was an engineer, product and program manager involved in the Xbox, Azure and Windows projects at Microsoft.

In this lightning talk, recorded at Facebook, John explores story maps as a way to figure out what your agile software development team should focus on (in order to satisfy customer needs). Story maps keep the customer journey front and centre during development and make it clear what should be included in a team’s sprint. For more on story mapping see Understand what your customers want with agile user story maps.

It’s time to get things done and hand over the project to the programmers. But before they get their hands dirty, someone must plan the Scrum sprint or iteration. The Sprint Planning meeting is one of Scrum’s ceremonies, and it's the sprint's opening event. 🎬

Let's walk you through the event and explain how to prepare and hold one successfully. You'll also learn who participates in Sprint Planning and why the meeting is so important.

What's a Sprint Planning meeting?

Sprint Planning is a Scrum meeting. It kicks off a sprint, so it occurs on the first day of a new sprint. If applicable, it should occur after the Sprint Review and the Sprint Retrospective from the previous iteration.

Sprint Planning aims to decide the deliverables for the upcoming sprint and define a plan to develop the work.

The entire Scrum Team (the Product Owner, the Scrum Master, and the Development Team) collaborates during Sprint Planning.

Can you imagine a successful project without planning? 🙅 We can't either, so we don’t start a Scrum sprint without planning it.

To plan a Scrum sprint, you need to decide:

• The sprint's duration — remember that a sprint is a timebox
• The sprint goal, which is its purpose and represents the product increment's value to the customer
• The work that the Development Team can complete during the sprint, what work items the team should do first to achieve the sprint goal, and how long they should take considering the team's capacity

Additionally, Sprint Planning should motivate the team and set realistic expectations.

By the end of the Sprint Planning meeting, the team must produce the following outcomes:

• A shared understanding of the sprint goal. This goal is the guideline for evaluating the Development Team's work once the sprint is over.
• The Sprint Backlog. This artifact represents the conversation between the Development Team and the Product Owner on the to-do work. It's the result of a balance between customer value and development effort.

Now, each Sprint Planning meeting requires some preparation. Read on about who should do it and what it entails.

How do you prepare for Sprint Planning?

The Product Owner should follow these steps to set the foundation for successful Sprint Planning:

• Combine the output of the previous Sprint Review, feedback from stakeholders such as management and customers, and the product vision
• Update and, if necessary, refine the product backlog
• Know the customer value that the development team needs to create in an increment

So, once all the preparation is over, it's time for the Sprint Planning meeting to take place.

How should the meeting go?

1. The Product Owner indicates the Product Backlog items — and corresponding priorities — that they consider the next sprint's best candidates. Items can be user stories, tasks, or bugs. The Product Owner proposes those items according to customer value and product vision.
2. Based on effort estimates and the Product Owner's proposal, the development team selects the product backlog items to work on during the current sprint. By promoting those items to sprint backlog items, developers agree on the sprint goal with the Product Owner.
3. Although optional, the team might discuss dependencies between items and who should work on each one of them.

Very few steps, right? However, some practical actions should add on to these steps. Discover what those actions are below.

How do you execute a successful Sprint Planning meeting?

1. Limit the meeting's duration. ⏳ Sprint Planning shouldn't take longer than 1-2 hours per sprint week. That means the meeting shouldn't take more than 2-4 hours for a two-week sprint.

2. Let the Scrum Master be the guardian of time. They're the ones responsible for ensuring that the meeting happens within the defined timebox.

3. Hold the meeting on the same day and at the same time every time. 📅 Team members can be quite busy and have full agendas. That's why reserving a slot in every participant's agenda is a good practice.

4. Define valuable, clear outcomes. 🎁 Those, together with a clear sprint backlog, increase the Development Team's motivation. Producing the right outcomes is pure satisfaction, and a clear work plan is the recipe to achieve that.

5. Make sure that the Scrum Master guarantees these things. First, that the conversation between the Development Team and the Product Owner is fruitful. They should all agree on the sprint goal. Second, that the developers make good choices when moving product backlog items to the sprint backlog. Selecting an item that is feasible for the sprint duration, team capacity, and workload is a good choice.

It might seem easy, but this is not all there is to do during Sprint Planning. There's a bunch of things to avoid.

If we were to give you some advice...

Make effort estimates against the development team's capacity. To decide on the amount of work that the team can accomplish in a sprint, consider the team's capacity. (And remember, estimates are just that — estimates.) Developers consider their previous experience, yet each sprint is unique and might change over its course. However, considering team capacity improves the accuracy of effort estimation. Additionally, story points might help the team with effort estimation.

Consider that the development team's ability to estimate should improve over time. Therefore, the team should not critique less accurate effort estimates after the sprint. Otherwise, the team will take much longer to estimate or provide much bigger estimates next time.

Don't try to plan every single thing during Sprint Planning. Leave the idea of coming up with the most complete, perfect Sprint Backlog ever at the front door. After all, Scrum is all about flexibility, and "Better done than perfect." So, a Sprint Backlog that’s complete enough to get developers started is just what it needs to be. Remember that solving complex problems requires a learn-by-doing approach, which turns planning into an equally complex job.

Figure out a realistic expectation for the sprint's outcome. Setting unrealistic expectations for the increment that the development team can produce over a sprint is not a good idea. It might make developers frustrated that they couldn't deliver, which can seriously affect their motivation and performance. On the other hand, realistic expectations set the team for success and a sense of accomplishment. Besides, they facilitate the conversation between the developers and the Product Owner so they can agree on the sprint goal.

Have a well-refined product backlog. It must be detailed enough to allow the Development Team to understand what the work items are about. You don't want to waste precious Sprint Planning time splitting work items into a maximum of one per day. Define and follow a backlog refinement process and ensure that Product Backlog items meet your definition of ready.

Propose a clear sprint goal. 🎯 The Product Owner must be very clear on the expected customer value for the increment. Otherwise, the development team might choose a set of product backlog items that don’t relate to one another. The result could be unexpected outcomes and a low sense of accomplishment.

Clarify the definition of done with the Development Team. Knowing what work done means in the current sprint helps the developers meet the expectations. That's because they can better understand what to do to create the increment. Also, a clear definition of done makes the Development Team more confident when estimating effort.

Strong Sprint Planning makes your project stronger

If you're following the Scrum framework, Sprint Planning is not a choice. Nevertheless, if you ever feel tempted to skip it, bookmark this article and read the following. 📑

It's easier to understand the sprint goal, to-do work, and sprint outcomes with a successful Sprint Planning meeting. If the team doesn't know where it's heading and how to get there, it gets really tough to satisfy customer needs. It's equally hard to deliver your customers valuable increments if you don't organize work by priorities.

Sprint Planning is about instilling clarity and organizing work before it's too late in the iteration. It's also about involving the whole team in preparing for all the effort that a sprint demands. A note: Keep in mind that a sprint plan must fit into a sprint's timebox and consider the team capacity.

Easy Agile TeamRhythm is perfect for Sprint Planning. It's a fast, straightforward, visual, and collaborative tool that allows you to:

• Drag items directly from the product backlog onto the user story map
• Register effort estimates in user stories
• Edit story point estimates
• Prioritize user stories in each sprint by ordering them inside the respective sprint swimlane
• Analyze sprint statistics to ensure that the planned work doesn't exceed the team's capacity and the sprint goal is realistic
• Visualize what the team will deliver and when by arranging user stories into sprint swimlanes

Let us know if you have any questions about Easy Agile TeamRhythm. We highly recommend it to your Scrum project, and our customers recommend the same.

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.

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.

A product backlog represents all of the goals and desired outcomes within the development of a product. They are the specific tasks a team hopes to complete when they set out to design or improve upon a product.

What makes a product backlog so effective is its agile nature. Backlogs are in constant evolution, changing and adapting based on the current needs of stakeholders and customers. To keep a backlog up-to-date and in its most effective form, it needs to be continuously refined and adapted. This process takes time, but there are simple, powerful strategies for maintaining a quality backlog.

A good product backlog has four characteristics. It is:

• Detailed appropriately
• Estimated
• Emergent
• Prioritized

We’ll cover all of these attributes in detail, including how you can ensure your product backlog is in good health. But first, let’s get on the same page about product backlogs and the refinement process.

Transform your flat product backlog with

Easy Agile TeamRhythm

Try Now

What is a product backlog?

A product backlog is a prioritized and ordered list that represents the work to be completed by a development team. Backlog items are derived from the product roadmap and are organized based on the tasks that are most vital — the ones that will make the biggest impact at any given time.

Backlog items represent what it will take to develop a new product or improve an existing one with new features. It’s all of the work a team will tackle in the future, but it’s also a flexible, living organism that evolves as a development team learns more about the product and its stakeholders.

The product owner is in charge of ordering and prioritizing backlog items, placing high-priority items at the top. They are also responsible for backlog refinement, which ensures all backlog items are organized, have appropriate details, and are ready for any upcoming sprint planning.

Product backlogs vs. sprint backlogs

Sprint backlogs are quite similar to product backlogs, but they serve a different, more specific purpose. At the beginning of a Scrum, the product owner arranges the product backlog items that are to be completed by the Scrum team in that sprint.

The Scrum product backlog represents a small subset of the overall product backlog. The product backlog is the entire bottle of wine, while the sprint backlog is the glass of wine you’re going to tackle next. In this analogy, the Scrum master is the sommelier, providing guidance, context, and feedback throughout the sprint.

At the end of the sprint, a sprint review is conducted with the stakeholders to better understand what to tackle next. Backlog items that weren’t completed may be pushed back into the larger product backlog to get to at a later date or during the next sprint. Another sprint planning meeting will prepare the team to tackle the next batch of backlog items.

Why does a backlog need refinement?

Backlog refinement isn’t a luxury task reserved for when you get a chance to tidy up. Refinement is a key part of product backlog management that ensures a backlog always has the most recent, up-to-date information.

Refining the backlog prepares it for the development team, saving time in the long-run. The process helps to prioritize items and ensures there’s nothing in your backlog that you no longer need.

As you’re well aware, the agile methodology centers around flexibility and the ability to evolve a plan as new information or roadblocks appear. What you thought was important at the beginning of product development may not be necessary anymore, or your stakeholders may have turned you in a completely different direction.

Product backlog refinement includes:

• Adding detail to high-priority backlog items for greater comprehension.
• Improving and reviewing estimates.
• Removing items that are no longer relevant to the product.
• Adding items based on new stakeholder feedback.
• Making adjustments based on the most recent bug fixes.
• Prioritizing items that bring customer value.
• Ordering backlog items to deliver the most impact over the next sprint.

Backlog refinement takes time, but it’s well worth the effort to have a healthy, up-to-date backlog that’s always ready for the development team.

DEEP: The key attributes of a good product backlog

Roman Pichler, the author of Agile Product Management with Scrum: Creating Products That Customers Love, developed DEEP to describe the key attributes of a good product backlog. The acronym DEEP helps product owners and development teams understand how to make smart decisions while maintaining a successful backlog.

The concept is applied throughout the product backlog refinement process, which is a critical part of backlog management. Backlog refinement, previously called backlog grooming, is an ongoing process that ensures a backlog is in tip-top shape. We like to think of it like trimming the branches of a plant.

To help a plant grow, you need to prune and trim it. The refinement process adds details where needed and prioritizes items based on the current information a product owner has from team members and stakeholders.

DEEP stands for Detailed appropriately, Estimated, Emergent, and Prioritized.

Following these guidelines and best practices will lead to a quality backlog, which will lead to smooth product development and a successful end result. Let’s dig into each attribute. 🔎

Detailed appropriately

Details matter, especially as a user story rises in priority. As a backlog item gets closer to being completed or moved into a sprint backlog, it requires more detail. Upcoming backlog items should be detailed appropriately, so they can be better understood by the development team. The closer an item is to being completed, the more detail it should have.

On the other hand, items that are lower on the priority list don’t require nearly as much detail. It’s a poor use of time to add details to lower priority items since you never know how the backlog is going to evolve. You could waste a lot of time detailing low-priority items when they might be removed or revised later on in the process.

Estimated

Thorough estimation should be focused on high-priority items that will be tackled soon. As you refine your backlog and add more details to top-priority items, you can improve your estimation. A good option is using story points to zoom in on the details. They can help you accurately and practically reflect the reality of an item from the customer’s perspective.

📘 Read our guide to incorporating user story points to start using this technique.

Since not much is known about them, it’s difficult to properly estimate items that are lower in priority. When you are further down the priority list, your estimation will be more of a guess since you don’t have all of the information yet. In these cases, use a simple agile estimation technique, such as t-shirt sizing (labeling work items as XS, S, M, L, XL) to make a guesstimate. Based on the information you have at that moment in time, make an approximate estimate on the exertion required for that backlog item.

Emergent

The more you learn about the product and its customers, the more you can improve your product backlog. The backlog is a living document that represents your plan at any one given time. It’s not set in stone, and it should see revisions and improvements as you go.

With the information gleaned from retrospectives and stakeholder feedback, you can update the backlog to reflect what you’ve learned along the way. Allow your backlog to evolve, adding, removing, and refining items as needed.

Prioritized

A product backlog needs prioritization. Items at the top are a higher priority, and items toward the bottom are a lower priority. When deciding which items should be prioritized, consider the value each item will provide.

Your team can maximize its efforts by prioritizing the backlog items that will provide the most value to customers at any given time. Since this will change depending on the current needs of your customers, you need to continually adjust and refine your priority order.

Achieve a DEEP product backlog with Easy Agile

Easy Agile is dedicated to helping agile teams work more effectively. We have a suite of Jira apps designed for teams that want to develop products that put the customer at the forefront of decision making.

Easy Agile TeamRhythm transform your flat product backlog, prioritizing based on value to the customer and bringing the customer journey to life. They help teams organize and prioritize user stories while visualizing the customer journey. Keeping your customers embedded in your process will help you make refinement decisions that are in the best interest of the customer, no matter what phase of development you’re in.

Learn more about our agile apps and follow our blog for the latest content for Jira teams.

There are many good reasons why so many scrum and agile teams are adopting story points.

1. Fast estimation

User story points allow you to quickly estimate the work involved in each item on your backlog, and how much work you can get done in a sprint or release.

2. Build consensus and collaboration

If one team member estimates 5 story points, but another estimates 12, it's an opportunity for the team to discuss what work is involved.

One person may have a more efficient way of doing things, or the other person may have a better understanding of the steps involved in doing the work. This discussion will help them share ideas, create a common understanding, build consensus, and create a more accurate estimation.

Compare this to estimating time. If you ask each team member to estimate the amount of time involved in a task, you’ll get 5+ different answers. Timing depends on experience and understanding. But most team members will agree on the effort required to complete a story, which means you can reach a consensus and move on with your story mapping or sprint planning much more quickly.

3. No artificial deadlines

Estimating time instead of story points forces you to come up with an artificial deadline, which can create unnecessary pressure (and probably won't be all that accurate).

Story points more accurately and practically reflect reality. In most cases, there is no set deadline - only ensuring tasks are done efficiently and in the right order of prioritization.

4. Better planning and forecasting

Story points can help you plan better in advance. For example, if you know that Johnny is going on holiday for a week, you can adjust your sprint so that your team doesn't over-commit. Or you can find another way to increase your capacity, like bringing on another team member or reducing scope.

5. Zoom in on the details

Story points force your team to think through the work involved in an upcoming sprint, and consider what's realistic. It's a time for your details-oriented team members to shine - and time for your big-picture thinkers to understand what needs to happen to bring their plans to life.

6. Get commitment

When your team knows they can achieve what's planned and they’re confident in their velocity, it's easier to get them to commit to the work and follow through confidently.

7. Be more adaptable

If the team size changes (maybe you add a new member or someone moves to another role), you have a built-in system to update your velocity (i.e. how many stories you can complete in a sprint) and adapt your workload accordingly.

8. Be just accurate enough

Story points help you estimate what your team can get done in a given amount of time. This kind of accuracy means smoother releases that go to plan - and is especially valuable when you have multiple teams with multiple dependencies.

But at the same time, story pointing makes it clear that your work is only an estimation, and you're not committing to getting X done in Y amount of hours. You won't know how long something will take until you do it - there are nearly always unexpected things that pop up.

Other methods might give you more precise timing, but it’s not practical to spend 30 minutes discussing the work that goes into every single story on your backlog. It’s much more practical to assign an “accurate enough” number, plan your sprint, and get to work.

9. Better capacity planning

You might not be able to fit all your top priorities into a release, especially if they’re complex, risky, or time-consuming. But story points can help you easily identify one or two smaller stories to fill your capacity every sprint or release.

Using story points also encourages you to find ways to increase your team’s capacity (rather than working longer hours). If you can mitigate risk, find ways to reduce effort, and bring the right people in the room to make complex tasks more simple… you’ll be able to get through more stories, more quickly.

10. Measure and improve performance

Story points can help you measure and improve performance by asking your team questions like:

• Did you complete all the work assigned during the sprint?
• Is your velocity going up or down over time, as you get better at agile?
• Was your story points estimate accurate?
• If not, how could you optimize your team's performance and ensure you work or plan better together?

Does everything in your backlog need user story points?

Some teams don't assign story points to every item in their backlog. They might just assign them to the user stories. They might avoid assigning user story points to bugs that come up during the sprint, particularly if they're not related to any of the stories originally mapped to the sprint. This makes sense since it's often tricky to estimate a bug - some take very little effort to resolve, while others are quite complex.

Your backlog might also include smaller jobs or technical tasks that would take anywhere from a few minutes or a few hours to complete. These tasks may not have story points assigned if they require very little effort.

But it’s important to note that these tasks still matter. They still deliver value back to the user. And they're essential as part of your goal: to deliver working software. But you can't always plan for them or estimate them ahead of time.

So, how do you incorporate them into your workflow?

You might need to discuss some different ideas and strategies with your team.

For example, you could set aside a buffer in your capacity to allow for an average amount of bugs and other jobs that don’t get story-pointed. That way, you can stay on track with the stories you have assigned to the sprint, while getting other items ticked off the list.

Either way, if your team is working on tasks that don’t have story points, you have to consider the impact on capacity. You will need to adapt, assess whether the sprint goal is still doable, and adjust your plans accordingly.

What happens if you get the estimate wrong?

While you should aim to make your user story point estimates as accurate as possible, you might have under or overestimated the amount of risk, effort, and complexity involved in bringing a story to life.

This might mean you don't get all the work planned for your sprint done. Maybe you need to move some of it over to the next sprint, which will mean reprioritizing and adjusting your user story map.

Fortunately, this process is pretty straightforward if you use digital user story mapping software like Easy Agile TeamRhythm.

Retrospectives or sprint reviews are a good time to discuss any issues with your team where estimates were off. Take some time to go through what happened, understand why more or less effort was required, and discuss how you might do more accurate estimates in the future.

Assign story points inside Easy Agile TeamRhythm

With Easy Agile User Story Maps for Jira, you can add and edit story point estimates directly on your story map. Simply select the story or issue and edit the story point field.

It will automatically update your sprint/version statistics with new totals, so you can see your capacity, arrange stories into sprint/version swimlanes, ensure you’re making the most of your velocity, and avoid over-committing.

Plus, your whole team has access to the user story board and estimates - perfect for in-house or remote user story mapping, online collaboration, and updating estimates at any point in the process.

Curious about Easy Agile User Story Maps? Features include so much more than story points, like:

• Drag and drop prioritization
• Visualized customer journeys inside Jira
• Sprint/version swimlanes for organizing stories
• Easily add or edit stories inside your story map
• See sprint/version statistics at a glance
• Easy collaboration with team members
  

Free Trial: Easy Agile TeamRhythm