Workflow

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

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

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

WATCH NOW

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

‍

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

Nick Muldoon, Co-CEO at Easy Agile

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

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

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

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

‍

Empowering your teams

Culture eats strategy for breakfast

Peter Drucker

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

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

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

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

Qualities of high-performing, Agile teams

1. Create a solid foundation

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

2. Open to learning and adapting

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

3. Share feedback and do the retrospective

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

Using Easy Agile to set your Agile teams up for success

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

‍

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

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

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

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

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

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

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

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

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

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

What is a program board?

What does your teams plan or schedule typically look like?

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

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

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

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

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

But how does a program board help the planning process?

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

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

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

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

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

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

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

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

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

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

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

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

1. Setting up the board itself

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

There are two key elements here:

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

Here is what this may look like:

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

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

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

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

2. Start with features and milestones

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

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

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

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

Milestones are highly visual

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

Features are native Jira issues

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

Join a product tour to walk through Easy Agile Programs

Want to bring your Program Board into Jira?

Join a demo

3. Identify dependencies

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

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

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

To explain this, let’s consider an example.

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

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

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

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

Dependency health is represented as follows:

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

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

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

Program boards are needed for better collaboration

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

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

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

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

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

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

You can with Easy Agile Programs

TRY NOW

‍

The most efficient and effective method of conveying information to and within a development team is face-to-face conversations.

Agile Manifesto, 2001

As true as this statement was when it was written, the Covid-19 pandemic irrevocably changed the way we work, live and communicate.

As organisations and individuals we found ourselves quickly needing to adapt to an ever-changing environment. Now that we have survived, we have to lean into this new way of doing things in the workplace so that we can thrive.

But what about our agile ceremonies?

One of the main reasons companies transition to agile is to make business processes and outcomes more efficient. So how do we take those principles and practices and preserve their integrity in a remote environment?

If you’re familiar with the Scaled Agile Framework, you’ll know that PI Planning is an agile ceremony that is at the heart of implementing SAFe.

Traditionally a face-to-face event, PI Planning is a scaled cross-team planning ceremony that aims to bring together multiple teams to plan - aligning them around a shared mission and vision for the upcoming quarter or increment.

SAFe still advises that PI Planning is still collocated where possible, and it does have its benefits.

However many teams, even before the pandemic, used PI Planning software to run their planning process and to make it more efficient and accessible to distributed PI Planning. But as with most things we have taken online since Covid, we are at the mercy of the tools we use to determine how effective we can be.

The truth is, unless you can get all members within an Agile Release Train - Business Owners, stakeholders, product management, Release Train Engineers, Scrum Masters, and teams - physically in the one room at the one time, considering alternatives is necessary.

It’s important that everyone is present during PI Planning, but that doesn’t mean they have to be physically present to make PI Planning a success

Remote PI Planning with Easy Agile Programs

We are now beyond the period where we needed to adapt to remote work. Our own business agility has been tested and we have needed to evolve.

Since we first launched Easy Agile Programs, we have continued to build on the capabilities it has to help teams and organizations around the world thrive in a remote environment.

With a simple but powerful tool seamlessly integrated with Jira, the latest version of Easy Agile Programs has a range of features aimed at helping distributed teams through the PI Planning ceremony and to build out a long-lived but flexible digital Program board in Jira.

Moving to remote or hybrid PI Planning doesn’t need to jeopardize yours or your customer’s success. In fact with the right tool, it can enhance it by saving time on context switching, complex configurations and double-handling.

The PI Planning Agenda

Regardless of whether you are following a more traditional 2-day PI Planning agenda, or need to accommodate a split agenda in a distributed environment, the core agenda items are the same. We’ll walk you through each of those and how Easy Agile Programs supports these key features.

Source: Scaled Agile

Setting the business context

PI Planning kicks off with the Business Owner(s) or senior executives giving a presentation where they describe “the current state of the business, share the Portfolio Vision, and present perspective on how effectively existing solutions are addressing customer needs” (Scaled Agile - PI Planning).

In the Program details section of Easy Agile Programs, Business Owners can share a recorded video presentation with all members of the ART, or a Zoom or video conferencing link.

As a result, the presentation isn’t restricted to team members being physically present for this agenda item, and can be referred to throughout the PI Planning session and beyond.

Setting the Product/Solution Vision

Next in the agenda, Product Management will present the current vision, typically in the form of the top 10 upcoming features.

Rather than presenting the top 10 features in a list on a slide or document, Program Managers can access Jira Features (Epics) right within Easy Agile Programs and can schedule them onto a visual timeline for the duration of the Program Increment (PI).

The Program Roadmap ensures all teams are aligned on the committed features for a PI and provides visibility into the direction of the Program for all stakeholders.

It’s at this point in the PI Planning ceremony that Product Managers may also call out any upcoming milestones.

According to Scaled Agile, ‘Milestones mark specific points on the development timeline, and they can be invaluable in measuring and monitoring the product evolution and risk.’

Easy Agile Programs enable you to create highly visible milestones on the Program Roadmap to highlight key delivery dates, external events, or business milestones. These can also be created on the Program Board, or at the team level on the Team Planning Board. They are represented by colored flags at the top of the Roadmap that spans the team swimlanes that make up the Program.

Team Breakout Sessions

In the team breakout, teams work individually to estimate the capacity for each Sprint in the PI. Teams create new or identify existing issues from their backlog that will help achieve the set features. The draft team plans are visible to all members of the ART.

To make this easier, Easy Agile Programs has dedicated Team Planning Boards accessible to all who have access to the Program. Simply clicking on a team’s name will take you to their team Planning Board where they are able to set capacity for each sprint within the PI:

Teams have the context of their committed features at the top of their Team Planning Board, both those that are shared by more than one team in the ART or are specific to their team.

To plan the work needed to achieve these features, teams are able to drag and drop existing issues from their backlog or quick create new issues right within the planning board.

During this session, teams also create draft PI Objectives. These are a critical part of linking what the team is working on to broader business objectives, and you don’t need to leave the Team Planning Board to create them.

In Easy Agile Programs you can indicate whether the objective is committed or uncommitted, provide a description, and directly link the Jira issues scheduled to achieve this objective with the objective itself:

During PI Planning, Business Owners will have a discussion with teams about their PI Objectives which provides an invaluable opportunity to align. The Team Planning provides the artefact to facilitate those conversations, and allows Business Owners or stakeholders to assign a business value directly within the tool.

An important part of the team breakout sessions is identifying any dependencies or potential risks to scheduling work. Through drag and drop or create dependencies mode, it is very easy to create and visualize dependencies across teams in the Team Planning Board.

Aside from highly visible dependency lines, our customers also appreciate being able to see the health of those dependencies. If a dependency line is green it means the dependency is healthy, if it’s orange it is at risk, and if it is red it means we are blocked i.e. the work needed to be done to achieve an earlier piece of work is scheduled after it.

And the best bit of all? This is visible to all in the ART in a digitized SAFe Program Board.

On the Program Board, we have the option to have a detailed view with team-level issues visible or to hide them so we can just see features.

Wondering whether Easy Agile Programs could support your organization's PI Planning? With a seamless Jira integration, it takes minutes to set up.

Free trial of Easy Agile Programs

Try now

Program Risks

During PI Planning, we need to be able to identify risks and dependencies to assess whether teams in the Agile Release Train are set up for success to reach their PI Objectives.

A digital Program Board provides transparency to all members of the ART during PI Planning and acts as a single source of truth during and beyond planning. A digital artefact enables the Program Board to become more than a plan, and lives longer than the strings and post-it notes on a physical wall.

We know that visualizing feature-level dependencies is crucial to not only understanding but also troubleshooting the health or status of a PI. Not just during PI Planning itself, but also throughout the PI during execution.

The Program Board in Easy Agile Programs is highly visual and also filterable. Colored lines that indicate the health of the dependency ensure we have an at-a-glance view of significant dependencies that pose a risk to our PI.

Additionally, our scheduling conflicts feature surfaces when there is work scheduled outside of its associated feature, to immediately and clearly indicate where there is a risk.

The ability to filter by dependency health and team in Easy Agile Programs helps to focus conversations around risks during PI Planning.

Plan rework

After presenting plans to the ART and discussing scope, cross-team dependencies, required resources, and risks, teams then proceed to a confidence vote.

If needed, a closing part of planning is to rework any plans so that all teams within the Agile Release Train are confident in what they are committing to.

This may involve rescheduling to address dependencies, breaking work down further, adjusting estimations, etc.

Reworking is simple and streamlined within Easy Agile Programs. The ability to inline edit issue estimates and summaries in real time makes any rework fast and simple. Dragging and dropping an issue easily reschedules it and any impact on associated dependencies can be seen all at once.

All changes made to issues in Easy Agile Programs are automatically reflected in Jira.

Find out how Easy Agile Programs can make PI Planning easy for your collocated, hybrid or remote teams.

Join a product tour to walk through Easy Agile Programs

Join a demo

What about beyond planning?

We’ve examined the merits of remote PI Planning using a digital tool like Easy Agile Programs but something that so often gets overlooked is - what happens after planning?

A plan remains just that if it’s not translated into action. A plan isn’t made not to be fulfilled, and this is where a distributed or hybrid environment can be challenging.

Your Program Board may set you up for success, but ask yourself - how will you know if you’re on track to achieve it?

This is where having a digital, user-friendly tool that uses native Jira issues helps. At the end of PI Planning, teams have created a plan in the form of a Program Board in Jira, but they are also ready for sprint one as soon as PI Planning is done.

From there, the Program Board is set up and capable of evolving, not rolled up and stored away. This is what Easy Agile Programs is designed to do - to provide transparency but also flexibility so that the plan can necessarily adapt and be agile while maintaining momentum towards progress.

So what’s up next for Easy Agile Programs? Can you help us improve it? Check out our product roadmap and if there is something missing let us know.

‍

Should you form cross-functional agile teams?

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

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

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

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

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

Key points

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

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

What are cross-functional agile teams?

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

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

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

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

William Rojas, Adaptavist

What are the benefits of cross-functional agile teams?

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

1. Cross-functional teams communicate and collaborate better

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

2. Cross-functional teams are responsive

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

3. Cross-functional teams are innovative

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

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

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

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

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

What are the downsides of cross-functional agile teams?

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

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

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

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

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

William Rojas, Adaptavist

The first step is to just get started

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

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

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

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

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

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

‍

Success for agile software teams revolves around collaboration, flexibility, and efficiency. Whether you're a coach or Release Train Engineer supporting multiple teams, or a scrum master or engineer aiming for improvement within your team, honing your dependency management skills will boost efficiency and productivity.

While dependencies often seem like hurdles, here's an insight: they can be a powerful strategic tool to enhance your agile team's performance. In this post, we'll explore how you can leverage dependencies to guide your team towards greater efficiency and success.

Agile Team Autonomy

At the heart of agile is the concept of autonomy and self-management. It's all about empowering teams to own the end-to-end delivery of their work with minimal dependencies. This means optimizing their workflow rather than relying on other teams to deliver value to users. When teams need to depend on others, the flow of work becomes less predictable.

In larger, more complex companies, dependencies are often unavoidable due to the sheer size and intricacy of systems. The real challenge is transforming these dependencies into opportunities for improvement rather than roadblocks. By improving the visibility of these dependencies, teams can better understand them, prioritize and sequence work effectively and manage delivery planning and execution more efficiently.

More than one-third of agile teams report that team silos and the delays that result are a problem

17th State of Agile Report, Digital.AI

Dependency visualization

Improving the visibility of dependencies starts with open communication and transparency. When team members are comfortable sharing their tasks and challenges, you create a culture of trust and collaboration. This transparency is critical for identifying dependencies early and managing them effectively.

Software that allows teams to map out dependencies clearly can be a great tool for improving the visibility of work, making it easier to track their status and plan accordingly. Regularly updating and reviewing the dependencies you've mapped keeps everyone on the same page and helps you anticipate potential bottlenecks before they occur.

Easy Agile TeamRhythm is a user-friendly app that integrates seamlessly with Jira to support team planning, which includes visualizing dependencies. You can display dependencies by type and risk, and see dependencies both within your team and with other teams.

Dependency Patterns

Once you're able to see dependencies clearly, you might recognize patterns forming. These dependency patterns can show where a team is relying too heavily or too dependent on another team to deliver work.

Consistent bottlenecks highlight opportunities for improvement, like a change in team composition. When you notice these patterns, it's essential to reassess and implement strategies to become more self-reliant, ensuring a smoother flow of work and improved delivery timelines.

Prioritizing and Sequencing Work

Once dependencies are identified and made visible, you can improve the flow of work by organizing tasks in a sequence that avoids work being delayed by other tasks. Not all tasks carry the same weight or urgency, and understanding the critical path—the sequence of tasks that determines the fastest time to deliver value—can help focus efforts where they are needed most.

Sequencing work thoughtfully ensures that dependent tasks are tackled in the right order, minimizing delays and rework. This strategic approach to task management not only enhances team efficiency but also supports a smoother workflow and avoids delivery being derailed at the last minute.

Better Collaboration

By identifying and visualizing dependencies, you spot bottlenecks early, re-prioritize tasks, and manage delivery plans effectively. More importantly, it empowers your team to take complete ownership of their tasks while constantly improving their workflows.

Remember, every dependency is a piece of a larger puzzle that holds the potential to boost your team's efficiency. By understanding and managing these dependencies proactively, you can ensure smoother workflows, fewer roadblocks, and a highly efficient agile team.

‍

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

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

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

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

Why Story Mapping

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

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

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

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

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

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

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

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

How to build a user story map

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

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

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

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

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

Why user story mapping is better than a flat backlog

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

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

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

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

How to run a user story mapping session

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

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

People you could consider inviting are:

The product owner for the team

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

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

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

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

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

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

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

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

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

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

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

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

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

That’s where user story mapping comes in.

What is user story mapping?

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

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

What’s a user story mapping session?

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

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

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

What’s a user story map?

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

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

What’s a user story?

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

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

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

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

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

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

What does a user story map look like?

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

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

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

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

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

What’s involved in a user story mapping session?

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

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

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

What’s the point of user story mapping?

User story mapping benefits both your customers and your team.

Customers get more value delivered, sooner

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

Teams prioritize and collaborate better

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

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

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

What’s the alternative to user story mapping?

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

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

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

What user story mapping can do for teams

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

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

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

- Christopher Heritage, The Atlassian Team @NextEra Energy

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

How user story mapping can upgrade your flat backlog

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

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

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

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

Try user story mapping inside Jira

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

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

So, give it a try!

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

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

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

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

Try now

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

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

- Mike Doolittle, Product Director @Priceline

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

- Casey Flynn, Distribution Forecast Analyst @adidas

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

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

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

- Sathish K Mohanraj, Lean-Agile Coach @Equifax

Learn more about user story mapping

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

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

How organized are your Jira boards? On the scale of “well-thought-user-stories-beautifully-prioritized-by-customer-value” to “the-digital-equivalent-of-a-90’s-era-laminate-desk-cluttered-by-sticky-notes-and-old-coffee-cups”, where do yours sit?

It might be time to find a tool to help you whip your Jira issues into shape. And the best way to keep things in shape is to visualize the work in one place.

Read on for tips and to see how Easy Agile TeamRhythm helps you prioritize work effectively.

Visual task management

Put simply, when you can see something clearly, it’s easier to understand and manage. Enter: visual task management.

Visual task management uses boards to display and track work, which can give you a view of complex project tasks that makes it easier to comprehend.

For those of us who work in Jira, well yes we can see our epics, stories and tasks on the screen, but it isn’t always clear how they relate to each other.

That’s where a tool like a User Story Map, such as the one in Easy Agile TeamRhythm, offers so much value.

Get to the benefits

Giving yourself the ability to visualize your work comes with a long list of benefits. When your whole team can see the work laid out before them, communication is easier and teamwork can improve.

1. Consistent communication

Local and remote teams can see the same view of work from any location. Epics across the backbone with linked issues lined up beneath. When work is added or changed, you still have a central source of truth that is shared by everyone, no matter where they’re located.

2. A time-saving tool

Sprint or version planning is quick and easy when team members have all the information they need in a single view. Planning is much easier when initiatives, epics, user stories and subtasks along with story points and goals, can all be seen in one place.

Easy Agile TeamRhythm provides this all-in-one view, along with the ability to create and estimate new issues on the story map, and sequence them with drag and drop. Easy.

3. Avoid unexpected roadblocks

Ever had a release derailed by an unexpected dependency? For a smooth and dependable release, you need visibility of issues that are dependent on others.

We’ve made it easy to visualize the dependencies between issues on the TeamRhythm User Story Map, so you can avoid unexpected delays and keep delivering value to your customers.

You can choose to see dependencies between issues that are on the same board (internal dependencies), and where one issue is on another board (external dependencies). This gives you a clear picture of how work should be prioritized so that you avoid roadblocks and manage delays before they become a problem.

Read more: Dependency lines on the TeamRhythm User Story Map >>

4. Productivity increases

Working life is better when you can see how your contribution makes a difference. When everyone in the team can see how their work is important, and ideas for how to do things better start to flow, that’s when you start smashing your goals.

We’ve designed Easy Agile TeamRhythm to help teams focus on continuous improvement. That is something for everyone to get excited about because the team leads with their ideas for how they can make their working life better. Turn those ideas into Jira issues in just a few clicks so you can put things into action in the very next sprint.

TeamRhythm helps you see what to do first

Laid out clearly in a User Story Map format, with the ability to overlay a map of dependency lines, TeamRhythm makes it really clear which issues need to be tackled first to make sure that you can keep delivering for your customers.

Everyone in the team has an instant view of their priorities. Communication is streamlined. Collaboration is simplified and productivity increases. Doesn’t that sound great?!

Watch a demo, learn about pricing, and try for yourself in our sandbox. Visit the Easy Agile TeamRhythm Features and Pricing page for more.

Easy Agile TeamRhythm

KEY FEATURES

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

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

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

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

What is the user journey map?

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

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

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

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

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

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

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

The customer journey mapping hierarchy

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

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

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

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

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

1. Understand user personas or buyer personas

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

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

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

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

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

2. Develop themes and epics to address touchpoints

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

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

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

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

The epics should meet several foundational requirements:

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

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

3. Use epics for highlighting the narrative flow

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

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

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

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

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

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

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

4. Begin storytelling through the user journey map

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

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

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

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

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

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

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

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

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

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

Bottom line: The customer journey map

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

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

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

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

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

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

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

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

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

"Bottleneck" is a buzzword you don't want to hear. When it comes to your production process, maximizing your time and budget is all about keeping efficiency high. However, simply cutting the steps in your process may not make your customer any happier. If you want to achieve a high return on investment and increased customer satisfaction, value stream mapping is an ideal way to keep your team on track.

What is value stream mapping?

Value stream mapping (VSM) is a technique from the lean principles methodology that helps you visualize the steps you need to take to deliver a finished product or service. Value stream maps outline the flow of information and the physical materials to see where value is added for the customer. The purpose of VSM is to increase efficiency by reducing waste in the production process.

Widely known as the lean manufacturing method used in the Toyota Production System, VSM is now often used to eliminate bottlenecks in other industries like software development, supply chain, and healthcare. It's a versatile technique that can help many organizations shine. 🌟

Streamline visibility and provide transparency of your Program for all teams

Easy Agile Programs

Join a demo

Why value stream mapping matters

When companies aim for efficiency, they often focus on reducing the total amount of production steps required. But customers don't always see what happens behind the scenes. Decreasing the length of your workflows mainly benefits your process without changing the experience for them. On the flip side, the value stream mapping process keeps your team members aware of customer needs, so your business can stand out.

For teams that use value stream mapping, reducing inefficiencies is all about cutting production process steps that don't add value. Value stream maps are a visualization of where you're wasting effort. They show your team that keeping steps within your process is okay — but each of those steps should help customers in some way. As a result, VSM prevents overproduction while ensuring your customers are happy with your final product or service.

You can achieve better lean agile workflows with value stream mapping and effectively keep up with customer demand. 💪

Value stream mapping terms

A typical value stream map is divided into three key sections — information flow, material flow, and lead time ladder — that help you see where process improvements can occur. To help you complete each part of a value stream map with greater ease, we'll explain a handful of common terms that you'll come across in each section.

As you learn these terms, you can refer to this Microsoft template to see a few VSM symbols that you'll often use.

Information flow

At the top of a standard value stream map is an information flow section that shows how data transmits between your team members, customers, and other stakeholders. Common terms you'll need to know to complete this section include:

• Customer: This is the consumer who will receive your final product. Your customer is represented in the upper right corner of your map.
• Supplier: This is your organization. Suppliers are placed in the upper left side of value stream maps.
• Dedicated process flow: This is a process or department (like "production control") that information flows through.

Material flow

In the middle of a value stream map is a material flow section that shows how you take your product or service to delivery, step by step. Each box represents a unique task, which may be performed by the same team or by another after a material handoff.

To complete the material flow section, you need to know these terms:

• Shipments: On value stream maps, "shipment" arrows point from the supplier to the first step in the material flow, or from the last step to the customer. They show how your information flow is related to the start and end of your production process. For example, an arrow can show how raw materials move between the supplier and factory or how software access is "sent" to a user.
• Cycle time (C/T): This metric represents the amount of time required between shipments.
• Inventory: Inventory is what's produced between each stage of the production process. Your inventory is usually written below a triangle with a "I" within it. 🔺

Lead time ladder

At the bottom of a value stream map is usually a time ladder that helps you visualize your lead time, which is the average time spent on each step of your material flow.

Kaizen burst

Throughout your value stream map, you can include Kaizen bursts. These represent bursts of activity (like a sprint) in which your team focuses on resolving a specific issue — such as processing customer returns — to quickly remove potential bottlenecks. The symbols for Kaizen bursts look like comic book explosions to grab your attention. 💥

How to create a value stream map

When you're ready to get started with value stream mapping, select the specific product or service that you want to create a map for. While all production processes can benefit from continuous improvement, you should ideally start with a product or service that could benefit the most from VSM. Once you've made your selection, follow these steps with your VSM team:

1. Define your objective: Identify what you want to change for the customer as a result of the value stream mapping process. For example, you might want to improve the quality of a product or the speed with which you deliver a service.
2. Clarify your scope: Define the start and end of your value stream map. You can create a map that includes all of the steps between concept and delivery, begin with an inefficient part of your value stream, or end with a contract agreement instead of a traditional delivery.
3. Outline your process: List each step of your production process. Begin by speaking with team members from each department involved in the process to gather any needed insights. Your list should include non-value producing steps. Collect data about cycle times, lead times, inventory, and more to understand each step even further.
4. Create and evaluate your current state map: Using the information you’ve gathered, create a map that reflects the current state of your process. Work with your team to identify which steps are productive and where improvements are needed. This map will allow you to pinpoint areas of waste, like long process times or software downtime.
5. Develop a future state value stream map: Create a second map that illustrates an improved process that eliminates non-valuable steps. This will be the map you'll ultimately follow to reach your objectives.
6. Build an implementation plan: To start moving toward your future state, establish how your team will implement the new process. Include what metrics you'll keep an eye on to ensure you're on track to reach your objectives. You can also establish how frequently you'll review your progress and adjust your future state map (if needed) during the implementation phase.

📣 Achieve team alignment at scale with Easy Agile Programs

Join a demo

Continue adding value for your customers

Learning to see from your customer's perspective is crucial to ensuring you stand out from your competitors. Following the value stream mapping process can help you visualize where your team is producing value and where you're doing extra work that can easily be eliminated.

To continue adding value for customers, learn how Easy Agile Programs can help you dive deeper into your product’s customer's journey.

Try Easy Agile Programs for Jira

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

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

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

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

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

Use case vs. user story: Past and present

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

What is a use case?

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

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

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

These details include:

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

Take the “bagel” setting on a toaster.

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

What is a user story?

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

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

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

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

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

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

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

1. Use cases provide a summary and planning skeleton

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

2. Use cases provide context for each requirement

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

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

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

4. Use cases provide answers for specific issues and scenarios

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

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

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

Use cases vs. user stories: Bottom line

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

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

Using Easy Agile TeamRhythm

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

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

Story points can be a little confusing and are often misunderstood. Story points are an important part of user story mapping, and many agile teams use them when planning their work. But they aren't as simple as adding numbers to tasks or estimating how long a job will take.

Even if you’ve been using story points for a while, you’ll find that different teams and organizations will use them differently.

So, let’s define story points, discuss why they’re so useful for agile teams, and talk about some of the different ways teams implement them in story mapping and sprint planning.

What are user story points?

Story points are a useful unit of measurement in agile, and an important part of the user story mapping process. You assign a number to each user story to estimate the total effort required to bring a feature or function to life.

When to estimate story points

User stories can be estimated during user story mapping, backlog refinement, or during sprint planning.

Once a user story has been defined, mapped to the backbone, and prioritized, it's time to estimate the story points. It is a good idea to work with your team to do this, as each team member plays a different role in different stories, and knows the work involved in UX, design, development, testing, and launching. Collaborating on story point estimation will also help you spot dependencies early.

It is best to assign story points to each user story before you sequence them into releases or sprints. This allows you to assess the complexity, effort, and uncertainty of each user story in comparison to others on their backlog, and to make informed decisions about the work you decide to commit to each sprint or release.

How to estimate user story points

When estimating story points, you're looking at the total effort involved in making that feature or functionality live so that it can deliver value to the customer. Your team will need to discuss questions like:

• How complex is the work?
• How much work is needed?
• What are the technical abilities of the team?
• What are the risks?
• What parts are we unsure about?
• What do we need in place before we can start or finish?
• What could go wrong?

Tip: If you're having trouble estimating a story or the scope of work is overwhelming, you might need to break your story down into smaller parts to make multiple user stories.

What is a story point worth?

This is where story points can get a little confusing, as story points don’t have a set universal value. You kind of have to figure out what they’re worth to you and your team (yep, real deep and meaningful stuff).

Here’s how it works:

• Each story is assigned a certain number of story points
• Points will mean different things to different teams or organizations
• 1 story point for your team might not equal the same amount of effort involved in 1 story point for another team
• The amount of effort involved in 1 story point should remain stable for your team each sprint and it should remain stable from one story to another
• 2 story points should equal double the effort compared to 1 story point
• 3 story points should equal triple the effort compared to 1 story point… and so on

The number you assign doesn't matter - what matters is the ratio. The story points should help you demonstrate relative effort between each story and each sprint.

Estimating story points for the first time

Because story points are relative, you need to give yourself some baseline estimates for the first time you do story point estimation. This will give you a frame of reference for all future stories.

Start by choosing stories of several different sizes:

• One very small story
• One medium sized story
• One big story

...a bit like t-shirt sizes.

Then assign points to each of these baseline stories. Your smallest story might be 1. If your medium story requires 3 times more effort, then it should be 3. If your big story requires 10 times the effort, it should be 10. These numbers will depend on the type of stories your team normally works on, so your baseline story numbers might look different to these.

The important thing is that you’ll be able to use these baseline stories to estimate all your future stories by comparing the relative amount of effort involved.

Over time, you and your team will find estimating user stories becomes easier as your shared understanding of the work develops. This is where story points become most valuable, helping your team align expectations and plan more effectively.

Make estimation easier

An app for Jira like Easy Agile TeamRhythm makes it easy to see team commitment for each sprint or version, with estimate totals on each swimlane.

Using the Fibonacci sequence for story point estimation

Some teams use the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 34, 55, 89, etc.) for their story point estimates, rather than staying linear or allowing teams to use any number (1, 2, 3, 4, 5, 6, 7, etc.).

This has its benefits. For example, if you're looking at a story and trying to estimate whether it's a 5, 8, or 13, it's much quicker and easier to come up with an answer than trying to land on the right number between, say, 4-15. You'll likely reach a consensus much more quickly.

This also means you won't be able to average the team's story points to finalize the estimation. Instead, you'll need to discuss the work and decide on the best estimate from a limited set of options.

But it does limit your options - if you have a story that’s more effort than 34, but less than 55, your estimate might be less accurate.

Using story points to estimate velocity

After some time working together most teams will have a good idea about how much effort is involved in each story point.

Of course, timing isn't exact - there's a bell curve, and story points are designed to be an estimate of effort, not time.

But story points (and knowing their approximate timing) can be useful when it comes to figuring out how much your team can get done each sprint.

You should be able to estimate about as many story points your team can manage during a two-week sprint, or whatever timeframe you’re working to.

For example, if your team can usually get through 3 story points per day, this might add up to 30 story points across a two-week sprint. This is your velocity.

Velocity is useful for user story mapping and sprint planning. When mapping your user stories to sprints or versions, you can check the total story points and make sure it matches up with your velocity so you’re not over- or under-committed.

As you can see there are a few different methods for estimating work. The best advice is to be conservative and not overload the team.

Over time, your estimations should become more accurate.

Using Story Points in Scrum, Kanban, and Extreme Programming

Story points are central to estimation and planning processes in many agile methodologies. Scrum and Extreme Programming (XP) rely heavily on story points to gauge the effort and complexity of user stories.

Scrum teams use story points during sprint planning to decide which tasks to include in the upcoming sprint, encouraging discussion that leads to shared context and understanding of the work.

Extreme Programming on the other hand, uses story points to assess the size of features, enabling teams to prioritize and allocate resources effectively. Teams using Kanban can benefit from story points by using them to set work-in-progress limits and optimize the flow of tasks across the board.

While the specific practices may differ, story points can help encourage team collaboration and a more predictable flow of work.