Agile Teams

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.

Just as you looking at a physical map before a road trip helps you understand the legs of each journey, roadmaps help agile teams understand their workloads for the upcoming months. Jira roadmaps offer further benefits, such as timeline visualization and the ability to share relevant information with external stakeholders.

In this article, we'll unpack the purpose of product roadmaps and whether they’re all the same, as well as why Easy Agile Roadmaps for Jira is the simplest roadmapping tool for Jira. You’ll discover how roadmaps help Product Owners, agile team members, customers, and stakeholders. You'll also understand the difference between roadmaps and Gantt charts.

Let’s start with discussing the purpose of roadmaps for agile teams.

Why does an agile team need a roadmap?

Roadmaps help agile teams define their big chunks of work and when to complete them by. It’s an artifact to communicate with the team, customers, and other project stakeholders.

With roadmaps, agile team members have a sense of their journey for the next 3-6 or even 12 months. By understanding this journey, teams can better understand their product’s evolution.

If you’re a Product Owner, roadmaps are a great way for you to:

• Demonstrate that you understand company goals
• Show the C suite and the agile team that you're aware of customer needs
• Show you know how to deliver a valuable product to your customers while meeting your company's goals

Roadmaps are also a great way to remind you and your team how their work fits into the bigger picture. They give you an opportunity to motivate and help team members.

Also, by breaking down epics into user stories in the product backlog, Product Owners and the development team can better prioritize, schedule, and assign resources to those work items.

Now that we've covered the basics of Jira roadmaps, let's take a look at how to adapt them for different roles.

Tailoring roadmaps to meet specific needs

Different people on the team will need different views of roadmaps. Some roles focus on analyzing specific roadmap items of roadmaps, and other roles focus on different parts.

The development team needs roadmaps with expected release dates, milestones, and a detailed customer value explanation.

You may prioritize roadmap items by customer value, which makes sense when considering the customer-first agile methodology.

Often, development teams have roadmaps organized by sprints and work items arranged on a timeline. A work item can be a user story, a task, or a bug.

The C suite uses roadmaps to map the work of development teams onto company goals and metrics.

Those roadmaps display work items organized by month or quarter. This organization helps track progress over time and draw conclusions on goal achievement.

When roadmapping for the C suite, you don't need to worry about providing them with detailed work item descriptions.

The sales staff relies on roadmaps to learn about new features and customer value. That kind of information can help improve sales conversion. Roadmaps are a great way for the sales staff to understand upcoming developments they can get customers excited about.

You should also do your best to offer visually appealing and highly readable roadmaps to your customers. They'll look for a prioritized overview of new features.

Jira roadmaps might help you deliver these different types of roadmaps.

Jira roadmaps

Atlassian included roadmaps in next-gen Jira software. Jira roadmaps allow you to define and organize items in a timeline and keep them up-to-date. You can even share the work status with stakeholders.

But the coolest thing about roadmaps in Jira is that it syncs with the developers' work.

As the scope of a project can change while agile teams are working, it can get tricky to maintain an up-to-date roadmap, especially if you’ve been using a static tool like Excel or Confluence. Thankfully, Jira roadmaps allow you to quickly and easily update the work status and item priorities.

Agile teams can attach user stories to the Jira project on which they're working. As a result, Jira software updates the actual work in their roadmap.

You can also use Jira software to break down roadmap items, or epics, which means dividing work into small chunks. And as if this wasn't enough fun, you can use Jira Software's drag-and-drop functionality to adjust item priorities in the timeline. Consequently, Jira Software automatically adjusts the dates in the epics.

These are a few more reasons why Jira roadmaps are worth checking out. They offer:

• Stakeholder collaboration in creating and maintaining the roadmap
• The ability to share information with external stakeholders
• Increased availability and visibility to team members
• Tight links between a team's work and the roadmap
• Seamless item update ability
• Project status visualization
• Both high-level and detailed item descriptions
• Connections between Jira issue dates and dates on the roadmap

Easy Agile Roadmaps for Jira can help shape your roadmap as a timeline with swimlanes based on work themes or teams. Drag and drop items on the timeline to set when the team will begin and end working on them. You can also:

• Define milestones
• Filter the roadmap’s view
• Track epic completion progress
• Share a PDF version of the roadmap with stakeholders

Before you go, we should get on the same page about Gantt charts vs. roadmaps.

What are Gantt charts?

When we say “Gantt charts are useful for agile teams,” you might immediately think, “That can’t be right!” 😮 However, Gantt charts can be useful in the right context. They’re just not very agile.

The Gantt chart, named for the chart’s creator, Henry Lawrence Gantt, provides a graphic schedule for planning and visualizing tasks organized by project stages.

Project managers use Gantt charts to manage task dependencies and the critical path. This path is the sequence of tasks that team members must execute on time to not compromise the project’s end date.

Simply put, if you’re building a data center, you have to define the order in which the team must execute tasks. Basically, the team can’t start some tasks before completing others.

Now, let’s clarify why roadmaps are agile, whereas Gantt charts are not.

Why Gantt charts and roadmaps are not interchangeable

At first glance, Gantt charts seem similar to roadmaps. However, at their core, they serve different purposes and audiences.

Gantt charts assume that team members will complete work in a linear fashion. This means that the execution of some tasks depends on the execution of other tasks. And any modification to the schedule can compromise the project’s end date, so you should avoid task rescheduling and frequently track the execution of tasks.

This is why the linearity of Gantt charts goes against the very principles of agile. 🛑

The agile methodology originated from the need to address the inefficiencies of traditional project management practices in software development. One of those methodologies is the waterfall methodology.

Agile teams do adaptive planning and deliver outcomes on an ongoing basis. They also focus on continuous improvement. That’s why no Gantt chart would fit into an agile workflow.

Gantt charts follow a linear delivery model with lots of task dependencies, which tends to be slow. 🐌

On the other hand, the agile workflow has shorter development cycles — iterations — with frequent deliveries and the bare minimum task dependencies. That speeds up continuous improvement. Additionally, agile teams adapt their roadmaps very well to ever-changing priorities and requirements.

Roadmaps are good, but Jira roadmaps are awesome

Jira roadmaps like Easy Agile Roadmaps help order work items by priority and update their statuses. Stakeholders can make collaborative edits on roadmaps in Jira, which is very convenient.

Perhaps the greatest feature of Jira roadmaps is that developers can both track work in Jira Software user stories and through the tasks on those roadmaps. From the Product Owner's perspective, the benefit is how they visualize the developers' work and communicate it with stakeholders.

It’s really important to make sure that both the C suite and the agile team buy into the roadmap. If they don’t, you might not be aligning your team’s work with company goals and customer needs.

Keep in mind that roadmaps’ benefits work two ways: Team members better realize how they contribute to achieving company goals, and you can monitor that process.

Try our Easy Agile Roadmaps for Jira. Whether you’re following the Scrum framework or the Kanban framework, it’ll help you organize your team’s work items in a timeline, define milestones, and track progress.

Sprints are at the core of agile principles. And they’re how a Scrum team uses a predefined time period to work together towards an agreed-upon goal. A sprint focuses on interaction and collaboration to produce working software. A team has to do a lot of work to maintain their sprint workflows in Jira. Changing task statuses, notifying teammates to sprint changes, and keeping developers’ code changes in sync with Jira tasks can all add up to a lot of manual mouse clicks. 🖱

Many of these manual steps can be automated to save your team effort.

Help your Scrum team with Jira automations

Scrum is a framework for getting agile work done. The Scrum events are:

• Sprint: The time period in which the team works toward their sprint goal (e.g., completing a set amount of user stories from the product backlog). The next sprint starts when the previous one ends.
• Sprint Planning Meeting: A meeting that scopes the amount of effort required for backlog items prioritized by the product owner. The software development team commits to completing that amount of work.
• Daily Scrum: A brief meeting each workday when Scrum team members update each other on the progress of their work within the sprint. It's a time to lend support or unblock another team member who may be stuck on an issue.
• ​Sprint Review: A time for the Scrum team and stakeholders to review the outcomes of the completed sprint and discuss what impacts they have on future sprints.
• Sprint Retrospective: A meeting to find opportunities to improve on the team's agile processes and its interactions with each other.

Which Scrum roles are involved:

• Software Developers: They get the work done but don't want any sprint surprises.
• Product Owner: This person prioritizes the work and sometimes has to make unplanned mid-sprint changes.

Every player on the software development team, from startups to established companies, has repetitive tasks they need to perform throughout its sprint events. Because we're all human, when we're sprinting, we sometimes forget to transition the status of issues or do the little things in Jira that keep everyone on the team aware of what's happening in our sprint in real-time.

Automate your sprint workflows with Jira

Have no fear. Jira can help automate typical sprint workflows like task transitions and team notifications. 🤯 Agile project management within software development is a methodology that is conducive to automation. You can link behaviors in your Jira issues to trigger actions from tools like Slack and MS Teams, email, GitHub, Bitbucket, and GitLab.

You can use Jira automations to do things such as:

• Notify team members and stakeholders of any changes to a sprint
• Trigger actions based on task transitions within a sprint iteration
• Keep Jira task and sub-task statuses and story points in sync
• Connect code commits and build statues to Jira issues

Oh my!

If you didn't know these tools existed, here's your chance to learn them.

Automate your way to connectivity

Keep agile teammates in the know

When a sprint begins, it's important the product owner notifies team members if something changes. That way, you can make sure it won't negatively impact your ability to complete your sprint goal.

Communication within agile teams is paramount, and Jira provides ways to automatically notify your scrum team based on rules you set about your sprint. For example, you can send emails or Slack notifications when the status of a task changes.

Task and sub-task coordination

Sub-tasks are a handy feature in Jira. They help you break tasks into smaller steps and track their progress as they're being worked on. Scrum masters encourage this universally in agile, but it can be easy for sub-tasks to get out of sync with their parent tasks. We’ll soon learn a Jira automation to prevent this.

Connect developer code work to Jira issues

Your development team has a lot on its plate during a sprint. Not only does it have to complete all of its user stories — but there's also the mechanics of keeping code commits by developers synced with their associated Jira tickets. And, always remembering to keep these in tune with Jira tickets is burdensome. As you’ll see, there are ways to connect actions taken in GitHub, Bitbucket, and GitLab and update Jira tickets.

Jira automations FTW

Here are our nine favorite Jira automations that streamline our sprint workflow.

1. Notify teammates when a story is added to a sprint

Scope creep (adding new points to a sprint after it starts) is nobody's friend. However, there are times when a product owner needs to pull an item from the product backlog and add it to the current sprint. When this happens, it's best practice to inform the whole team that a change has been made. Use this handy automation template to send an email to your team when backlog items are added to a sprint.

2. Automatically assign a task when its status changes

Some team members need to be made aware when an issue transitions to being on their plate. When an issue’s status switches to In Review, for example, you can auto-assign it to a QA teammate.

3. Celebrate when your sprint is over by sending a Slack message

A lot of work happens during a sprint. Because your next sprint always begins immediately when the current one ends, it's often difficult to find time to celebrate wins. Use this celebration to send a fun Slack message to your team when the final issue in the sprint is completed. You can make sprints fun with automation!

4. Automatically put In Progress issues into the current sprint

There are lots of moving parts when trying to ensure that In Progress Jira issues are visible in the current sprint. Nobody wants hidden work. When a developer moves a task into In Progress, you can automatically assign it to the current sprint.

5. Sum the story points of sub-tasks and update the value of the parent task

Be sure that your story point totals are accurate by automatically summing the points of your sub-tasks and updating the parent task with the value. They'll never be out of sync with each other with this nifty automation rule.

6. Close an issue when all of its sub-tasks are complete

Some people like to work with sub-tasks, which is great. But it's easy to overlook closing a parent task after you've finished your work and closed all of its sub-tasks. Well … you can automatically close a parent task when all of its sub-tasks are complete so this doesn't happen. 🤖

7. Move a task to In Progress when a commit is made

Save your developers time by cutting down on redundant tasks. When a code commit is made, it means a task is being worked on. Connect Jira to your commit repository (GitHub, Bitbucket, or GitLab) so that when a code commit is made, the associated Jira issue moves to In Progress.

8. Add a comment to a ticket when a pull request is made

Adding details to a Jira ticket from a pull request can be a copy-and-paste job — but it doesn't have to be. Use a trigger to add the details from the request into a Jira comment.

9. Notify the development team when a Jenkins build fails

Certain issues can't wait to be realized by the whole team on the next daily stand-up. If your Jenkins build fails, this is an awesome way to let the whole team know by Slack, MS Teams, or email ... right away.

Make agile sprints easy

Automations in Jira make a sprint team’s life easier by cutting down on the manual work needed to keep the mechanics of a sprint running.

You can use modified versions of these automations with Easy Agile to make agile even easier! For example, celebrate roadmap wins by notifying your team when issues are completed in your Easy Agile Roadmaps for Jira, or sync your Jira data fields with your roadmap. There are many ways to mix-and-match rules and triggers to make Jira automations work for you.

A couple of weeks ago, our partner Adaptavist released their State of the Atlassian Ecosystem Report which surveyed approximately 1,000 users of Atlassian tools and services. After reading the 50+ page document, I decided that the reports' insights were extremely valuable and worth sharing.

You can also download the full report here. It is a fantastic read and incredibly interesting for anyone working within the Atlassian ecosystem.

Key take-aways from Chief Information Officer at Adaptavist

• Despite a turbulent year, Atlassian ecosystem continues to grow and evolve. This year the company surpassed $US500 million in quarterly revenue for the first time
• For those who rely on Atlassian Server, the company’s decision to sunset its Server products has forced some soul searching and tough decision-making
• Atlassian continues to focus on driving improvements around security, customisation, and feature parity
• Let's open up collaboration across the ecosystem and find new ways to tackle the challenges that lie ahead.

Key findings

• Usage Up: Atlassian usage up despite decrease in IT spend overall. Including Jira, Access, Trello, Align and Advanced Roadmaps
• Non Tech User Up: Increase in non-technical teams using Atlassian tools including Operations and Marketing.
• Challenge: The biggest integration challenge organisations face is connecting Atlassian with other third-party apps such as Zoom, MS Office, Slack, Gitlab, Github, Salesforce.
• Cloud: Atlassian Cloud adoption is increasing slowly but surely, 28% 2020 to 34% 2021. Server represents the majority of deployment followed by DC
• Challenge: Customisation (57% concerned), app integration (48% concerned), cost, and feature functionality (43% concerned) are the main concerns about migrating to Atlassian Cloud
• Changing deployment: 65% of respondents are expecting to change how they deploy Atlassian products in the next three years. Sunset of Server spurring this.
• What people want more Automation - drives business processes, reduce operational costs and improve integration with tools
• DevOps is Up: 27% of respondents developing a DevOps strategy in next 3 years. Adoption across verticals. Why? Automates workflows, faster development cycles, better coordination across teams, improved time to market. Why not? Lack of capability, inadequate training, budget (Same as the benefits that org’s can expect from DevOps!)
• Agile Adoption Up, barriers to scaling efforts though: 67% of large enterprises (>5,000 employees) have high agile adoption intentions. Agile at scale adoption has increased from 10% in 2020 to 49% in 2021. Biggest barriers to agile at scale adoption: other priorities, current method working fine, unclear ROI. Why do org’s want to adopt agile at scale? Better team coordination, align strategy with delivery, increased visibility.

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.

Software development teams are known for using a wide variety of agile methodologies, approaches, and tools to bring value to customers. Depending on the needs of the team and the product's stakeholders, it’s common for teams to deploy and utilize a combination of software development methodologies.

Most dev teams combine methodologies and frameworks to build their own unique approach to product development. You’ll find there are plenty of overlapping principles from one methodology to the next. The key is choosing a system and working as a team to fine-tune and improve that approach so you can continue to reduce waste, maximize efficiency, and master collaboration.

In this post, we’ll outline and compare the following eight software development processes:

1. Agile software development methodology

2. Waterfall methodology

3. Feature driven development (FDD)

4. Lean software development methodology

5. Scrum software development methodology

6. Extreme programming (XP)

7. Rapid application development (RAD)

8. DevOps deployment methodology

1. Agile software development methodology

Agile is the most common term used to describe development methods. It’s often used as an umbrella term to label any methodology that’s agile in nature, meaning an iterative process that reduces waste and maximizes efficiency.

Most software development methodologies are agile with a strong emphasis on iteration, collaboration, and efficiency, as opposed to traditional project management. It’s like comparing jazz to classical music. 🎷

Traditional, linear management methods, such as the waterfall method we’ll cover below, are like classical music, led by one conductor who has a set plan for how the music should be played. The agile process, on the other hand, is more like jazz, which comes together through collaboration, experimentation, and iteration between band members. It’s adaptive and evolves with new ideas, situations, and directions.

2. The waterfall methodology

The waterfall approach is a traditional methodology that’s not very common in software development anymore. For many years, the waterfall model was the leading methodology, but its rigid approach couldn’t meet the dynamic needs of software development.

It’s more common to see the waterfall method used for project management rather than product development. At the beginning of a project, project managers gather all of the necessary information and use it to make an informed plan of action up front. Usually, this plan is a linear, step-by-step process with one task feeding into the next, giving it the “waterfall” name.

The approach is plan-driven and rigid, leaving little room for adjustments. It’s more or less the opposite of agile, prioritizing sticking to the plan rather than adapting to new circumstances.

3. Feature driven development (FDD)

Feature driven development is also considered an older methodology. Although it uses some agile principles, it’s viewed as the predecessor of today’s agile and lean methodologies.

As the name says, this process focuses on frequently implementing client-valued features. It’s an iterative process with all eyes on delivering tangible results to end users. The process is adaptive, improving based on new data and results that are collected regularly to help software developers identify and react to errors.

This kind of focused agile methodology can work for some teams that want a highly structured approach and clear deliverables while still leaving some freedom for iteration.

4. Lean software development methodology

Lean software development comes from the principles of lean manufacturing. At its core, lean development strives to improve efficiency by eliminating waste. By reducing tasks and activities that don’t add real value, team members can work at optimal efficiency.

The five lean principles provide a workflow that teams use to identify waste and refine processes. Lean is also a guiding mindset that can help people work more efficiently, productively, and effectively.

The philosophies and principles of lean can be applied to agile and other software development methodologies. Lean development provides a clear application for scaling agile practices across large or growing organizations.

5. Scrum software development methodology

Scrum is a system regularly used by software development teams. Like many software development methodologies, Scrum is agile, focusing on a value-driven approach. The Scrum process is based on empiricism, which is the theory that knowledge comes from hands-on experience and observable facts.

One Scrum takes place over a preset amount of time called a sprint. Usually, the time frame is between two to four weeks and the Scrum is at the beginning of the sprint. The goal of each sprint is to yield an imperfect but progressing version of a product to bring to stakeholders so that feedback can be integrated right away into the next sprint.

The specific goals of each sprint are determined by a product owner who orders and prioritizes backlog items (the artifacts that need completion). The sprint process repeats over and over again with the development team adjusting and iterating based on successes, failures, and stakeholder feedback.

Learn more about Scrum — the complete program planning solution for Jira.

6. Extreme programming (XP)

Extreme programming, also called XP, is a methodology based on improving software quality and responsiveness. It’s an agile approach that evolves based on customer requirements; the ultimate goal is producing high-quality results. Quality isn’t just limited to the final product — it applies to every aspect of the work, ensuring a great work experience for developers, programmers, and managers.

Decision-making in extreme programming is based on five values: communication, simplicity, feedback, courage, and respect. The specifics of XP can’t apply to all situations, but the general framework can provide value no matter the context.

7. Rapid application development (RAD)

Rapid application development (RAD), sometimes called rapid application building (RAB), is an agile methodology that aims to produce quality results at a low-cost investment. The process prioritizes rapid prototyping and frequent iteration.

Rapid application development begins with defining the project requirements. From there, teams design and build imperfect prototypes to bring to stakeholders as soon as possible. Prototyping and building repeat over and over through iterations until a product is complete and meets customer requirements.

This is ideal for smaller projects with a well-defined objective. The process helps developers make quick adjustments based on frequent feedback from stakeholders. It’s all about creating quick prototypes that can get in front of users for constructive feedback as soon as possible. This feedback is pulled into the user design so that development decisions are based on the direct thoughts and concerns of those who will use the product.

8. DevOps deployment methodology

The DevOps deployment methodology is a combination of Dev (software development) and Ops (information technology operations). Together, they create a set of practices designed to improve communication and collaboration between the departments responsible for developing a product.

It's an ongoing loop of communication between product developers and Ops teams (IT operations.) Like so many agile processes, it relies on continuous feedback to help teams save time, increase customer satisfaction, improve launch speed, and reduce risks.

The steps of DevOps deployment repeat, aiming to increase customer satisfaction with new features, functionality, and improvements. However, this methodology has some drawbacks. Some customers don’t want continuous updates to their systems once they are satisfied with an end product.

Software development made easy

Most software development teams use a combination of methodologies and frameworks to fit their team size, team dynamics, and the type of work being completed. The key is to use an agile methodology and work together to continually improve your systems as you learn and grow.

Easy Agile is dedicated to helping teams work better together with agile. We design agile apps for Jira with simple, collaborative, and flexible functionality. From team agility with Easy Agile TeamRhythm, to scaled agility with Easy Agile Programs, our apps can help your agile teams deliver better for your customers.

Book a 1:1 demo to learn more about our suite of Jira tools, or contact our team if you have additional questions. We offer a free, 30-day trial, so you can try out our products before making a commitment.

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 or do not; there is no try.” While this is certainly Jedi Master Yoda’s most famous quote, it doesn’t exactly apply to agile development. In fact, it’s kind of the opposite of agile. If Yoda were a Scrum Master, however, the quote would look a lot more like this: “Try and again try; that is how you do.”

The Scrum Master facilitates the Scrum team, leading them to a hopeful victory. It’s rewarding, but the Scrum Master role is filled with pressure. The success of the Scrum and the wellbeing of the team falls on the Scrum Master’s shoulders.

If you’re a Scrum Master or aspire to become one, you’ve come to the right place. Master Scrum theory and your leadership skills with our six strategies for Scrum Masters.

Understanding Scrum values and the role of the Scrum Master

Scrum is an agile practice commonly used for product development. It’s based on completing a set amount of work in short bursts — called sprints — so that teams can continuously create iterations as they learn more about a product and its stakeholders.

Ken Schwaber co-created the Scrum framework in the early 1990s to help teams manage complex development projects. He also founded Scrum Alliance and established Scrum.org, an online resource for agile teams.

At the beginning of a Scrum, the product owner decides which product backlog items will be moved to the sprint backlog. From there, the Scrum Master takes over, leading the team through Scrum events, including:

• Sprint planning
• Daily Scrum or daily standups
• Sprint review
• Sprint retrospectives

The role of the Scrum Master is to guide the team through the Scrum process. They facilitate the process, helping the team to master the framework and improve from one sprint to the next.

Characteristics that define a great Scrum Master

Being an effective Scrum Master goes beyond simply following the rules of Scrum. Here are some additional characteristics that truly define excellence in this role:

1. Emotional intelligence

A great Scrum Master possesses high emotional intelligence. This means they can:

• Understand and manage their own emotions.
• Empathize with the team members' feelings and perspectives.
• Facilitate constructive communication and resolve conflicts gracefully.

2. Strong facilitation skills

It's not just about managing the daily Scrum meetings. They need to:

• Encourage open dialogue.
• Ensure every voice is heard.
• Guide the team towards consensus without being overbearing.

3. Adaptability

The landscape of a project can change rapidly. Great Scrum Masters:

• Adapt to changes swiftly without losing focus.
• Help the team pivot strategies quickly while maintaining morale.

4. Lifelong learner

The world of Agile is always evolving. Exceptional Scrum Masters:

• Commit to continuous learning.
• Stay updated with the latest practices, tools, and methodologies.

5. Servant leadership

At the heart of a Scrum Master's role is servant leadership. This involves:

• Placing the team's needs above their own.
• Removing obstacles that hinder the team's progress.
• Empowering team members to take ownership and make decisions.

6. Analytical thinking

A great Scrum Master should be able to:

• Analyze the team's processes and identify bottlenecks.
• Use data-driven insights to foster continuous improvement.

7. Motivational skills

Keeping the team motivated is crucial for sustained productivity. They excel at:

• Recognizing and celebrating small wins.
• Encouraging a positive, collaborative team culture.

8. Excellent communication

Communication is key. They need to:

• Convey ideas clearly and concisely.
• Ensure that all stakeholders are on the same page.

By embodying these characteristics, a Scrum Master not only facilitates effective project management but also fosters a thriving team environment that encourages innovation and success.

Six strategies to become a great Scrum Master

Here are six strategies for Scrum Masters to improve their skills or prepare for their future roles.

1. Don’t forget to be agile yourself

Do you live by agile principles yourself? How agile are you in your leadership style?

Effective Scrum Masters know that they also need to continually improve based on new experiences, successes, and failures. It’s important to learn from your mistakes so that you don’t make them again, but it’s just as important to learn from your successes. Take the time to review your process, including what went well and what didn’t, so you know how you can improve as a leader and facilitator.

2. Get to know your team

Your ability to lead your team is tied to how well you know them. You should continually get to know your team’s strengths and weaknesses. How well do they work together? Who brings out the best in one another, and who doesn't work so well together? Dig deep to truly understand the root dynamics of the team.

Learn more about each individual on the team as well. What do they need help with? What do they excel at? What feedback can you provide to help them grow in their role? How can you help them succeed? Build rapport with your team members by asking how they’re doing, giving and receiving feedback, and finding common ground.

3. Foster a culture of continuous feedback

The agile methodology is based on continuous improvement. How will the individuals on your team improve if you don’t provide them feedback? Likewise, how will you improve if you don’t ask for, and accept, feedback from the team?

Feedback is a two-way street, and it only works if it’s constructive and continuous. Don’t wait until you have something negative to address — you need to regularly provide both positive and negative feedback. Doing this on a regular basis will help you and your team become accustomed to hearing feedback, so it won’t be jarring or off-putting when you do.

As the Scrum Master, you should foster an environment in which all members give and receive constructive feedback.

4. Hone your communication skills

Being in charge doesn’t mean you’re always doing the talking. The opposite is true: Great leaders are great communicators. As a leader, you need to constantly listen to your team, keeping both ears open for any issues your team or the individuals on it may be dealing with.

Actively listen to the concerns of the development team, and consider how each individual on your team prefers to communicate. Do they prefer bold and to-the-point interactions? Or do they need time to ease into a conversation? Everyone communicates a little differently, and understanding your team's preferences will help you make the most of each interaction.

Scrum Masters need to hone their communication skills in order to be effective leaders for their teams. Regularly assess your communication style and its effectiveness, and ask your team for feedback on how you are doing.

5. Make the most of every retrospective

The retrospective is the final event of a Scrum. They are an incredibly important part of the Scrum process, and they should not be overlooked, rushed, or underutilized. As the Scrum Master, you need to take responsibility for making sure retrospectives are effective and occur after each Scrum. Go in with a plan to make the most of every retro meeting.

That doesn’t mean you need to take charge of everything. It’s helpful to let your team run the occasional retrospective. Everyone involved should continually contribute their own ideas to improve the meeting.

Collect regular feedback from your team on how they think your retrospectives are going. Ask for ideas on how they could improve, and change things up. Repeating the exact same questions and retrospective activities will bore your team and lead to reduced engagement.

For more retrospective perspective, read our five steps to holding effective sprint retrospectives.

6. Become a certified Scrum Master

A Scrum Master certification can take you from simple Scrum Master to masterful Scrum Master. While certification isn’t required to become a professional Scrum Master, it certainly helps.

Scrum.org, the website founded by the co-creator of Scrum, offers a three-part certification program called The Professional Scrum MasterTM. The program has three assessment levels that validate your knowledge of the Scrum framework and practical application of Scrum theory.

• The Professional Scrum MasterTM I (PSM I)
• The Professional Scrum MasterTM II (PSM II)
• The Professional Scrum MasterTM III (PSM III)

We’re also big fans of Pretty Agile’s SAFe training programs:

• SAFe Scrum Master SSM Certification
• SAFe Advanced Scrum Master

A certification is a great addition to your resume, and it will help you fine-tune your facilitation skills and Scrum knowledge.

Easy Agile for Scrum Masters

“Try and again try; that is how you do.”

The beauty of agile is that regardless of how many certifications or years of experience you have, there’s always more to improve. Agile is an iterative process in which learning continues from sprint to sprint and project to project. As a Scrum Master, it’s up to you to continue learning the craft and perfecting your facilitation skills, the Scrum Master role involves life-long learning.

Easy Agile builds products designed to help Scrum Masters and agile developers work more efficiently and effectively. Our tools are specifically designed for teams that use and love Jira but need more functionality in order to prioritize customer needs.

Try Easy Agile TeamRhythm to support your team agility from planning through to review. TeamRhythm supports user story mapping, backlog refinement, sprint and version planning, and team retrospectives, building a continuous cycle of improvement right in Jira. It’s a win-win-win for Scrum Masters, development teams, and customers. Try our products absolutely free for 30 days.

You can stick to manual Scrum workflow, or you can automate with free Jira software. We know which method we prefer.

Whichever you choose, implementing the Scrum framework creates a streamlined workflow. Each person has a specific role throughout the framework's steps.

The Scrum workflow provides team members with a simple process to help teams meet stakeholder needs.

While agile methodology aligns with Scrum, Kanban, and Lean, here, we’ll focus on what a Scrum workflow is and how this methodology can support organizational teamwork.

What is Scrum?

Teams use the Scrum framework to guide their workflow. Having a structure to follow means they can easily share, track and improve their deliverables.

Scrum divides work into smaller work parcels known as sprints, which typically last 2-4 weeks. Once the sprint is over, team members do a sprint retrospective meeting (also known as a sprint review) to chat about what worked well and what can be improved.

Scrum roles

Let’s look at the different roles that make up a Scrum team.

1. Product owner

The product owner has a core role in the Scrum workflow. They guide agile team discussions about product backlog items and features. In addition, product owners guide quality assurance to make sure deliverables are up to par.

2. Scrum Master

The Scrum Master will closely follow the principles in the agile manifesto to support sprint planning. Scrum masters guide development teams through agile methods to add value for stakeholders.

3. Software development team

Development teams are skillful and cross-functional. Teams that work in agile software development environments will typically include designers, developers, testers, and others to prevent the need for external assistance.

With the basics in place, we can take a closer look at the agile workflow stages.

Components of the Scrum workflow

The Jira workflow involves an iterative feedback cycle that focuses on creating value throughout the product development process. You can use the basic Scrum workflow steps or customize these.

The parts of an agile workflow are as follows.

1. Backlog development

A product roadmap guides team members in creating user stories and product requirements, which make up the sprint backlog. In the backlog, teams propose a list of features or user stories that the team must deliver. Product owners decide which features will make up the backlog.

2. Backlog release

Produce owner and team collaboration now decide which user stories will make it into each backlog release. Each backlog release is the completion of a smaller set of activities which eventually make up a sprint release. After completing this planning and setting timeframes for each action item, team members choose specific features for each sprint.

3. Sprint work

In a sprint, team members complete a set of backlog tasks within predetermined timeframes (usually 14-28 days). During this time, the agile team builds the product features from a specific sprint backlog.

Scrum or sprint meeting

Teams also hold Scrum or sprint meetings. During sprint meetings, the team sets a sprint goal (usually work on a specific feature). They agree on which product backlog items to complete in order to complete this product iteration. The team will prioritize, plan, and estimate the time needed to complete each task within the sprint.

Daily stand-ups

Agile teams use these daily standup meetings to track their agile workflow towards meeting sprint goals. Daily standup meetings are typically held — naturally — standing up, as they should last no more than 15 minutes. Standup meetings help teams discuss solutions to daily work issues.

4. The burndown chart

Team members can use Jira software to create their burndown charts. Burndown charts show original time estimates compared to real-time activities, which shows where expectations or team resources need to be adjusted.

5. Testing

During testing, the team demonstrates product functionalities for stakeholders. Feedback from product testing guides any needed changes.

6. Sprint retrospective and follow-up planning

The final phase of the Jira workflow is to hold a sprint retrospective. Sprint retrospectives are post-mortems on the previous workflow. At this stage, agile teams question what they did well, what didn't go as they hoped, and what changes they should make in the next sprint. Groups hold these sprint retrospectives to concentrate on better value deliverables through continuous improvement.

Jira software offers a visual display of the team's velocity, task progress, and project status. All these elements link back to the user story, and the group begins a new lifecycle to complete their project.

Create your Jira Scrum workflow in a few simple steps

You can either carry on using a manual Scrum process or transition to an automated Jira workflow for Scrum.

To create an automated, custom workflow, go to the Jira workflow designer. From there, you can manage the workflow scheme for your Jira project. You can also organize backlogs, complex workflows, workflow statuses, or view an issue status using custom fields.

In your workflow, you can:

• Use statuses like "In progress" or "Under review."
• View status items on lines for transitions.
• See issue resolutions.
• Check conditions that restrict assignee roles in bumping up issues to the following stage.
• Use validators to limit who can make transitions.
• Link further changes with transitions.
• Use triggers for automating transitions within specific parameters.
• Set workflow properties for transitions.
• Establish a link between the simple or complex workflow and issue types using workflow schemes.

As the agile team goes through the product lifecycle in a series of sprints, they need a tool to guide their journey.

With the free Easy Agile Scrum Workflow for Jira plugin, you can move Jira issues between the "To do," "In progress," and "Done" sections. You can also use the top right button to drag and drop specific issue types in the "Backlog" and "Selected for development" areas on the board.

More features from the Jira workflow plugin

In terms of automation, plenty of tools are available. You can use Easy Agile’s free Jira workflow plugin as valuable support for agile project management. This can help you create complex workflows and save all the details in the Jira cloud, ensuring nothing is ever lost. The free Jira workflow plugin also includes your burndown chart and sprint report.

Add the Confluence wiki tool to your Jira software for greater team collaboration. Also, use the Team Calendars add-on for better team collaboration.

Automate your Jira workflow now

Don’t wait for providence to come knocking on your door. Automate your Scrum workflow today with software that works.

We design agile apps for Jira with simple, collaborative, and flexible functionality. From team agility with Easy Agile TeamRhythm, to scaled agility with Easy Agile Programs, our apps can help your agile teams work better together, and deliver for your customers.

Business agility alone is no longer enough to succeed in today’s rapidly changing digital age. To compete and thrive, companies need to deliver value at speed and remove anything that gets in the way of seamless workflow. SAFe® flow accelerators can be the key to unlocking this momentum – but how do you successfully apply them to consistently deliver value?

SAFe methodologist Rebecca Davis sat down with Easy Agile's Jasmin Iordanidis to reflect on the concept of flow and business agility. In this article, we share their tips on how to accelerate flow in your organization. You'll learn:

• Why you need a flow mindset for flow accelerators to be successful
• How improving flow improves customer outcomes
• How to work with flow accelerators

Why flow begins with having the right mindset

Under the SAFe® framework, flow is present when a company can quickly, continuously, and effectively deliver quality products and services that deliver value. This requires all individuals and teams in the value stream to be working optimally with minimum delays and rework, an approach that is significantly different to the traditional ways of work.

“Mindset is big when it comes to working in this way,” said Rebecca. “Rather than simply following policy or the way things have always been done, people need to have conversations and ask questions to find ways to improve. And that means everyone in the company, whether you’re at the team or solution or executive level, needs to really understand and live these principals”.

This makes cultivating a flow mindset of open communication and information sharing across all teams and levels essential. It helps pave the way for accelerated feedback loops that help identify blockers early, rectify issues fast, and facilitate continuous, seamless workflow.

How improving flow improves customer outcomes

SAFe® flow accelerators help work flow through the system without interruptions so your company can deliver continuous value in the shortest amount of time as possible. They do this by helping to remove interruptions, progress work quickly, and create a smooth workflow, which together improve productivity across the value stream. “Accelerators are tangible levers you can pull to improve flow,” said Jasmin. “You can apply metrics to each accelerator so you can quickly assess whether it’s working and adjust accordingly”.

This improved productivity generally leads to improved output from your people. “By removing blockers, you can give people in your business more time to do the work that makes them happier and that makes a difference,” said Jasmin. “They can do more deep work - in whatever form that looks like for them – and ultimately, this leads to improved customer outcomes”.

What are the eight SAFe® flow accelerators?

The SAFe® framework includes eight flow accelerators, with each designed to address a specific activity that interrupts value flow.

1. Visualise and limit WIP: Too much WIP confuses priorities, overloads people, and reduces productivity. Continually adjust WIP to better match demand to capacity and help increase flow through the system.
2. Address bottlenecks: Bottle necks cause the value stream to operate well below capacity. Focus on eliminating dominant bottlenecks by adding additional skills, people, or other resources.
3. Minimise handoffs and dependencies: Excessive handoffs and dependencies can cause rework and delays. Create teams and ARTs with all the knowledge, resources, skills, and decision-making authority to create an end-to-end flow of value.
4. Get faster feedback: Fast feedback helps speed up learning and improvement. Build mechanisms and processes to collect, analyze, and evaluate data early in the development process.
5. Work in smaller batches: The smaller the batch size, the faster teams can collect and evaluate feedback and adjust. Optimize size by balancing the trade-offs between holding cost and transaction cost.
6. Reduce queue length: Long queues lead to waste, delays, and information decay. Start tracking queue length and keep backlogs short to create flexibility to work on new high priority tasks.
7. Optimise ‘time in the zone’: People and teams in the zone demonstrate higher creativity, productivity, happiness, and fulfillment. Focus on creating an environment where workers have time and space free from interruptions.
8. Remediate legacy policies and practises: Legacy policies can become part of the culture and inhibit flow, even when they are no longer fit for purpose. Take steps to identity these policies then eliminate, modify, or mitigate.

‍

Easy Agile Podcast

Learn when to connect the Scaled Agile Framework with your agile transformation, the importance of having a common language for organizations to scale effectively + more!

Listen now

‍

‍4 steps to winning with  SAFe® flow accelerators

1. Build a hypothesis

The first step is to build your hypothesis. Clarify what you believe will change and think about when you might first see if flow is moving in a different way to how it was before.

TIP: Start conversations and gather insights from the teams that will be directly impacted by these changes.

2. Choose high-impact accelerators

When choosing which accelerators to focus on, you’ll need to start with reading, digesting, and understanding them all. You can then take these learnings and start conversations with people on the ground to get an idea of where improvements can be made. “There are no sequential steps to follow when it comes to the accelerators,” said Rebecca. “Once you’ve found areas of improvement, you can self-select which accelerators you think will have the most impact and start working with those”.

TIP: Remember if you can’t see it, you can’t accelerate it. So, if you don’t know where to start making improvements, look out for any friction points or gaps in the value stream.

3. Decide when to check progress

“There’s no one-size-fits all answer as to when to check whether an accelerator is improving flow,” said Rebecca. “How long you need to wait depends on the action and the insights you gathered when building your hypothesis”. This means that for some actions, you can check whether flow has improved the next day while others may take a few weeks to see results.

TIP: Identify the earliest moment you can look back and see that something has changed and note this as your time to check in.

4. Use flow metrics correctly

It’s important to remember that flow metrics are not to be used as punitive measures but instead as a marker to measure whether an accelerator has improved flow. For many people, this requires a mindset shift away from thinking that if something goes wrong or if it fails, it didn’t work. And that means that sometimes, there may be a risk that the metrics may be used in a negative way.

“It helps to understand that sometimes people fall back on old behaviours when things get hard – and that includes people in leadership positions,” said Rebecca. “So be honest and courageous if you see metrics used in a negative way. This can help the team get back to the reasons why the metrics are being used in the first place”.

TIP: Build and maintain trust by clarifying how each metric helps improve outcomes and deliver value. If there is no clear link, then consider dropping it.

Accelerating flow helps teams focus on delivering value

Creating time and space for teams to focus on producing value can help your organization respond more quickly to changing customer needs and business conditions. SAFe® flow accelerators can help remove unnecessary work and blockers to create an environment of continuous improvement, optimization, and consistent value creation.

To improve flow across your organization, learn how Easy Agile Programs empowers your organization to visualize where you may have conflicts or risks to work not progressing and to easily unblock these so teams can maintain momentum and continue to deliver value.

‍

Easy Agile Programs

Easily scale planning and collaboration across teams and timezones. Align and empower teams to deliver value at scale - together

Try Easy Agile Programs

If you have been running retrospectives for some time prior to 2020, you may be familiar with the follow agenda for a 1 hour session:

It is quite possible that as your team transitioned to working remotely from 2020 onwards, that retrospectives were still run in realtime but in a virtual setting using Zoom/Teams/Meet rather than in person.

Here at Easy Agile where we have flexible work arrangements, most team members usually spend 1-2 days a week in the office, though we now also have team members working interstate who are 100% work from home. As a result, all our teams really value their F2F meeting time whether it be in person or virtual, so we try to maximise that F2F time as much as we can for those important debates and conversations where the entire team can listen and participate in real time.

How Easy Agile uses TeamRhythm retrospectives to maximise team time

1. Team members can add items to the retrospective board anytime during the sprint

The team is reminded and encouraged to add items to the retrospective board at any time during the sprint, whenever it is top of mind. This can be done asynchronously without any time constraints. Items added like this tend to be worded better because it has not been rushed within the timebox of a traditional retro setting. Capturing the item when it’s top of mind ensures that these items are less likely to be forgotten when the team sits down together to run the retro at the end of the sprint.

2. The team self reviews the retro board during the sprint

The team can review the items on the retro board during the sprint and ping the author of a particular item if they are unclear as to the content of the item. With this feedback and over time, Easy Agile teams have learnt to write in a more specific manner where the item is less likely to be incorrectly understood.

3. Facilitators categorize items before the meeting

Grouping and sorting retro items during the meeting itself can often be a rushed and sometimes stressful event, especially if it is left to just the facilitator to do it while running the meeting at the same time. At Easy Agile, the nominated retro facilitator looks at the items of the board ahead of time and uses categories to label and group like-minded items together.

4. Face to face time are primarily for debate and action setting

Easy Agile retrospective meetings now mainly focus on reviewing and discussing those retrospective items already pre-labelled into specific categories, and deciding on what actions need to be taken in order to improve on future sprints.

The timing of a retrospective at Easy Agile now typically looks like this:

Wrapping it up

By encouraging the team to capture any lessons/thoughts they would like to share during the course of a sprint by capturing it as soon as it comes up on that sprint’s retro board, the majority of the time spent during the retrospective meeting at the close of a sprint focuses on meaningful conversations, ideation, candid feedback and debates and more thoughtful actions.
Less time is wasted with the team sitting silently trying to recall what worked or didn't work during the last two weeks and then having to type it out quickly and have it make sense to the rest of the team.

Just one more thing…

By the time you read this, we will have provided users with the ability to add items to a retrospective board directly from the Jira issue viewer, so now the friction to add a retrospective item is reduced by one less step.

And we also plan to provide the option to display any outstanding retrospective actions from previous sprints on the current retro board.

How do you and your teams run retros? Do you have any tips that you would like to share with us? We would love to learn from you as well. Please email us at hello@easyagile.com with subject: Retro tips.

Software development is incredibly dynamic and results-driven, with rapid innovation and technology changing all the time. So if you want to keep with it all – just like you do with the Kardashians – you need a flexible way of working that suits your organisation. If you’re struggling to work out how to coordinate multiple agile teams and scale agile transformations, Scaled Agile (SAFe) might be for you.

But what exactly do we mean by SAFe, and how can it help your enterprise work better together and more effectively serve your customers?

Read on as we discuss the differences between SAFe and agile and how you can use SAFe within larger companies. Below, we’ll cover why agile is still best for small teams and why enterprises should consider scaling up.

Want to empower your team to implement the Scaled Agile Framework (SAFe)?

Try Easy Agile Programs

Join a demo

What is SAFe?

Scaled agile framework, or SAFe, makes it easier for large enterprises to implement lean agile practices to improve their product and meet stakeholder requirements.

SAFe is a body of knowledge that has structured guidance on roles and responsibilities, work planning and work management, and core values.

SAFe is a combination of different agile practices, but it introduces one unique aspect: lean thinking.

Lean thinking should ensure no resources go to waste during the software development process. Trust us, your thrifty side will thank you. #ZeroWaste 💃🏼

SAFe also encourages people to apply systems thinking to three crucial areas: solutions to pain points, workflow management, and revenue streams.

Here, solutions refer to products, services, or systems that are delivered to the customer. Large solutions have several interconnected parts, so managers need a broader approach to see how they fit into the bigger picture.

People who follow the SAFe framework should think about the involved stakeholders and processes. If any organization wants to optimize how their teams work, they need to become cross-functional, remove silos, and make new working arrangements with suppliers and clients.

This can be a big change for many large companies with poor cross-functional collaboration.

The enterprise also has to define how value flows from concept to cash in the solution department value streams, which is a series of steps used to create value in SAFe. Plus, it's management’s job to maximize value flow across organizational as well as functional boundaries.

People often confuse agile to be the same as SAFe, but they have some key differences.

Try Easy Agile Programs for Jira

SAFe vs. agile: How do they differ?

Agile is a repetitive product development method that helps ensure the continuous delivery of tasks assigned. In other words, it's like Monica from Friends. She’s reliable and good at what she does.

In agile, cross-functional development teams work off a single backlog and break work into sprints, which means breaking down tasks into time-defined, smaller groups. This makes every person aware of what is expected of them, which, in turn, promotes productivity and increases the likelihood of better results.

That said, agile is mainly designed for smaller teams. Think 10 or fewer people. But if you’re an enterprise, don’t start sweating yet. In its simplest form SAFe is an agile framework for businesses that operate on an enterprise level. Enterprises are usually corporations that have hundreds, if not thousands, of employees and teams. So the number of people engaged is definitely larger.

The benefits are different as well.

Agile provides project managers, leaders, sponsors, and customers with various benefits, including faster turnaround time, resource wastage reduction, improved strategic focus on customer needs, better team collaboration, and feedback.

The biggest advantage of SAFe is it’s suited for enterprise problems. It keeps the size of the teams in mind as it helps increase productivity, make efficient project framework planning, and quicker codification of agile practices.

Having said that, SAFe and agile aren’t exactly on different planets.

The essential SAFe and agile core values are similar – but they aren’t exact. SAFe principles prioritize the following four:

• Alignment
• Transparency
• Built-in quality
• Program execution

Whereas, the core values of agile include:

• Customer collaboration over contract negotiation
• Faster response to change over a plan
• Working software of work comprehensive documentation
• Individuals and interactions related to processes and tool

Achieve team alignment at scale with

Easy Agile Programs

Join a demo

So, SAFe inspires lean-agile decision-making across large product management projects, while agile development promotes self-organizing, autonomous teams..

Organisations operating on a larger scale should consider scaling agile – which is exactly what SAFe is. Keep reading as we discuss this in more detail.

Why enterprises should consider scaling up from agile

Before discussing SAFe further, you have to understand what happens to relationships and communication when teams get larger.

The larger the team, the greater the number of relationships. Every new person adds some individual perspective to the team, but they can also increase overhead communication.

Let’s explain things from a mathematical point of view.

Imagine a team that consists of seven members. The total number of one-on-one relationships within the team is 21. But when you increase to nine members, the relationships between every individual becomes 36. Yep, that's the difference it can make! *mind blown*

How does SAFe serve larger teams better?

You may already be familiar with Scrum and Kanban – both of which are agile frameworks and are most effective at the individual team level in sectors primarily born out of software development, including DevOps and portfolio management.

It also means that adopting these perspectives when multiple teams are involved won’t be useful. #Frustration 😔 Although large-scale scrum is a possibility, product owners and product managers often look for other solutions.

SAFe goes beyond the team level, which, in turn, results in better alignment across teams and workload visibility. You're also able to make better predictions related to dynamic market conditions and ever-changing customer expectations.

*enter PI Planning or program increment planning*

PI Planning within SAFe can ensure better collaboration and decision-making between teams. Team leaders can decide on features to work on next, identify dependencies, and develop a new plan for program increment in a much more effective and efficient manner.

So teams work with each other and not against. #Win 🥳

A full SAFe adoption can solve enterprise pain points and boost competencies

Keep reading as we discuss how SAFe solves large enterprise pain points in a way agile alone cannot.

Make processes configurable and scalable

Implementing SAFe for larger teams isn’t difficult – all you need to do is add a layer to the process map. And take your patience levels up a few notches. These changes can help the team visualize how the different teams can continue to work together harmoniously after any change.

In other words, business agility won't have to be compromised.

The Agile Release Train (ART)

An ART enables Scrum and Lean teams to experience the benefits of proper process alignment that the Program and Portfolio processes expand upon as the team starts to grow.

Clearly defined processes and roles

It’s normal for teams to face problems, but with SAFe, they'll get a better idea of how to solve them by improving their thought processes and utilizing specific tools.

What's more, the SAFe website has an in-depth explanation of concepts along with process maps that serve as visual aids to understand the said concepts and processes.

Scaled Agile improves team collaboration

SAFe helps large organizations carry out large-scale, mission intensive projects better. The combination of existing lean and agile principles can play a very positive role in facilitating better communication and control between multiple teams.

As a proud Scaled Agile Platform Partner, Easy Agile Programs enables Release Train Engineers and Program Managers to effectively manage programs at a ‘team-of-teams’ level to deliver alignment at scale.

Register for a demo

Try free for days

If you want to learn more about agile teams and frameworks, we have plenty of guidance that can help you ensure better results for your organization.