Stories by Easy Agile

At Easy Agile, we’re constantly looking for new ways to improve our products, and one of the ways we foster innovation is through Dash Days—a focused period where our team steps away from daily tasks to experiment, explore, and reimagine how our tools can better serve customers.

During our most recent Dash Days, we took a fresh look at the user interface of two of our flagship products, Easy Agile TeamRhythym and Easy Agile Programs. The goal was to enhance interaction and discoverability, so users can experience the full value of our tools without unnecessary complexity.

Here’s a glimpse into our thought process, challenges, and the exciting solutions we explored.

The challenge

As Easy Agile TeamRhythym and Easy Agile Programs have evolved, we’ve introduced powerful features designed to give users more control and flexibility. However, as new capabilities have been added, the interface has become more elaborate. For us, this presents an opportunity—an opportunity to take a step back, simplify the experience, and help users unlock more of what our products offer.

To address this, we brought people from across the business together to brainstorm how we could improve the experience in both products. Through these sessions, we identified a few core opportunities:

• Discoverability: How do we make it easier for users to find and use the powerful features built into our tools?
• Visibility: What’s the best way to surface the right information and features when users need them? 
• Consistency: How do we create a more uniform experience within and across our products to make navigation intuitive?

Armed with these insights, we then set out to explore solutions tailored to each product’s unique challenges. 

A more personalized experience with Easy Agile Programs

For Programs, we focused on three “how might we” questions to reframe our challenges into opportunities: 

1. How might we create more focus on the actions users are trying to complete?
2. How might we make navigation more intuitive and easy?
3. How might we help users with more context about where they are in the app at any given screen? 

Out of the many solutions we explored, the one that got us the most excited was the idea of an Easy Agile Programs Home Screen—a personalized dashboard designed to guide users based on where they are in their planning cycle. 

This home screen could adapt based on where users are in their journey, offering relevant guidance and actions.

• For new users, the home screen could provide clear onboarding steps and easy access to help, so they can get started quickly and confidently.
• For experienced users, it could offer insights and key actions related to their progress, so they can stay focused on what matters most. Users might even see data summarizing their accomplishments, which makes it easier to share successes with their teams.

Whether someone’s brand new to the product or deep into execution, the home screen could be a great way to guide and coach our users—helping them answer questions like, "What should I be doing next?" or "What extra value am I missing out on?". 

A more focused interface for Easy Agile TeamRhythm

For TeamRhythym, our three key “how might we” questions were:

• How might we provide more focus within the User Story Map during sprint planning?
• How might we improve the discoverability of issues without epics?
• How might we enhance the layout to highlight key features and improve overall usability? 

With these questions in mind, we explored a range of ideas to simplify sprint planning and make it easier for users to prep, plan, and review their work, whether they’re using Scrum or Kanban.

Sprint planning can sometimes feel overwhelming when you have multiple sprints competing for attention. To help users focus, so we explored the idea of introducing a focused view during sprint planning. 

• This would allow users to zoom in on a specific sprint and the backlog alone, while collapsing others. 
• Each issue would have its own row in the detailed view, and users can drag and drop either an entire row or drag individual issues to quickly rank them based on priorities.
• The sprint view will also hide epics that don’t have linked issues in the current sprint, giving users a cleaner view of what’s relevant to their current work.

We also looked at ways to enhance the User Story Map interface to bring the most useful tools and features to the forefront. By improving how key functionality is presented, we’re helping teams quickly access what they need, when they need it, enabling them to stay productive without interruption.

This way, we can create a smoother, more focused experience for teams using TeamRhythm, so they can focus on what’s in front of them without being distracted by everything else.

Your turn. What do you think?

At Easy Agile, we’re always thinking about what comes next. 

These ideas aren’t on our official roadmap just yet, but they’re the kind of innovations we’re excited to explore.

If you think these changes would improve your experience with Easy Agile TeamRhythm and Easy Agile Programs, let us know! Your feedback helps us decide what to prioritize, so we can continue building tools that truly make a difference for your teams.

‍

Your company has finally committed to practicing Scrum. WOOT!! 🎉 The promised land is laid out before you — self-organizing teams, sustainable delivery pace, and autonomy to do the right thing for the product and the team. You can't wait to get started! (Spoiler alert: There's an agile release train in your future.)

That was three months ago. Today, your product development organization is a hot mess. Teams are delivering the wrong work at the right time. Code is stuck on a shelf waiting for another team to deliver a dependency. And upper management is thinking about pulling the plug and going back to the older waterfall days.

If you work in a large organization with 50+ software developers and engineers, Scrum can be a tough nut to crack. The larger the organization, the more likely you'll have cross-team dependencies, scheduling conflicts, and challenges creating transparency between the business, product, and engineering teams. But fear not...

SAFe to the rescue! SAFe is short for scaled agile framework. Intended to help large companies implement Scrum, SAFe provides a framework for coordinating work across many Scrum teams.

Part of the SAFe framework is the concept of an agile release train (ART). If you're not familiar with ARTs, you're in the right place. We'll explain what an ART is, why it helps large companies deliver software solutions more efficiently, and how you can start an ART at your company.

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

Try Easy Agile Programs

Join a demo

So, what is an agile release train?

First, let's explain the train metaphor. A train goes down the tracks intending to reach a specific destination. Along the way, the train may stop at multiple depots and add new cargo or passengers. Your software solution is the train tracks. Team contributions to that solution are the new cargo you pick up at the depots. And, the destination is the business value delivered to your users. Simple enough, huh?

ARTs help a group of teams stay aligned on the business purpose of their work and coordinate the delivery of solutions. Your teams are probably organized by function or value stream. An ART identifies the input and timing of each team's contributions that help achieve the business objective for the value stream. Think of it as cross-functional coordination on steroids.

Here are some basic requirements for an ART:

• The schedule is fixed so the scope is variable. But don't panic — once your teams have a consistent velocity, confidence in the scope will increase.
• All teams must be on the same sprint and release cadence.
• Each team follows the values and principles in the Agile Manifesto.
• ARTs participate in planning events for program increments (PIs) and inspect and adapt (I&A) ceremonies, which are similar to retrospectives and system demos.
• Innovation and planning (IP) iterations must be regularly scheduled between program increments. This provides your large team of individual agile teams time to innovate, update infrastructure, or indulge in some specialized training or a hot tech conference. IP iterations also offer a nice buffer in case your PI gets behind schedule.

If your organization is large enough, you may need multiple agile release trains focused on independent value streams. If that's the case, you may need an additional level of coordination found in a solution train. But let's not get ahead of ourselves.

Principles of an agile release train

An Agile Release Train (ART) takes its cues from the Scaled Agile Framework (SAFe) to ensure that multiple agile teams can align and collaborate seamlessly. Here are the core principles that guide an Agile Release Train:

Fixed schedule

ARTs adhere to a predefined schedule to deliver work consistently. This schedule is organized through Program Increments (PIs), which are typically 12 weeks long. The fixed cadence helps teams plan and deliver work efficiently.

Bi-weekly cadence

Much like individual agile teams work in sprints, ARTs operate in two-week segments known as system increments. This regular rhythm facilitates continuous progress and rapid feedback cycles.

Known velocity

The train's capacity to produce work in a given PI—referred to as velocity—is derived from historical performance data. By dividing projects into smaller tasks, teams can prioritize and deliver essential features more effectively.

Develop on cadence, release on demand

While development follows a rigid schedule, the release date is flexible and depends on project completion. This approach allows teams to continuously provide value to customers without being restricted by fixed release dates.

Program increment planning

PI planning is a cornerstone event where all agile teams within the ART come together, usually in person, to establish strategic objectives for the upcoming increment. This collaborative planning ensures everyone is aligned and working towards common goals.

Innovation and planning

At the end of each PI, teams participate in an innovation and planning (IP) event. This period is dedicated to planning the next increment, engaging in educational activities, and addressing infrastructure needs.

Inspect and adapt

To foster continuous improvement, ARTs hold an inspect and adapt (IA) event at the end of every PI. Teams assess their progress and identify areas for improvement through a problem-solving workshop, ensuring that they are always refining their processes and delivering better results.

Roles in a SAFe agile release train

Generally, teams use an ART in a Scrum environment, but, SAFe and agile release train concepts can apply to any agile methodology, including extreme programming (XP), Lean, or Kanban. Regardless of your chosen agile methodology, there are specific roles required to run an ART.

Agile teams

You can't have an ART without agile teams. Thank you, Captain Obvious. 🙄

One difference between SAFe and traditional Scrum is that ARTs allow you to operate with teams dedicated to a specific function, like frontend or backend development, quality assurance, DevOps, security, and business or product functions. ART itself is cross-functional so your teams don't have to be.

Each team is required to have a Scrum Master and Product Owner, just like in Scrum.

Release train engineers (RTEs)

Like Scrum Masters help their team members follow Scrum principles and best practices, release train engineers are servant leaders who do the same for the agile release train. RTEs help ensure the proper execution of program increments, remove blockers, manage risk, and work with the teams on improvements.

Release train engineers typically report to an Agile Management Office, or in the case of Lean, the portfolio management team.

Product managers

While some traditional Scrum teams use both product managers and product owners, SAFe operates at such a scale that both roles are required. The product manager drives the vision, roadmap, and feature backlog while the product owner is responsible for defining the PI objective with the team and executing the functionality.

Easy Agile Programs enables Release Train Engineers and Program Managers to effectively manage programs to deliver alignment at scale.

Try Easy Agile Programs

System architects

Again, due to the scale at which SAFe teams operate, a system architect is required to design the high-level structure of the overall system, determine how each piece fits into the puzzle, and create stable integration points to bring data and processes into a centralized ERP.

Business owners

The business owners are responsible for achieving business outcomes like revenue or customer acquisition goals. As the primary stakeholder for ARTS, business owners operate at a strategic level and will participate in vision, roadmap, and program increment discussions. Their job is to ensure products are built to meet specific business objectives.

Customers

Customers are the ultimate economic buyers or value users of the solution. Their feedback and needs are critical to the success of the ART.

System teams

System teams typically assist in building and maintaining development, continuous integration, and test environments. They play a crucial role in ensuring that the infrastructure supports the ART effectively.

Shared services

Shared services include specialists necessary for the success of an ART but who cannot be dedicated to a specific train. These often include data security experts, information architects, site reliability engineers (SRE), database administrators (DBAs), and many more.

Get started with your agile release train

So, you're ready to jump on the ART! Great! Let's walk through the steps to get you started on your journey.

1. Start with training

Don't skimp on this one. You likely started your agile practices with some training. Do the same here. All the hard work and best intentions in the world can't help you if you don't have a solid understanding of the basics.

Along with training teams, you'll also want to train your leadership teams and executives. Just like when your company adopted agile principles, you'll want to make sure you have buy-in, an understanding of how agile release trains work, and the roles required to support them.

2. Identify your value streams

There are two types of value streams in SAFe: operational and development. An operational value stream focuses on delivering the value to end-users that was created by the development value stream. An example might be fulfilling an order from an eCommerce website.

A development value stream focuses on developing the business solution, like building that eCommerce website.

Identifying your value streams is important before selecting individuals and teams to work on the value stream and filling the additional roles required for the ART. Once the players have been chosen, you're ready to start planning.

3. Prepare the program increment backlog

It's time to refine your program backlog and get ready for PI planning. Planning and refining are best when you can meet face-to-face, but sometimes in large organizations, that's impossible. If you have a distributed team, make sure you have a good backlog tool like Jira to help facilitate virtual meetings.

🚨 Looking for the complete PI Planning solution for Jira?

Try Easy Agile Programs

Ideal for distributed, remote or face-to-face Program Increment Planning.

Join a demo!

Create your user stories at the program level to fit in a two-week timebox and plan your initial release. Until your teams have established a predictable velocity, leave some wiggle room in the iteration.

4. Start the program increment

Now, it's Scrum as usual. You have your sprint ready to go — just execute it like normal. At the end of the sprint, you can add your teams' contribution to the release train.

5. Rinse and repeat

Agile release trains are a continuous, iterative delivery mechanism. Just like traditional Scrum, your teams will build, release, learn, and then start building again. Don't forget to schedule an innovation and planning iteration to give the team a break from the train and time to improve their systems or their team.

Are you ready to jump on board?

SAFe and agile release trains help teams maintain agile development practices as they scale up in size. What may look complicated at first glance is actually a well-orchestrated process designed for team synchronization according to business value streams.

Use the Scrum knowledge you have within the individual teams, and then train in SAFe practices and get prepared to build your first agile release train. You'll learn by doing but save yourself and your company some headaches and money and invest in training first.

We've linked to some great learning articles throughout this piece, but here are a few more to help you jumpstart your SAFe learning:

• The Ultimate Guide to PI Planning [2021 SAFe Edition]
• SAFe Program Board 101: Everything You Need To Know
• Scaled Agile Framework (SAFe) 5.0 — The Easy Agile Review
• Streamline your workflows with better PI Planning software
• How to prepare for distributed PI Planning

Good luck on your agile journey and stay SAFe! (Too corny??🤦🏽‍♀️)

Project management has many moving parts, and team collaboration and integration of these moving parts is quite challenging. Without intuitive software to guide projects, managers and team members can easily end up shaking their heads in utter confusion.

Software development and other project management teams need all the help they can get when managing these complex projects. Enter the Jira board.

Before we delve deeper into the Jira board, please understand that the topics we cover are just the tip of the iceberg. But unlike the Titanic, there is no room for disasters here — only streamlining your successes!

In this article, we'll cover what Jira boards are, how to create, configure, and navigate the boards, and how to approach reporting, project sidebars, the cross-project board, and using the Scrum and Kanban backlogs.

Adopting Jira boards increases productivity, promotes teamwork, and improves the overall management of any Scrum or Kanban project.

With this kind of support, it's easy to produce outstanding outcomes.

Overview of Jira boards

The Jira board is an Atlassian creation that has become the go-to tool for team collaboration. Jira boards are versatile and practical, allowing teams to streamline their WIP limits and optimize their workflow.

Teams welcome software like Jira to help them control the iterative nature of their projects. The upshot is that project teams deliver high-quality work and exceed customer expectations. Not bad, right?

Anyone can create and use either the Scrum or Kanban Jira board to support their agile methodology and manage iterative, constraining work-in-progress, and monitoring of project processes for optimum value-driven outcomes.

There are two Jira boards: one for each of the Scrum and Kanban agile methodologies. Each software automation board provides an overview of the project, making it easy to see a status snapshot of the work in progress.

Scrum teams work in sprints where individuals must complete tasks in realistic timeframes. Team members capture all backlogs, sprints, and reports on their boards, making work collaboration and integration more straightforward.

Similarly, teams using the Kanban agile methodology get to experience the benefits of Jira boards and reduce their amount of work. Kanban boards also focus primarily on the backlog and reporting functions.

However, the difference between the boards for these agile methodologies is that Scrum highlights iterative work, and Kanban focuses on the workflow, which means managing the workload through work constraints.

Key features and practices of a Kanban Board

Visual workflow representation

Kanban boards use columns to represent distinct phases of a workflow. Each column signifies a step in the process, from task inception to completion. This visual representation helps teams understand their capacity and manage their workload effectively.

Continuous flow

One of the key principles of Kanban is maintaining a continuous flow of tasks. Unlike other methodologies that rely on fixed iterations, Kanban encourages the progression of tasks through each workflow stage in a steady, uninterrupted manner.

Work in progress (WIP) limits

Setting WIP limits is critical in Kanban practice. This means capping the number of tasks that can occupy a column simultaneously. By doing so, teams can pinpoint bottlenecks and inefficiencies more easily, facilitating smoother task transitions and more predictable delivery times.

Task cards

Each task or work item is represented by a card on the board. These cards can include details such as descriptions, deadlines, assignees, and priority levels. This allows team members to quickly grasp the status and requirements of each task.

Continuous improvement

Kanban promotes continuous improvement (Kaizen) through regular reviews and feedback loops. Teams are encouraged to consistently evaluate their processes and outcomes to identify areas for enhancement.

Flexibility and customization

Kanban boards can be tailored to fit the unique workflows and requirements of any team. From customizing columns to aligning WIP limits, teams have the freedom to configure the board to best suit their specific needs and goals.

Key features and practices of a Scrum Board

Scrum Board

This board is great for teams that like to work in sprints, or time-boxed periods when a team works to complete a set amount of work.

Scrum

Ideology: Learn through experiences and reflect on wins and losses to improve.

Cadence: Regular, fixed-length sprints (i.e., two weeks).

Select Features

• Insights: Use insights to optimize sprint planning, make daily stand-ups more meaningful, and improve delivery velocity.
• Backlog: The backlog is home to all of your team's potential work items for the project.
• Sprint: A sprint is a time-boxed period when a scrum team works to complete a set amount of work. Create a sprint, define its goals, and add all the issues from the backlog that your team intends to complete during a sprint.

Navigating the Scrum and Kanban Jira boards

A Jira board shows everything you need to know about a software project. You need a board to track team software activities and collaborate accountably. As any team member knows, this is the backbone of working well together.

In case it isn’t yet clear, these boards help you achieve those goals.

Both these methodologies work for Jira boards, whether your focus is on sprints or constraining the current work.

If you select Kanban for your project, you must enable the backlog feature. Whichever methodology your team prefers, you can use the issue detail view to determine progress immediately and enhance functionality.

Let’s take a look at what the Jira board offers.

1. Jira software board creation

Once you start a project, the software creates a Jira board template automatically. You will need to activate the “Create Shared Objects” feature to allow access to the new board. Alternatively, you can use the 'View All Boards' feature to copy an existing board.

You don’t need to adjust sharing permissions for an existing project board, as the software automatically creates a board for a new project. Once you create your new project, you add the relevant team members to the Jira board.

You also don’t need sharing permission if you copy a board, as all the original users can automatically access the copy until you make changes in line with permission parameters.

However, you’ll use the same issue filter when copying an existing board. You will be the board's administrator, but you may want to select a new filter, as you can't change the original one. Additionally, you can create custom fields to sync with project requirements.

Remember — choose one methodology before you create a board, as it is not possible to switch after starting a new project.

After creating a board, you can share the link with the team, which you will find under the “View All Boards” tab. Best of all, you save all your projects in the Jira software cloud, lowering overall project risks and saving space.

2. Board configuration

Configuration allows you to express your creativity in new and practical ways that benefit the overall project. Only Jira or board administrators can configure Jira boards.

You get to customize the board to align with project outcomes, and you have several configuration options to meet your goals.

You can literally configure everything on the Jira board, from the filters to the ranking, columns, swimlanes, issue detail view, and other elements. This is your chance to shine as you use the tool to express your creative side.

Have fun mapping the workflow on the board. Keep track of statuses, and use color to enhance the board’s readability so everyone on the team can see what they need to do and when. Plus, board configuration is intuitive, making it enjoyable to use this software.

3. Using the Scrum backlog

In the backlog, you have two sections — the sprints and the backlog. You can create issues and keep these current or delete them when complete.

Because Jira is user-friendly, you can drag and drop any issue into rankings, sprints, organizing stories into epics, or anywhere else you wish to assign them.

Only specific issues are visible in this section. For instance, issues such as sub-tasks or those that sync with a saved filter are visible. But if you map the status of all the issues to a specific column such as a Done column, they won’t be visible in this section.

When planning a backlog, note that various functions have different permission requirements. Only project administrators can initiate sprints, for example, but they can grant permissions to others.

4. Active sprints

The Scrum board uses active sprints, whereas Kanban uses a “monitoring work” feature. Active sprints on the Scrum board deal with current teamwork iterations. As with the planning mode, administrators can manage issues, dragging and dropping them into the workflow or elsewhere as necessary.

These boards update twice every minute, and the same concept applies as in the plan mode. Some issues on the active sprints will be visible, and others will be invisible. Software developers should be able to figure out the differences quickly, since they deal with this kind of thing regularly.

Again, this part of the Jira board is comprehensive. active sprints allow you to generate and move issues to different columns. Managing active sprints keeps the project current and informs team members of the status of each issue, whether in transition, flagged, or if there is a change in its ranking.

5. Getting familiar with the Kanban backlog

Image credit: Atlassian

Remember that the Kanban backlog is only accessible when the software administrator enables this feature for an assignee.

A small number of issues are easy to manage in this section, but as these increase, it becomes more challenging to address them. This excess volume of issues is a nightmare without software, but you can escape this drama with ease. Easy Agile has a suite of products aimed at helping you manage project issues.

Administrators can create and plan their Kanban project as they want by moving the issues to the hidden Versions section or Epics in the expanded panel. You can also move issues between this section and the “Selected for Development” areas per planning requirements.

Like Scrum, some project board issues in Kanban will be visible or invisible. Visibility and invisibility of issues primarily depend on filter, issue matches, and this section's status.

Team members can concentrate their efforts on their current work separate from the planning section to avoid distraction. The separation of these elements helps team members to focus on issues that need immediate attention.

But none of this information should come as a surprise, as Atlassian has invested more than a decade into developing precision software to make your job much easier.

6. Kanban monitoring

Instead of active sprints, Kanban monitors project progress on its principle of continuous delivery. The project administrator tracks tasks and works in progress to ensure that team members stay in control of their software development.

Use this board if your team focuses on managing and constraining work-in-progress.

Many other actions are possible on this project board, including estimating stories (this is one of the really fun parts), user stories, creating sub-tasks, filtering, releasing, and hiding issues.

As team members complete tasks, the administrator pulls new ones from the work in progress section to constrain pressure and support quality deliveries.

Like active sprints, the administrator can prioritize and rank issues for their Kanban project.

The Kanban software administrator can also maintain complete control over a board or allow specific permissions for editing, as with the other board.

Ultimately, the Kanban board presents a bird’s eye view of the project in progress, allowing for close monitoring of issues at any point.

As hinted at earlier, little of the project board’s potential can be explained in one article. If you want to upskill yourself on this software, many sources can help you achieve your goal.

7. Reporting

One of the most fundamental aspects of projects is reporting (as y’all should know). Luckily, Atlassian allows for a comprehensive reporting function on Jira boards for both Scrum and Kanban.

Some of the Scrum reports include the burndown, burnup, and sprint charts. You will also find control charts, epic reports, the cumulative flow diagram, velocity chart, and a version report available, among others.

Kanban reporting features encompass the control chart and the cumulative flow diagram.

Additional general reports like the recently created issues report, time tracking report, and many others are available for general issue analyses.

The change log and status report are available in Confluence if you connect your Jira software to other programs.

As you can see, reporting is an inherent feature of the Jira board, which helps you connect with and inform everyone of a project position at any point.

8. Using the project sidebar

The project sidebar on the top-right of the board is your go-to section for everything about your project.

Select any tab in the project’s sidebar to view the backlog, reports, or anything relating to the current project. You can view most project details from this starting point, including epics, stories, issues, and more specifics.

Get familiar with the instant filter in the backlog to search for issues with a search term such as “issue type” or “issue key.”

A quick filter is also available to narrow your search for software work items that you are handling, including WIP limits, use cases, and more, adding to the overall versatility of the Jira board.

It should be clear by now that these boards are as creative and versatile as any project team — take advantage of the opportunity to up the ante.

9. The cross-project board

A Jira board may include access to a software project add-on that does not work with Jira software. Either methodology board might also have multiple projects.

When you see additional projects linked to a software board, you can navigate to the one that interests you. Select the project header and choose the cross-project tab, which will enable you to view project details in the sidebar.

Alternatively, you can navigate to a cross-project from the top-right board header. Using this option means that you won’t see details since the program cannot read project info from this perspective.

Adopting the Jira board: A new world of possibilities

If you’re looking at improving team collaboration, project software integration, and management, the Jira board offers a new world of possibilities.

When you want your team to master a popular agile methodology, the Jira board promotes learning and productivity, whether you opt to use Kanban or Scrum.

If you want to become an expert in Atlassian Jira software boards, take your projects to a new level with Easy Agile apps for Jira.

Easy Agile apps such as Easy Agile TeamRhythm, Roadmaps, and Easy Agile Programs make it practical and simple to engage with Jira boards by offering flexible and collaborative solutions.

Software developers also get the benefit behind years of developing these apps to support the creation of quality solutions for their clients.

By now, you’re pretty familiar with Scrum. It’s given your team a framework they can work with to achieve internal goals so they can deliver quality software to customers. But, you can always improve your Scrum practices to continue to delight your customers. 😁 One of these is the daily scrum — a practice that sounds straightforward, but is easy to mismanage (more on this soon 😉).

The daily scrum consists of three elements — Scrum roles, Scrum artifacts, and Scrum events.

In this article, we'll show you how these components fit into the all-important daily scrum meeting, provide some tips to keep your daily scrum running smoothly, and discuss what traps to avoid so that your team is always on task. We'll also point you towards resources that will get you proficient in the other elements of agile. Our goal, as always, is to make you an agile pro. 🏄🏽‍♀️

What is the Daily Scrum Meeting?

Let's do a quick recap of each of them before we dive into the daily scrum:

• Scrum roles: These are the product owner, the Scrum master, and the development team. These Scrum team members work together as a unit to achieve their goals.
• Scrum artifacts: Artifacts include the product backlog, the sprint backlog, and the increment. The artifacts represent information to the team that enables them to have transparent views against which to measure their progress.
• Scrum events: The sprint, sprint planning, daily scrum, sprint review, and sprint retrospective give the team an opportunity to meet and refine any of the Scrum artifacts that need adjusting to keep the team's goals within view.

The daily scrum is a meeting between team members to discuss its current sprint progress. It's time to discover if any adjustments to the sprint or the product backlog need to be made in order to achieve its sprint goal.

Importance of Daily Scrum

The daily scrum plays a crucial role in enhancing both team coordination and communication. This brief, focused meeting offers the team a structured environment to align on progress and obstacles, contributing to several key areas:

1. Progress Transparency: Team members get a clear view of what everyone is working on, which fosters accountability and mutual support.
2. Impediment Identification: Problems and potential roadblocks are surfaced early, allowing the team to address them promptly and minimize project delays.
3. Focused Collaboration: By keeping discussions relevant and on-point, the team can spend their time more effectively, concentrating on solutions rather than prolonged debates.
4. Goal Alignment: The meeting helps reaffirm and refocus efforts toward the sprint goals, ensuring everyone is aligned and moving in the same direction.

By adhering to best practices, such as keeping the meeting time-boxed and promoting an inclusive atmosphere, teams can maximize the benefits of the daily scrum, leading to a more cohesive and efficient working environment.

Key Participants in the Daily Scrum

Development team

The development team members are the main participants in the daily scrum. During the meeting, they report on their progress towards the sprint goal to discover if any adjustments need to be made. They can do this by each answering three questions:

1. What did I work on yesterday towards the sprint goal?
2. How do I plan on working towards the sprint goal today?
3. ​Is there anything preventing me from finishing what I am working on?

By doing so, everyone on the team is in the loop of the full team's progress. The answers to these questions also allow the team to uncover any blockers and adjust the sprint backlog accordingly. An example of a blocker may be a bug that prevents one developer from finishing her assigned user story in the sprint.

Scrum master and product owner

In traditional Scrum, the Scrum master and product owner aren’t active participants — and aren’t technically required — in the daily scrum meeting since they don’t do the development work that will achieve the sprint goal. However, they can still be valuable meeting participants. It’s up to the Scrum team to decide if they should attend.

• The product owner can lead the way in adjusting the sprint's backlog items. For example, the bug that is blocking other work can be moved so it gets fixed in time to keep the sprint goal within reach.
• The Scrum master can make sure that daily scrum best practices are being followed and that the team is avoiding some of the common pitfalls that betray the objectives of the daily scrum meeting. Let's look at those next.

What's the Difference Between Daily Scrum and Daily Standup?

Sometimes, it can be confusing to tell the differences between daily scrum and daily standup — and sometimes the terms are used interchangeably. However, it's worth pointing out the differences between the two.

A daily scrum is an event that is defined in the Scrum guide. So, then what is daily stand-up, and how is it different? 🤔

A daily stand-up is a daily meeting whose objective is to provide team members with progress towards a common goal. However, it is less restrictive in terms of its participants and time limits. In other words, team members outside of the Scrum team can participate and the meeting can run longer than 15 minutes. For example, a company may conduct a daily stand-up that includes its entire staff or a particular department whose progress updates are not limited to the development of software.

Daily Scrum Best Practices

So, what are the best practices for conducting your daily scrum meetings effectively?

1. Complete the daily scrum in a time box

A 15-minute time frame is most commonly used to ensure that the team stays focused and on point. After all, team members only need to answer their three questions succinctly and effectively.

2. Conduct the meeting at the same time and place every day

This will provide a level of consistency and regularity and will help foster the Scrum values of commitment and focus.

3. Include the same team members in each daily scrum meeting

If you have a rotating cast of characters, then you run the risk of disruptions. Some people in the meeting will likely be missing context from prior meetings and will need to be updated.

Daily Scrums for Remote or Distributed Teams

Daily scrums are pivotal in ensuring team alignment, but for remote or distributed teams, they require thoughtful execution to maintain effectiveness. Here's how you can make the most of your virtual daily scrums:

Leverage Video Meetings Intelligently

Video meetings bring the advantage of live conversation, crucial for real-time collaboration and clarity.

• Respect Personal Needs: Recognize that being on camera can be draining. Offer flexibility by allowing team members to choose when to use their cameras.
• Avoid Fatigue: Encourage camera use for important discussions but provide options for audio-only participation to prevent exhaustion.

Manage Time Zones Wisely

Distributed teams often span multiple time zones. Here's how to navigate the challenge:

• Schedule Smartly: Find a suitable meeting time that works for the majority. For instance, someone might join in the mid-morning while it’s early morning for others.
• Consider Asynchronous Updates: When time zones are vastly different, rely on asynchronous communication like task board comments or chat channels to keep everyone informed without disrupting their work-life balance.

Utilize Visual Tools

Visual aids can significantly enhance understanding and engagement in virtual meetings.

• Screen Sharing: Use screen sharing to display task boards or project management software, providing a clear, visual context for discussions.
• Collaborative Tools: Leverage tools like Miro or Trello for visual brainstorming and task tracking during the scrum.

Define Working Agreements

Creating clear working agreements ensures everyone is on the same page regarding processes and expectations.

• Communication Methods: Specify how team members should communicate, whether through video calls, messaging apps, or emails.
• Collaboration Tools: Decide on which tools to use for documentation, real-time collaboration, and async updates. Popular options include Slack for communication and Jira for task management.

Daily Scrum Pitfalls

There are tempting activities to avoid while conducting your daily scrum meeting. These are some of the common pitfalls to avoid:

1. Using the meeting as a status update

To the product owner, Scrum master, or other stakeholders. The main objective of this meeting is for the development team to answer their three questions so that they can make any needed adjustments to keep the sprint goal intact. It should not be used as a status meeting for developers to report on the progress of their work.

2. Turning it into a problem-solving session

To resolve any blocks that are discussed in the meeting within the 15-minute time frame. One thing will undoubtedly happen if the team attempts this — the meeting will run too long! The Scrum master should advise the team to stay on task during the meeting and defer these problem-solving attempts to time outside of the daily scrum meeting.

3. Focusing on a task board

As a means of tracking progress. The daily scrum meeting is a time for discussion. If the team is staring at a task board, it's wasting valuable time by focusing on the status of tasks and not on talking about making adjustments to its work.

In addition to these key points, there are several other common mistakes that can derail the effectiveness of a daily scrum:

• It’s become a boring status meeting that no one wants to attend. This indicates a lack of engagement and purpose.
• Developers are reporting personal performance to a scrum master or manager, which can undermine the collaborative spirit of the team.
• The meeting isn’t held if the scrum master can’t make it that day. This dependency can disrupt the consistency of daily progress checks.
• The team is trying to solve problems and find solutions during the daily scrum, which should be avoided to respect the timebox.
• The daily scrum is being used to refine work items, which is not its intended purpose. Refinement should occur separately.
• The timebox isn’t respected, leading some team members to feel like the meeting is a burden. It's crucial to stick to the 15-minute limit.
• Some developers think they don’t need to show up, which can result in misalignment and missed opportunities for team synchronization.

By being aware of these common pitfalls and maintaining a focused and efficient daily scrum, teams can ensure they are making the most of their time together and keeping their sprint goals on track.

Master Daily Scrum and Become an Agile Pro

At Easy Agile, we provide products to manage all of your Scrum events. We are passionate about making agile accessible and easy to understand for its participants. In addition to our products, we love to provide resources so you can level up your agile game 💪. Check out our blog and our podcast to become an agile pro!

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

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

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

Understanding Scrum values and the role of the Scrum Master

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

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

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

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

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

Characteristics that define a great Scrum Master

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

1. Emotional intelligence

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

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

2. Strong facilitation skills

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

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

3. Adaptability

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

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

4. Lifelong learner

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

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

5. Servant leadership

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

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

6. Analytical thinking

A great Scrum Master should be able to:

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

7. Motivational skills

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

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

8. Excellent communication

Communication is key. They need to:

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

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

Six strategies to become a great Scrum Master

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

1. Don’t forget to be agile yourself

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

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

2. Get to know your team

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

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

3. Foster a culture of continuous feedback

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

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

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

4. Hone your communication skills

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

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

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

5. Make the most of every retrospective

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

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

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

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

6. Become a certified Scrum Master

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

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

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

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

• SAFe Scrum Master SSM Certification
• SAFe Advanced Scrum Master

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

Easy Agile for Scrum Masters

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

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

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

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

As an agile team, you’re likely well aware of Jira software and its supreme capabilities for creating agile workflows. Jira workflows are a staple for development teams (ours included! 🕺), and there’s no question why.

Jira takes a customer-first approach to design projects, and it’s highly customizable, making it extremely popular among agile teams working in software development. As the folks who developed Jira at Atlassian like to say, “The more agile your team is, the more Jira will be able to help.”

Our team has been using Jira workflows for years, and we’ve learned a thing or two along the way. Okay, we’ve learned a lot along the way. 😎

We’ve also dedicated our company to making products that work directly with the Jira software you use. While you probably already know how to use Jira workflows, you may not be getting the most out of them. In this post, we’ll share seven best practices for getting the absolute most out of your workflows.

Free workflow apps

Try our FREE Jira workflow apps available on the Atlassian Marketplace!

Easy Agile Scrum Workflow for Jira

Easy Agile Kanban Workflow for Jira

Why dev teams choose Jira workflows

Unlike traditional project management tools, Jira takes an agile approach to product development. Jira Software is a family of software platforms designed to help agile teams do what they do even better, so team members can plan, track, and release great software every time.

The Jira server allows for multiple frameworks, including both Scrum and Kanban processes, making it completely versatile, no matter what style you’re used to. It helps you manage all phases of your workflow with complete visibility, and you can continually improve your performance based on detailed real-time data.

🙋🏼 If you’re new to Jira, follow this how-to tutorial from Atlassian for developers joining an existing Jira cloud project.

Jira workflow best practices and lessons learned

We love its flexibility and how it helps development teams work to meet stakeholder and customer needs. Our two CEOs worked directly with the Atlassian Jira team for five years, where they got to know the product inside and out.

1. Make customer-focused decisions

Every decision you make should be customer-focused. Repeat that again and again — you can even record it on your phone and listen to it while you sleep every night! Agile methodologies are especially effective because they focus on this priority in every problem.

Keep this mantra top of mind through every step of your Jira project, such as when you add workflows, create new workflows, define specific issue fields, or resolve issue types. To continually bring value to the customer, you need to visualize their journey from start to finish.

User story maps are invaluable tools for keeping customers at the forefront of everything you do. They help teams prioritize based on customer needs, and they give a clear view of the customer journey. It’s their story, after all, so why not view your backlog from their perspective?

Easy Agile TeamRhythm transforms flat backlogs into impactful, visual representations of the customer journey. The app integrates seamlessly with your agile boards in Jira and is designed to help teams provide value to customers quickly and frequently.

2. Use personas to gain a deeper understanding of your audience

Personas are the ultimate tool for empathizing with customers. They ask important questions about users so development teams can gain a deep understanding of the people who will use the product they’re working on. If you aren’t using personas yet, move it to the top of your to-do list.

A persona asks important questions of the user to capture buying habits, pain points, behavioral patterns, demographics, and more. Using these directly with your user story maps or alongside your product roadmap will help you make the decisions that will bring the most value to the customer.

Easy Agile Personas for Jira configures directly with your current Jira projects. The app has the functionality to create and store customer personas natively in Jira software, so you can prioritize customer needs every step of the way.

3. Create a workflow for your team, not everyone else

Some teams create a one-size-fits-all workflow and duplicate it across issue types with only small changes on the way. Depending on the team, that might not work. A status and transition that works for one issue type, for example, might not work for another. Some issues may require specific statuses and transitions, or even restrictions and automations that only work for them. You can mold a template, but it’ll never be the most effective workflow for your team.

Still, the one-size-fits-all approach is tempting. It’s easier too. But ultimately, the people on your team will end up working with a tool not made for them, but for someone else. Remember, as an admin your job is to serve the people on your team. You want your team to work with joy and harmony. You want your workflows to be effective for the people working in them, not easy to create for the admin. Putting in the effort now will have a scaling effect, given that the people on your team have to work in Jira every day.

If not one-size-fits-all then, what do we recommend?

Start from scratch. Start from zero, from nothing. Clear your mind of all templates that exist and do the work of talking to your team. Figure out the steps your team goes through and translate them into Jira. Talk to a representative from each role on your team, and make sure their needs are met. The best workflow is the one that’s tailored to your team, not for everyone else. It’s not easy and it’s going to take time, but your teams will thank you for it.

4. Don’t add more detail than what’s needed

When working in Jira, there’s such a thing as too much detail. Although it can be tempting to include absolutely everything, this may not actually be the best move.

Overuse of custom fields can lead to a slower response time on Jira issues, and it may cause frustrating holdups. Don’t get in your own way by creating an overly complicated structure. Whenever adding to your Jira workflow, think back to your customer needs and OKRs. Simple is often the more effective choice.

5. Don’t over-customize or overcomplicate

Custom workflows offer dev teams a solution that can be adapted to meet their current needs. But customization can come at a price.

As your Jira workflows evolve, they will become more and more unrecognizable from one workflow to the next. In some cases, they may get to the point of becoming a completely different species that will have trouble working with original versions.

Add custom fields when you need to, but don’t overdo it on complex workflows. Set standard practices across your team for how and when different workflows are customized to minimize compatibility issues. Ensure that customization is approved by those who understand OKRs and have the entire big picture in mind. It may be prudent for larger teams to limit admin assignee access to prevent unnecessary and possibly harmful customizations.

6. Keep your workflow simple: limit statuses and transitions

Adding a status for every part of your team’s process may seem like a good idea, and Jira definitely supports it. But keep in mind that every status and transition adds more complexity for the team working in the workflow. If you want to move fast, keep your process lean.

After mapping how your team works, include only the statuses and transitions you need. A workflow with too many statuses and transitions can be confusing to understand. Remember that the team working in the workflow will have to understand and use it.

7. Iterate on your workflow

It’s great to plan out your workflow, but don’t worry about getting the perfect workflow on the first try. Teams change, and Jira can adapt to those changes. What’s important is creating the best workflow you can now and iterating based on changes and feedback from the team.

This may seem counterintuitive, especially if your team isn’t used to working agile and wants to set and forget the workflows. Keep in mind that Jira workflows are here to serve your team’s needs at the current time. They’re here to adapt to your needs right now. As you evolve, your workflows evolve with you.

8. Involve stakeholders when creating workflows

These include both internal and external stakeholders in the process to ensure their needs are consistently met. The product manager is just one person with one viewpoint — you need a variety of team perspectives.

Stakeholders need to be involved, and they need to have continual access to essential documents, such as your product roadmap or user story map. These living documents are a work in progress. They represent the overall vision at any given time, and since they’re always evolving, your stakeholders need to know how to access them and how to decipher them.

When admins don’t involve the team in creating workflows, the workflow may not be the best one for the team. Remember that when you’re building a workflow, you’re doing it for people. These people will be working with the workflow you build, so make it work for them.

To create effective workflows, involve a stakeholder from each role within your multidisciplinary team. Here are some key roles to consider:

• Product Manager: Understands the overall vision and roadmap.
• Software Engineer: Knows the technical intricacies and feasibility.
• Product Designer: Focuses on user experience and interface design.
• Content Designer: Ensures that content is clear and effective.
• Quality Assurance Engineer: Guarantees the product meets quality standards.

Get a representative from each of these roles, find out how they work, and once you’ve created your workflows, check that they’re happy with them. If you don’t, you might end up with statuses and transitions that people don’t use, and you might miss important workflow rules that can speed your team up.

Then take your team’s feedback and iterate. They’re the ones who are working in Jira.

9. Teach stakeholders about the iterative process

When it comes to agile and working in Jira, everything is iterative. The plan you set out with is bound to change with the needs of your customers.

This is really difficult for some stakeholders to understand, especially if they’re not used to working with agile. The ideas and methodologies that come naturally to you may be completely foreign to the stakeholders and key customers you involve in the process.

Take it slow and BE PATIENT. Teach stakeholders about the agile process, and ensure they understand that any plan is completely subject to change. Plans are “living documents” that represent what the team hopes to accomplish based on what will provide the most value to customers in that snapshot of time.

10. Test your workflow

If you don’t test enough, you’ll have a workflow with so many errors they’re hard to fix. If you test too much too early, you won’t be able to move quickly. Testing is a balancing act. There are no hard rules, but there are two stages where people usually test their workflows:

Stage 1 - Testing the new workflow in a separate project or instance

Before you get your team to use your workflow, you want to check that everything works properly. To do so you can copy your workflow to:

• A separate Jira project
• A separate Jira site, if you have one

Either way, you want a place in Jira that doesn’t impact people in the project for testing. There you can create sample issues and manually run through every step of the workflow. You can check for things like:

• Whether the statuses and transitions make sense
• If the issue ever gets stuck at particular steps in the workflows
• Whether workflow rules are working properly
• How a representative from each role in your team goes through the workflow

Stage 2 - Testing with your team in your actual project

Testing is a continuous process.

After getting your workflow into Jira, there are bound to be problems your team runs into that you didn’t consider. That’s why it’s important to get feedback from the people actually using the workflow.

It’s not something you have to do every day, or even every week, but keep in touch with your team every now and then. If you have meetings about the tools you use or about how you work, make sure to talk about how the workflows are working for them.

11. Make use of agile Jira apps

Jira is a fantastic platform with tons of features and development tools for agile teams that we can’t praise highly enough, but it doesn’t come with everything. Take advantage of plugins designed to help teams just like yours. The Atlassian marketplace offers a number of Jira apps that provide specific solutions, including Easy Agile’s four Jira plugins:

• Easy Agile TeamRhythm
• Easy Agile Programs
• Easy Agile Roadmaps
• Easy Agile Personas

Each of our plugins seamlessly integrates with Jira to simplify your development and streamline your business process.

Marketplace

Try any of our apps free for 30 days — we’re sure you’ll love them. If you have questions, contact our team or watch the demos on each product page to learn more.

Agile is about being flexible and always getting better—essential for delivering great software. But when scaling agile across teams in a program, being adaptable and flexible is easier said than done. In this post, we'll dig into the ins and outs of agile program management to help you:

• Tackle common challenges
• Use metrics and feedback loops to keep improving
• Leverage leadership for the best chance of success

By identifying some clear and actionable steps that you can start implementing now, you’ll improve your approach to program management and make your software delivery smoother and more efficient.

Overcoming Common Challenges in Agile Program Management

From dealing with dependencies to managing stakeholder expectations and balancing speed with quality, here are some challenges you might face now.

Dealing with Dependencies

Dependencies are a necessary part of working on complex software, and they need to be managed carefully to avoid disrupting delivery schedules.

Identifying dependencies early is key to keeping things running smoothly. By spotting potential bottlenecks early, like during PI Planning, we can nip them in the bud before they turn into major headaches, and:

• allocate resources more effectively
• streamline communication across teams
• keep everyone on the same page with a shared timeline.

Maintain clear communication channels and regular alignment meetings to address dependencies swiftly and efficiently. This helps everything stay in sync, and hopefully avoids last-minute 'surprises', for a more reliable delivery.

Managing Stakeholder Expectations

We can't deliver complex software on our own, so ensuring that our colleagues are informed and onboard is critical. Managing expectations across a large program is a complex challenge, but you'll be off to a great start if you are able to keep communication consistent:

• Regular Updates: Keep the lines of communication open and honest, and provide frequent updates to keep everyone in the loop.
• Be Transparent: Maintain a central source of truth for project information that everyone has access to, ensuring that objectives, milestones and priorities are clear.
• Set Realistic Expectations: Avoid over-promising and stay realistic about what can be achieved.
• Prioritize and Manage Feedback: Inevitably, there will be changes in priorities or feedback from stakeholders. It's important to have a process for managing these requests and ensuring they align with the program goals.

Agile tools that offer clear visibility into objectives, dependencies, and progress, can be the bridge between your development teams and stakeholders in leadership and other parts of the business.

By focusing on these areas, you’re not just managing expectations—you’re making sure everyone is part of the process.

The bridge between development teams and leadership, with objectives, milestones and dependencies all in one. Watch a demo or try for yourself.

Easy Agile Programs

FEATURES & PRICING

Balancing Speed with Quality

In a perfect world, we would all deliver amazing software that our customers love, at lightning speed. But the reality is that balancing time-to-market with quality is an ongoing challenge.

Agile practices like organizing work to deliver incrementally are part of the solution; they help identify problems early and deliver in a way that makes more sense than following a Gantt chart until the timelines blow out and it all falls over.

So while agile won’t make your development teams type faster, it can help them, as well as your colleagues in Product, and QA, learn what works faster, and how they can collaborate better to deliver work with quality.

Metrics and Feedback Loops

Metrics can be a powerful tool in agile program management. Velocity, burn-down charts, cycle time, lead time, and dependency reports can give valuable insights into how our teams are performing and how our projects are progressing.

• Velocity: Long-term trends help us understand team commitment over time, and estimate what can be achieved going into a sprint.
• Burn-down charts: Valuable for gauging progress throughout execution and spotting barriers to delivery.
• Cycle time: Uncover inefficiencies or bottlenecks where tasks are likely to get delayed or stuck.
• Lead time: Use the difference between an expected lead time and the actual lead time, as a starting point for understanding where delivery is being held up.
• Dependency reports: Use a snapshot of dependencies in your program to understand how teams are dependent on each other and where the biggest risks are.

Monitoring these metrics will give you a clearer picture of where work is progressing well and where you might need to make adjustments. Think of them as your project’s health check-up; a temperature check that can improve the predictability of your release.

With powerful dependency reports, you can identify bottlenecks, streamline communication, and keep your projects on track.

Easy Agile Programs

FEATURES & PRICING

Establishing Effective Feedback Loops

Feedback loops are integral to delivering software with market fit. Sprint reviews and retrospectives offer teams the opportunity to reflect on their performance, identify areas for improvement, and make necessary adjustments. DevOps practices like continuous integration further ensure that the code is consistently tested and integrated, reducing the risk of significant issues going unnoticed.

Using metrics and feedback loops allows teams to deliver software with greater predictability and transparency. Applying these practices consistently across a program means that you're better able to manage the planning and execution of work to deliver complex software to your customers in a predictable way.

The Role of Leadership in Agile Program Management

Great leadership is key to building an agile culture. It's not just about making decisions from the top; it's understanding team needs and clearing the way for them to be effective. But old 'command and control' habits are difficult to break.

As a program manager, you're the glue that connects the strategic vision of leadership with the hands-on work of development teams. Keep those communication lines open and reciprocal, so everyone understands the business goals and the strategic importance of their tasks, as well as progress and barriers to execution.

• Use agile tools to maintain a central source of truth, to give everyone a clear view of project progress and potential roadblocks.
• Foster a culture of regular feedback and continuous improvement. This proactive approach helps tackle challenges head-on and keeps everyone aligned with business objectives.
• Promote transparency and adaptability to help teams quickly adjust to changing priorities.

Keep these things in mind to help you plan and deliver with confidence. You may be the glue that holds it all together, but you can't be everything for everyone. Enlist help where you need it, and encourage an open and transparent culture where strategic priorities are understood, and everyone can see how the focus of their work contributes to the bigger picture.

An Agile Approach to Change

Taking a new approach to program management doesn’t need to be daunting. Once you’ve identified the changes that make sense for you, take an agile approach and implement incrementally. Every small change you make adds up over time and can lead to measurable improvement.

How Easy Agile Programs Can Help

Easy Agile Programs is a Jira integration that supports agile program management. It is a central source of truth for the issues, milestones, team objectives, and dependencies that make up a program of work.

Dependency maps and reports help you see the nature of cross-team dependencies clearly, so you and your teams can reorganize to avoid roadblocks that would otherwise blow out timelines with unexpected delays.

Easy to set up and tightly integrated with Jira, Easy Agile Programs supports scaled team planning and execution so you have greater confidence in delivering great software as each program increment begins.

Agile software development is like a roadmap for getting software done right. As highlighted in the agile manifesto, it prioritizes real conversations over tools, delivering working software instead of drowning in documentation, collaborating with customers rather than just negotiating contracts, and being quick to adapt to change. The manifesto emphasizes the power of collaboration within cross-functional teams, making it relevant for project management in various contexts.

Think of agile as a mindset, not just a method. It empowers project teams to give and receive feedback in a friendly, iterative environment that leads to great results. While it gained popularity in software development, agile principles can actually work wonders for any project team. Whether it’s in construction management, content marketing, or even planning weddings, agile has you covered.

Let’s dive into why agile project management is a great fit for any team. We’ll explore how its principles can seamlessly fit into your project processes. Remember, it doesn't matter which agile framework—like Scrum or Kanban—you choose, as long as it suits your team. In short:

• Agile principles are perfect for team cooperation.
• Agile workflows for project teams are conducive to continuous iteration and improvement.
• The framework you choose, Scrum or Kanban, is less important than your team mindset.
• Using agile project management across your organization increases visibility and coordination.

Agile principles in project management

The core principles of agile — collaboration, empowerment, and transparency — are ideal for project management. No matter the type of team, the goal should be continuous improvement. Teams meet this goal by working together with an iterative approach to fulfill their projects.

Agile is a mindset of adaptability, sharing progress, and learning from what worked and what didn't. You improve as you go.

Thomas Edison encapsulates the spirit of an iterative approach perfectly: “I have not failed. I've just found 10,000 ways that don't work.” 💡It's this attitude that is the agile mindset.

Entities such as the Project Management Institute espouse the virtues of agile project management and its impact on teams’ collaboration:

• Teams are responsible for project delivery and self-organize in a way to maximize their opportunities for success.
• Agile project managers encourage discussion of frameworks and processes, but also encourage independent thinking.
• Agile values foster trust and healthy working relationships.
• As a decision-making framework, agile project management promotes accountability while driving continuous decision-making and delivery.

Agile workflows for project teams

How can a traditional project team become self-organizing enough to become more agile? Let's step through a Scrum workflow in the context of a general project.

Backlog

Development teams work from a product backlog, which is a list of prioritized features desired by a customer. But this list doesn't have to be a set of software features. It can be any set of tasks or outputs that a project team needs to complete.

Sprint planning meeting

Agile teams work in sprints, which are set periods of time (e.g., two weeks) to complete an agreed-upon amount of work. During sprint planning, the team reviews and discusses the top priorities from the backlog. They then decide what can be delivered in the sprint and commit to that work.

Let's use a marketing team working on a campaign as a non-typical example. In a traditional project management setting, the team may take a waterfall approach. They would create a months-long content calendar of social media, blog articles, videos, and other content. Under agile, they would only commit to the next two weeks of content production before deciding what comes next.

Stand-Ups

A stand-up is a daily meeting of team members. During it, each member answers three questions:

• What did you work on yesterday?
• What are you going to work on today?
• Are there any issues blocking your work from being completed?

The questions provide each person the opportunity to share their progress and to provide support in case they can unblock a teammate's work by helping to resolve their issue.

Sprint review

When the sprint is completed, teams meet to review and demo the work they just finished. In our marketing case, it can be a time for the team to get together to watch their content videos, read the comments and feedback from their social media posts, and review key metrics from all of their content.

Sprint retrospectives

Product development teams meet after each sprint to discuss how they might improve things for their next sprint. In this meeting, the team discusses:

• What went well?
• What didn't go so well?
• What can we improve going forward?

Suppose your marketing team had a post go unexpectedly viral. Why was it so effective? What can we learn from that to adjust the next two weeks of content? These are the types of questions to ask yourselves so you can continue to iterate and to learn together as a team.

Scrum or Kanban?

The workflow outlined above is a typical agile Scrum framework. However, it does not have to be the way agile practices are implemented in project management. Different types of projects may call for different frameworks. For example, in Scrum, roles are more clearly defined than in Kanban.

Scrum

A Scrum team is made of specific roles that are tasked with different responsibilities for moving the team through the development process. According to the Scrum Guide:

• Developers create a plan for each sprint iteration, define completeness of work, adapt their plan each day, and hold each other accountable.
• A product owner is responsible for managing the product backlog by communicating product goals, prioritizing items, and providing transparency into the full backlog.
• The Scrum master coaches and guides the team in its adoption of Scrum.

Kanban

Some projects may be more suited for Kanban as compared to Scrum. There are key differences between the two frameworks that may influence a team's approach to agile project management:

• Continuous workflow vs. fixed sprint iterations
• Continuous delivery vs. delivery after the completion of each sprint
• No set roles vs. defined scrum roles

Kanban teams use a Kanban board to visualize their tasks and to limit the amount of work that is in progress at a given time.

The agile framework you use, whether it is Scrum or Kanban, is less important than your team’s shared understanding of how you work together to achieve common goals. The beauty of an agile approach is its conduciveness to tweaking your framework and how you use it as you iterate and retrospect.

Agile project management for your whole organization

As software development teams continue to embrace agile processes, they can encourage other teams to join them. Using agile in other departments empowers those teams’ ability to collaborate. It also creates a shared sense of unity across your entire organization because you’re all applying the same methodology to get to each of your goals.

Try a daily stand-up for department leads to improve cross-organizational communication. Keep it short and to the point, focusing on the topics that will help the work progress.

The 17th State of Agile Report shared that 93% of executives thought that their teams could do the same amount of work in half the time, if their teams collaborated better.

That's quite a statistic. We’ll leave it up to you to decide whether this reflects a lack of efficiency due to poor collaboration, or a disconnect between leadership expectations and the realities faced by development teams.

What we do know is that improving team collaboration has benefits and that improved collaboration is a key benefit of effective agile practices.

So if you think your team could work more effectively, here are six tips for improving team collaboration that we think will make your working life better, and help you deliver for your customers.

1. Agile Teams Are Cross-Functional

Cross-functional teams are the backbone of agile collaboration. It's Agile 101:

The best architectures, requirements, and designs emerge from self-organizing teams.

Manifesto for Agile Software Development

Ideally, your agile team should be able to deliver work independently. The skills and expertise of your team should allow you to handle diverse tasks without creating dependencies on other teams. You can take ownership of the software you're delivering.

The benefit of organizing into cross-functional teams is a greater shared understanding of your project, where you can each see how the pieces fit together. This type of collaboration supports the efficient flow of work and ensures that knowledge and skills are consistently shared.

2. Take an Iterative Approach

Or to put it another way, make it easier to fail fast, so your team can learn why, and correct your course. By breaking down large projects into manageable increments, your team can focus on delivering small, functional parts of working software at regular intervals. This approach goes hand-in-hand with continual feedback from users, ensuring that issues are uncovered quickly and dealt with just as fast. This shared team focus on user feedback, and the shared purpose and collaboration that comes with it, is a key benefit of agile development.

3. Maintain Regular and Transparent Communication

Daily stand-ups, sprint reviews, and planning meetings are all designed to foster regular and clear communication. You and your team should see these meetings as an opportunity to share ideas, discuss progress and blockers, and collaborate. If your daily stand-up is nothing more than a shopping list of tasks, then you're doing it wrong.

If your daily stand-up is nothing more than a shopping list of tasks, then you're doing it wrong.

Someone who has wasted too much time in shopping-list meetings.

Beyond team meetings, clear communication is important anywhere the details of your work are shared. Agile tools like Easy Agile TeamRhythm provide a central platform for prioritizing work and tracking progress. With a central source of truth that everyone can access to understand goals, priorities, and team commitment, collaboration can be more effective, keeping the team aligned and focused.

4. Conduct Team Retrospectives

Hot take: regular retrospectives are the most important agile practice your team can adopt.

Team retrospectives provide a structured opportunity to reflect on your work and discuss how it can be done better next time. This is team-led improvement because you and your team are in the driver's seat. Encouraging honest and open discussions during retrospectives helps build trust among team members and fosters a collaborative mindset. By continuing to work on processes and behaviors, you and your team can improve your performance over time and make your working life better.

5. Use Collaboration Tools

The right tools can make a big difference in team collaboration. The best tools provide a reliable source of truth that the whole team can access, in a place where the whole team will access it. It's a simple concept; a shared understanding of the work is supported by shared and willing access to the same information.

Choose a tool that makes it easy for you and your team to access information and keep it updated. If you're already working in Jira, an integration like Easy Agile TeamRhythm provides a better view of your work in a story map format, with goals, objectives, and team commitment all made clear. Team retrospective boards are attached to each sprint (or spun up as required for Kanban teams) so you have your team-led ideas for improvement tightly connected to the work in Jira.

No matter which tool you choose, make sure it will facilitate better alignment, streamline your workflows, and provide a clear picture of roadblocks and progress. By using collaboration tools effectively, your team stays organized, focused, and connected, no matter where each member is located.

6. Build a Positive Team Culture

It may sound obvious, but a positive team culture is essential for effective collaboration. Creating an environment where team members feel valued, respected, and motivated, encourages the psychological safety they need to share their great ideas, learn from missteps, and collaborate more effectively with their colleagues.

High-performing teams recognize the achievements of others, share constructive feedback, and support practices that lead to a healthy work-life balance. Make it regular, and keep it authentic. A positive culture not only improves team dynamics but also boosts overall productivity and job satisfaction.

Successful Team Collaboration

Effective collaboration can be the difference between your team achieving their goals, or falling short. By embracing agile practices like the regular communication that comes from agile planning meetings, to the learnings that come from taking an interactive approach to development, and creating time for team-led improvement with retrospectives, you can seriously boost your team dynamics.

Easy Agile TeamRhythm Supports Team Collaboration

Easy Agile TeamRhythm is designed to make your agile practices more accessible and effective, helping your team plan, prioritize, and deliver work with better alignment and clarity.

Built around a story map for visualizing work and retrospective boards that encourage team-led improvement, TeamRhythm facilitates sprint and release planning, dependency management, backlog management, user story mapping, and retrospectives.

Tight integration with Jira makes Easy Agile TeamRhythm a reliable source of truth, no matter where you and your team members are located.

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

‍

You're part of an agile team. You know the drill. You have an agile mindset, you and your team members participate in the agile ceremonies, and you use agile tools like Jira. All good! But there's also a good chance that you're part of a larger organization that either doesn't fully grasp agile practices or needs an agile transformation itself. That's where an agile coach can step in.

Let's face it — if your organization was perfectly aligned in its agile framework, you wouldn't be reading this post. 😉 In many large organizations, the adoption of agile practices is limited to a subset of teams, most notably the software development and project management teams.

But you want more — you want to be a master in agile ways. An old saying goes something like, "the best way to learn something is to teach it." Or, as Yoda put it, "Always two there are, no more, no less. A master and an apprentice.”

In this post, we'll explain what's at the core of being an effective agile coach, the differences between an agile coach at the team level vs. the organization level, and a sample path to becoming a certified agile coach. We'll also provide you with some of our best educational resources to keep you sharp no matter what stage of your agile journey you're in.

What is an agile coach?

Let's get one thing out of the way. An agile coach is not an instructor with cat-like reflexes.

Our agile coach provides professional coaching and know-how by helping organizations understand the agile methodology and its benefits well enough to implement it at scale across cross-functional teams. This is provided in two buckets:

• Working with a subset of an organization (teams, managers, and stakeholders) on agile best practices to improve performance and outcomes
• Facilitating organizational change by working with leadership to remove barriers that allow for a full agile transformation

An agile coaching role is not a one-size-fits-all. It can be a permanent or temporary position at a company. Agile coaches come from a variety of backgrounds, including software developer, product owner, Scrum master, and project manager.

An agile coach is a facilitator. Because it is a mentoring role, an agile coach should have competencies in collaboration and communication.

So, you want to be an agile coach

You're all in. You want to expand your agile expertise by teaching its principles or teach agile methods outside of your team. Well, where do you get started? Here's the plan.

Let's tackle it with a three-pronged approach:

1. Learning the agile frameworks
2. Getting involved in an agile community
3. Formal agile training

Learning the agile frameworks

Typically, you want some experience working in agile frameworks before embarking on formal agile coaching certifications. That said, it can be difficult to master the multitude of frameworks within agile development, even over the course of a lengthy career. To whit:

• Scrum
• Kanban
• ScrumBan
• DevOps
• Digital Agile (DA)
• eXtreme Programming (XP)
• Praxis
• Scaled Agile Framework (SAFe)
• Large—Scale Scrum (LeSS)

But wait...there's more! We'll run out of ink if we list them all, so let's move on. ✍️

Many of us spend the majority of our time working with one or two frameworks, or a hybrid of them. For example, you can work for a long time in a Scrum environment before mastering all of the following:

• Scrum roles
• Scrum artifacts
• Scrum ceremonies

And that's ok! We suggest mastering what you can in your own work environment, like Scrum, then learning as much as you can about another one or two that may interest you that you may not have the opportunity to practice directly. For example, learning about SAFe or LeSS and how they empower agile practices at scale would be a great place to start.

One key tip to keep in mind — it's easy to lose sight of the core principles of agile if you become too mired in practicing frameworks on a day-to-day basis. Every once in a while, close your eyes and go back and read the agile manifesto (ok, you actually need to open your eyes, but you know what we're suggesting):

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

You can open your eyes now.

If you're already working within a framework like Scrum with a development team as a Scrum master or product owner, then you probably have a lot of the prerequisites needed to get started in agile coach training courses.

Getting involved in an agile community

Before you apply for an agile coaching certification, it's a good idea to be involved in an agile community. This accomplishes three things:

1. It keeps you up-to-date on current happenings in the agile world.
2. It exposes you to agile methodologies and ideas that peers are practicing outside in their own organizations.
3. It demonstrates that you're committed to practicing agile as a career pursuit — which we'll soon see is important in the application process for becoming a certified agile coach.

You can find agile communities locally or remotely.

Formal agile training

If you want to get hired as an agile coach, it's a good idea to pursue some agile certifications. The most recognizable training courses are offered by the Scrum Alliance. There are two tracks you can take to becoming a Certified Agile Coach, depending on your interest — Certified Team Coach (CTC) or Certified Enterprise Coach (CEC). The are differences between these two tracks that are important to understand:

• A CTC works with multiple agile teams, coaching Scrum masters, product owners, and company managers. A CTC generally sticks to mentoring one area of an organization, such as software development.
• A CEC typically coaches at the executive leadership level at an organization. A CEC is an enterprise agile coach whose goal is to assist an organization in successfully achieving a full agile transformation.

You're probably wondering...how much of a commitment is it to achieve certification? We won't sugarcoat it — it's significant. But that commitment can lead to a career-long ability to have a meaningful impact on teams and organizations. In short, here’s what you need to become a CTC or CEC:

• Be an active Certified Scrum Professional
• Submit a first application describing your agile experience, including team and organization coaching experience, agile community participation, and your use of agile practices
• Submit a second application that evaluates your knowledge, mindset, and approach as a coach and that requires mentor and customer recommendations
• An annual certification fee
• Continuing education requirements to maintain your certification

Great agile coaches keep learning

It can take a long time to build the experience to become an agile coach. After that, it's important to stay in tune with core agile concepts and how they relate to current trends in software development in order to remain knowledgeable enough to maintain your credentials.

We believe our agile resources are as good for continuing education as you can find. Here are some posts that highlight some of the key areas we talked about earlier:

• What's the Difference Between Kanban vs. Scrum?
• Learn Agile First — Then Learn How to Scale It
• Why large enterprises need Scaled Agile Framework (SAFe), not team—level Agile

But wait...there's more! Head over to our blog for our treasure trove of resources — and when you get tired of reading, put on your headphones and tune in to our podcast episode featuring an agile coach.

You’ve come to the end of your sprint. Your team planned and prioritized the most important tasks and executed them as well as possible. It’s just almost time to begin planning again, and jump into the next sprint...

BUT — there’s a critical step you've overlooked. The team retrospective meeting.

What went well? What didn’t go well? What do you need to improve upon for next time?

We built this guide based on years of agile training and software development experience. Our ultimate guide to retrospectives has everything you need to run effective retrospective meetings, including the benefits of retrospectives, how to run them well, and extra resources.

An intro: what is agile?

But first, a review of agile. If you’re already familiar, feel free to skip ahead to the next section on retrospectives.

One of our favorite ways to differentiate the agile methodology from traditional, waterfall project management is to compare the approaches to jazz vs. classical music.

In classical music, a conductor brings a piece of music to an orchestra. The conductor guides the group through the piece, dictating exactly what happens where and when based on their own previously decided ideas. It’s a lot like traditional project management. A project manager creates a plan, brings it to their team, and tells them how to carry it out. Each step plays out as it was designed to, under the careful observation of the project leader.

Now, consider jazz music. Jazz is collaborative, with each bandmate feeding off of each other in a flexible environment. The band doesn’t go in completely blind. Everyone is working off of a piece of music — but it’s not strictly adhered to, allowing for new directions to be discovered in the moment. The band, just like an agile team, works together to create music flexibly and iteratively, with each iteration a little different — and hopefully even better — than the last.

💡 Learn more: Agile 101: A Beginner's Guide to Agile Methodology

Traditional project management isn’t flexible. Instead, team members must work in a sequential order that’s dictated by the original plan and project manager. Think of an assembly line. The same steps are followed from project to project. The linear structure means that if one piece of a project stalls, the entire project stalls.

Agile, on the other hand, is non-linear. It focuses on collaboration between team members, flexibility, and delivering consistent value to stakeholders throughout the development process. Each new iteration yields actionable insights about what’s working and what isn’t. This multidimensional way of working eliminates the bottlenecks and dependencies that are common with traditional project management.

What is a retrospective?

Retrospectives are a staple of many agile processes. They can be a critical moment for teams to come together and provide feedback about how processes can improve. Retrospectives keep the agile process — well — agile and encourage continuous improvement. No matter how well the last sprint went, there is always something that can be improved upon for the next iteration.

Agile retrospectives help agile teams gather data and feedback from those involved in the Scrum process. In Scrum, a retrospective is held at the end of every sprint, which is generally every two weeks. The retrospective is a chance for all team members to share what went well, what didn’t, and what could be improved upon for next time. The insights are taken into account in the next planning session to ensure teams learn from their mistakes, successes, and each other.

How retrospectives fit with Scrum

Retrospectives are conducted in a variety of agile methodologies, but for the purposes of our Retrospectives Guide, we’re going to discuss retrospectives within the Scrum process. It’s one of four critical meetings used in Scrum, coming at the conclusion of each sprint. So, how are retrospective meetings utilized in Scrum?

Scrum artifacts

Artifacts are the pieces of work the team completes over the course of the sprint. The product backlog is a compilation of tasks that the team believes need to get done in order to complete a product or iteration of a product. The product backlog is large and not very refined.

Items from the product backlog get moved into the sprint backlog when it’s time for them to be completed. The sprint backlog represents everything the team hopes to accomplish over one sprint, which generally lasts for two weeks. The sprint backlog is more refined — it focuses on the current state of the product, stakeholder feedback, and customer needs.

Scrum roles

There are three Scrum roles, and each has different duties within the Scrum framework. The product owner prioritizes the work that needs to be completed over the course of each sprint. They refine and prioritize backlog items, moving the necessary product backlog items into the sprint backlog.

The next role is the Scrum Master, who guides the team during the two week sprint, ensuring the Scrum framework is adhered to. This person is an expert in all things Scrum and can act as a facilitator during daily stand-ups and other important meetings. The Scrum Master tends to play a key role in leading retrospectives.

Lastly comes the development team. They make up the bulk of the team and complete the work set out in the sprint backlog. The development team participates in planning, attends daily stand-up meetings, and delivers work to the client and stakeholders.

Stakeholders and customers, while not directly on the Scrum team, play important roles in the Scrum process. Stakeholder and customer needs must always be at the forefront of development decisions. Stakeholders should be brought in early and often to provide critical feedback as a product is being developed.

Scrum ceremonies

The Scrum ceremonies are the events that take place within the Scrum framework. First comes sprint planning to set the stage, then daily Scrums or standup meetings, followed by a sprint review and a sprint retrospective.

The sprint planning meeting is when everything gets set up for the next sprint. Sprint planning meetings are opportunities to prioritize backlog items and get the entire team aligned on their goals for the upcoming two weeks. Without planning, the team won’t have clear goals, and they won’t know what tasks to tackle next.

The daily stand-up, sometimes called a daily Scrum, occurs every day of the sprint. The entire team participates in this daily meeting that updates everyone involved in the sprint. During the meeting, team members update each other on what they accomplished over the past 24 hours and what they hope to accomplish over the next 24 hours. This time also serves as an opportunity to discuss any issues that occurred or potential roadblocks that could prevent work from moving forward smoothly.

The sprint review meeting happens at the end of the sprint and is an opportunity to discuss the success of the sprint based on what tasks are considered “Done.” The sprint review can also bring stakeholders into the Scrum process to ensure everyone still aligns on where the product is going and what should happen next. Stakeholders provide invaluable insights that ensure the team stays on track to meet customer needs.

The last ceremony in the Scrum framework is the shining star in our guide. The sprint retrospective meeting arrives at the end of every sprint. It’s a critical meeting that helps the team improve from one sprint to the next. It allows team members to share what went well, what didn’t go so well, and what could be improved upon for next time.

We’ll dissect the elements of a good sprint retrospective throughout the rest of this guide.

💡 Learn more about the differences between these four meetings in our article: Agile Ceremonies: Your Guide to the Four Stages.

The benefits of retrospectives

Retrospectives put the iterative in agile. They provide a focused time for teams to learn from the past and each other so they can constantly improve the development process. Retrospective benefits are vast, and they trickle down into all areas of development. The insights from a retrospective can improve productivity, team dynamics, team trust, customer value, and the overall Scrum process.

Retrospective benefits include:

• Documenting feedback in real-time after each sprint
• Exposing issues from the previous sprint that are holding the product or team back
• Aligning the team around the most important issues
• Giving everyone involved an opportunity to express ideas, thoughts, and experiences
• Informing leadership of potential roadblocks
• Bringing the team together around common goals and action items
• Establishing a safe space for sharing positive and constructive feedback
• Encouraging a continuous improvement mindset
• Helping product owners make decisions for the next sprint
• Setting the team on a positive path for the next sprint

6 Effective retrospective techniques

Now that you know why retrospectives are so important to the agile process, it’s time to dig into how to run them effectively. Use our 7 retrospective techniques for a smooth meeting that keeps everyone engaged and always results in quality insights.

1. Choose a time that works for everyone and stick to it

It’s important that every member of the Scrum team participates in the retrospective. This means holding it when everyone is available, whether that’s in-person or virtually.

Get feedback from your team about the best time to set this meeting. It should take place right after the sprint ends but before the planning meeting for the next sprint. This can be a tight window, which is why it helps to schedule this meeting at the same time every two weeks.

Consistent meeting times help ensure the meeting actually happens and that an optimal number of team members can attend.

2. Find new and creative ways to acquire feedback

The Start, Stop, Continue format can take many forms, but the general process is the same. The team discusses what they want to start doing, what they want to stop doing, and what they want to continue doing in the next sprint. It’s a simple framework that addresses both what went well with the previous sprint and what could be improved for next time.

This is a tried and true method, but it’s also important to change up your format and ask different questions to keep the team engaged.

You are trying to acquire similar information each time (what to start, stop, and continue), but the way you gather that information can change and evolve. Add variety to your Scrum retrospective and mix things up every once in a while to keep everyone engaged.

Find new ways of asking similar questions, and bring in new ice-breakers that help the team feel comfortable discussing the past two weeks with honesty and clarity.

Other versions of “Start, Stop, Continue” include the Rose, Bud, Thorn exercise, where team members discuss something positive about the experience, a “budding” opportunity that can be expanded on for next time, and something negative about the experience that should be improved upon. Another alternative is the Anchors and Sails exercise. What about the last sprint weighed or anchored the team down, and what positives put wind in their sails, so to speak?

Boring retrospectives will make team members dread the meeting and will lower participation significantly. If participants aren’t engaged, they won’t contribute as openly, and they won't take ownership over the process.

Mixing things up is also a good way to uncover insights the team hasn’t considered before. New questions will spark new ideas, issues, and solutions that otherwise would not have been discovered.

3. Ensure all voices are heard

All voices need to be heard in the retrospective. It’s the responsibility of the meeting facilitators to make sure everyone has a chance to speak during the meeting and that loud or dominant personalities don't overtake the conversation. They have to be heard too, but not at the expense of more introverted team members.

If you notice some members of your team do not participate, start asking them direct questions. If this only makes them retreat further into their shell, take them aside at the end of the meeting for a one-on-one conversation. How can you make the meeting environment more comfortable for them? What will best enable them to collaborate effectively? Ensure this is framed in the right way so it doesn't sound like they're in trouble but rather like you value and appreciate their input.

4. Establish a comfortable environment

Ensure the retrospective feels safe and comfortable for everyone involved by instilling trust, collaboration, and open dialogue. Each team member should feel like their voice is important. It should be a place of positivity, not a chance for team members to dunk on one another. It’s up to the facilitator to ensure everyone is comfortable.

There should be room for everyone to speak. The whole team should feel like they can express their thoughts and opinions about what happened over the course of the sprint. If people feel uncomfortable or think their voice won't be appreciated or heard, they will hold back and not actually express their honest feedback.

This is detrimental to the process, as it can leave recurring issues to fester and worsen over the course of future sprints. It is in everyone’s best interest to be open and honest and to hear everyone out. The goal of a retrospective is to solve issues, prevent roadblocks, and improve the team’s processes. If team members are silent or dishonest about how they feel things are going, nothing will be solved.

Comfort plays a big role in how honest everyone will be. Ensure everyone is respectful and that speaking time is shared across the team. Take time building trust and allowing the team to get to know each other. A team that trusts one another can work together and build each other up — and you’ll be able to manage issues before they begin to hinder productivity, team wellness, or the Scrum process.

5. Document everything and create clear action items

If you don’t document it, it didn’t happen. Don’t rely on memory alone after the retrospective. Document the feedback team members provide, and ensure any important ideas or issues are brought to the next planning meeting.

Turn important insights into action items to make sure ideas are not lost. Ensure action items are specific and clear and that the whole team understands what “done” actually means for each task. Once an action item is created, make sure there is follow-up, ideally at the beginning of the next retrospective. Determine who is responsible for the action item and how important it is in the grand scheme of your product backlog.

6. Review your action items at the next retrospective

So, you’ve collected your and your team’s insights and made those insights into action items. The final step is addressing those action items during the next retrospective. Were they resolved, or did the same issues keep occurring?

It’s best practice to review your previous retrospective action items at the beginning of the next retro. Did the team make progress on the task? What else needs to happen? Do you need to follow up again at the next retrospective meeting?

What happens after the retrospective?

The retrospective may be the last meeting of the sprint, but it doesn't end there. Take those insights into the next sprint.

After the retrospective, the product owner reevaluates the product backlog and chooses what will go into the sprint backlog for the next round of work. They should consider past mistakes, successes, stakeholder feedback, and retrospective insights as they make decisions.

The sprint planning meeting comes after the retrospective and will help the team regroup and align on what they need to accomplish next. With each sprint, you will gain more information about the product, your customers, how the team works together, and your overall process. These lessons are taken into account to make improvements from sprint to sprint and product to product.

For better sprints, read our sprint planning guide, which includes everything you need to run efficient and effective planning meetings. ➡️ The Ultimate Agile Sprint Planning Guide.

Turn an action item into a Jira issue in just a few clicks, then schedule the work to ensure your ideas aren’t lost at the end of the retrospective.

Use Easy Agile TeamRhythm

LEARN MORE

Retrospective mistakes to avoid

Collecting feedback may sound simple, but there are many ways a retrospective can go wrong — from overpowering team members to asking repetitive questions to failing to capture insights effectively. Read our list of common retrospective mistakes to make sure your team doesn’t drop the ball.

❌ Skipping or delaying the retrospective

Due to a lack of time or resources, teams may consider skipping the retrospective. This is a costly mistake.

Do not, under any circumstances, skip a sprint retrospective. This is a critical time when the team has a chance to improve their processes. Skipping a retrospective enables the status quo and encourages complacency. The agile process is about continuous improvement — without the retrospective, you lose a critical opportunity to learn about the strengths and weaknesses of your team and its processes.

Delaying the retrospective can also be detrimental to your progress as a Scrum team. It’s important that you gather insights right after the sprint ends — while the ideas and issues are still fresh.

Delaying the retro could result in team members forgetting how the process actually went, leading to bland feedback that lacks the kind of detail that can create positive changes. And if delayed too long, something else could come up that takes priority over the retrospective, meaning the meeting may never occur at all.

❌ Always asking the same questions

The Scrum process is repetitive by nature, but that doesn’t mean your retrospectives should be boring or unbearably dry. Sticking to the status quo is a huge mistake in retrospectives.

When you repeat the same meeting every two weeks, you need to add variety in order to keep the team engaged. As soon as you lose team attention, engagement will drop, and the quality of the feedback you receive will too.

When running a retrospective, check in with yourself and the team to make sure engagement and interest stay high. If you are losing people’s attention and find engagement is dropping, change your format or the types of questions to keep everyone awake, attentive, and on their toes. Switching up who facilitates the meeting is another way to add variety into the mix.

❌ Allowing some of the group to dominate the conversation

Every voice on the team needs to be heard, but sometimes it’s the loudest ones that come through, well, the loudest. 📢 Effective retrospectives require multiple perspectives to deliver fresh insights.

Don’t let a select few voices dominate the conversation. A domineering team member will use all of the meeting’s time and limit the insights you can gather. If every voice isn’t heard, problems with the process could persist throughout multiple future sprints, severely impacting the effectiveness of your team. Plus, those who aren’t as loud will feel less involved and undervalued.

❌ Failing to empower softer voices

Along with discouraging domineering behavior, you need to amplify the softer voices.

Some people will be less likely to engage, or they may be too shy or afraid to express their opinions in a group setting. Watch out for this. If you notice it, find ways to make those underheard voices heard. It could mean asking them questions directly during the meeting, or it could mean taking a shy team member aside after the meeting to collect insights one-on-one.

If they find the group or your process intimidating, make the necessary adjustments to ensure everyone feels comfortable expressing their thoughts about the sprint. A retrospective is a collaborative process. Do what you can to engage and empower every member of the team.

❌ Jumping to conclusions without discussion

A single statement from one team member isn’t the end of the conversation. When team members bring up issues or ideas, they need to be discussed as a team. Do others feel the same way? Is it critical that this idea be implemented immediately, or can it be put on the back burner for now? How does a particular insight impact the product or customer needs specifically?

Don't jump to conclusions without having a meaningful discussion. You can gather information from your team quickly without throwing off your set meeting timeline. Don’t let any one topic throw you off course, but ensure you aren’t overlooking anything. If the team agrees an idea has merit, turn it into an action item that can be followed up on at the next retrospective meeting.

❌ Not implementing insights into the next sprint

Unfortunately, this is quite common. A team holds a retrospective meeting and does almost everything right only to fail to thoroughly record their team’s insights and put them into practice.

The whole point of the retrospective is to help your team improve. If you don’t properly document the feedback you receive from the team and don’t put those insights into action, you’re not getting the most from your retrospectives.

Turn feedback and discussion topics into clear action items you can follow up on later. Take important action items and insights into your sprint planning meeting and check in at your next retrospective. Were you able to make progress on the previous retrospective’s action items? What roadblocks did you hit? Do the action items require any further attention or follow-up?

❌ Not improving your retrospective process

Even a retrospective could use a retrospective! 🤯

Every now and again, take time to review your retrospective process. Ask your team to provide feedback on how they think the meetings are going. What do they like, what do they not like, and how do they think the retrospective meetings could improve?

You can improve on each aspect of your agile process. Go straight to the source to gather the opinions of those involved in the meeting. Do team members feel heard? Have issues been addressed to their satisfaction? Have the meetings grown stagnant?

When it comes to improving your retrospectives, your team has the data. Do not hesitate to ask.

Just because retrospectives come last in the Scrum process doesn’t mean they aren’t important. Don’t lose steam as you cross the finish line. Hold a retrospective at the end of every two-week sprint. Ensure each sprint retrospective includes insights from each team member and that insights are documented and transformed into clear action items.

📚 Additional resources

We have a wealth of free resources on the Easy Agile blog, and we continue to add to it every week. We recommend checking out our other guides as well as our top-performing agile content.

• The Ultimate Guide to PI Planning
• The Ultimate Guide to User Story Mapping
• Product Roadmaps: Your Guide To Why and How To Use Them
• The Difference Between a Flat Product Backlog and a User Story Map
• What's the Difference Between Kanban vs. Scrum?
• DEEP: The 4 Characteristics of a Good Product Backlog

Thanks for reading our ultimate retrospectives guide! 👏 If you have any questions about this guide, our other content, or Easy Agile products, reach out to our team. We love talking to teams and individuals about agile and how to work better together. We’ll continue to update this guide as we gain more retrospective insights, techniques, tools, and best practices.

Using Easy Agile to improve your Agile process

If your sprint retrospective isn’t effective, your next sprint will suffer from the same issues. 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.

Improve your Retrospectives with Easy Agile TeamRhythm. The Retrospective features in TeamRhythm help your team stay on the path of continuous improvement. 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.

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

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.

‍

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.

Sometimes the idea of writing user stories can seem like another "thing" on top of an already busy workload. But for software development teams who are looking to lead their own improvement and deliver software that works for their customers, writing effective user stories is the first step.

If you’re reading this post, it means you want to learn what will work best for the people who use your software, and improve how you approach software development. That's great! Our goal at Easy Agile is to help you do that.

So let’s start with why good user stories are important.

Why write user stories?

You may wonder why you should write user stories rather than writing features or tasks instead.

If this sounds like you, you might not yet have seen the value of writing user stories, and that they serve a very different purpose to writing features or tasks.

It’s easy to get buried in a cycle of feature development that lacks context. The objective becomes more about clearing your way through a large backlog than building solutions that add value for your customers. To build successful software, you need to focus on the needs of the people who will be using it. Your human customers. User stories bring that context and perspective into the development cycle.

What is a user story?

A user story helps agile software development teams to empathize with their customers. Written from the customer (or user) perspective, user stories help the development team understand what they need to build, and why they need to build it.

User stories are simplified, high-level descriptions of a user’s requirements written from that end user’s perspective. A user story is not a contextless feature, written in “dev” speak.

A User Story = the 'what'

A user story describes a piece of functionality from the point of view of the user.

User stories divide features into business processes.

A task = the 'how'

Tasks are the activities that need to be performed to deliver an outcome.

Tasks are individual pieces of work.

How do we write user stories?

You might like to think of a user story as an ‘equation’:

As a [user] + I want [intent] + so that [value]

Let’s break this down further;

As a [user] — this is the WHO. Who are we building this for? Who is the user?

I want [intention] — this is the WHAT. What are we building? What is the intent?

So that [value] — this is the WHY. Why are we building it? What is the value for the customer?

Let’s look at a few simple examples;

As an internet banking customer

I want to see a rolling balance for my everyday accounts

So that I can keep track of my spending after each transaction is applied

OR

As an administrator

I want to be able to create other administrators for certain projects

So that I can delegate tasks more efficiently

Following this equation, teams should make sure that their user stories are ticking all of the following checkboxes:

To write successful user stories:

• Keep them short
• Keep them simple
• Write from the perspective of the user
• Make the value or benefit of the story clear
• Describe one piece of functionality
• Write user stories as a team
• Use acceptance criteria to show an MVP.

Acceptance Criteria

User stories allow agile teams to balance the needs, wants and values of their customers with the activities they need to accomplish to provide that value.

The link pairing these two things together is acceptance criteria.

Acceptance Criteria or ‘conditions of satisfaction’, provide a detailed scope of user requirements. They help the team understand the value of the user story and help the team know when they can consider something to be done.

Acceptance Criteria Goals

Acceptance criteria should:

• clarify what the team should build before they start work
• ensure a common understanding of the problem or needs of the customer
• help team members know when the story is complete
• help verify the story via automated tests.

Let’s look at an example of a completed user story with acceptance criteria:

As a potential conference attendee, I want to be able to register for the conference online, so that registration is simple and paperless.

Acceptance Criteria:

• Conference Attendance Form
• A user cannot submit a form without filling out all of the mandatory fields (First Name, Last Name, Company Name, Email Address, Position Title, Billing Information)
• Information from the form is stored in the registration database
• Protection against spam is working
• Payment can be made via Paypal, Debit, or Credit Card
• An acknowledgment email is sent to the attendee after submitting the form

With this in mind, teams should make sure that their acceptance criteria considers all of the following:

• Negative scenarios of the functionality
• Functional and non-functional use cases
• Performance concerns and guidelines
• What the system or feature intends to do
• End-to-user flow
• The impact of a user story on other features
• UX concerns

Acceptance criteria should NOT include the following:

• Code review was done
• Non-blocker or major issues
• Performance testing performed
• Acceptance and functional testing done
  

Why?

Your acceptance criteria should not include any of the above, because your team should already have a clear understanding of what your Definition of Done (DoD) includes, for instance:

• unit/integrated testing
• ready for acceptance test
• deployed on demo server
• releasable

Writing effective user stories is a valuable practice that will help you and your team deliver software that stays relevant for your customers.

When you embrace user stories as more than just another task on your checklist, but instead view them as an essential tool for creating context and value for your projects, you can stay connected with your ultimate focus - your customer.

Transform your backlog into a meaningful picture of work to gain context for sprint and version planning, backlog refinement, and user story mapping.

Stay focused on your customers

Easy Agile TeamRhythm

You may be just starting out, or you may have worked with agile methodologies for a while, but we’re sure you can agree that scaling agile in a large organization can be daunting. PI Planning is key to scaling agile, so we’ve developed this guide to help you run successful planning sessions, and build your confidence for your next scaled planning event.

We'll cover:

• What is PI Planning?
• Why do PI Planning?
• What is the goal of PI Planning?
• What should be included in the PI Planning agenda?
• What happens in the first part of the PI Planning meeting?
• Why is a confidence vote held at the end of PI Planning?
• When is PI Planning held?
• What is a pre-PI Planning event and when is it needed?
• PI Planning in SAFe
• PI Planning in Scrum
• What is the difference between a PI Roadmap and a Solution Roadmap?
• What is a program?
• What is a program board?
• Who should be involved in PI Planning?
• How to prepare for PI Planning
• What happens after PI Planning?
• What is a post-PI Planning event?
• Remote or hybrid PI Planning
• Common PI Planning mistakes
• Using Jira for PI Planning

Let’s start with the basics…

What is PI Planning?

PI Planning stands for Program Increment Planning.

PI Planning sessions are regularly scheduled events where teams within the same Agile Release Train (ART) meet to align and agree on what comes next. Teams will aim to align on goals and priorities, discuss features, plan the roadmap, and identify cross-team dependencies.

The goal is to align the teams to the mission and each other. Here are the essential elements of PI Planning:

• 2 full day events run every 8-12 weeks (depending on the length of your increments)
• Product Managers work to prioritize the planned features for the increment beforehand
• Development teams own user story planning and estimation
• Engineers and UX teams work to validate the planning

Why do PI Planning?

PI Planning is incredibly beneficial for large-scale agile organizations. PI Planning enables:

• Communication
• Visibility
• Collaboration

To understand the impact, let’s look at an example of a large organization that hasn’t yet implemented PI Planning. This organization has 250 teams and 6,500 team members. These teams rarely speak to each other, outside of dealing with a critical issue that has forced them to collaborate.

Alignment across these teams happens at the leadership team level, and they have multiple levels of managers in between who cascade information down with varying success. There is a constant battle for resources, budget, and opportunities to work on the most exciting projects.

Their projects have a habit of conflicting - one team would release something and then it would break something in another team’s project.

PI Planning is the first time many big companies get their teams together in a room or on the same call to talk to each other. This is a chance to have important conversations about who is working on what.

Why is this important?

1. When you’re touching a system or a code repository, you need to know how it’s going to impact another team
2. You might need to do some work to enable another team to work on their feature first (and vice versa)

With proper planning and collaboration, teams can get things done more effectively, release with more predictability, and stay on budget.

All very good reasons to do PI Planning.

What is the goal of PI Planning?

PI Planning is an essential part of the Scaled Agile Framework, a framework that’s designed to bring agile to large companies with multiple teams.

SAFe PI Planning helps teams in the Agile Release Train (ART) synchronize, collaborate, and align on workflows, objectives, releases, and more.

Without PI Planning, teams don’t have structured communication. They may not know what the other teams are working on, which can cause a lot of problems. For example, two teams might be working on different features without realizing there’s a dependency, which could hold up the release or require a significant rework of the code.

The goal of PI Planning is to have all your teams aligned strategically and enable cross-team collaboration to avoid these potential problems.

Now that we’ve covered off the “why”, let’s dig a bit deeper into the “what”. The best way to get a picture of what happens during PI Planning is to take a look at an agenda.

What should be included in the PI Planning agenda?

Here’s a standard PI Planning agenda template:

Day 1 AgendaDay 2 Agenda8:00 - 9:00 | Business Context8:00 - 9:00 | Planning Adjustments9:00 - 10:30 | Product/Solution Vision9:00 - 11:00 | Team Breakouts10:30 - 11:30 | Architecture Vision and Development Practices11:00 - 13:00 | Final Plan Review and Lunch11:30 - 13:00 | Planning Context and Lunch13:00 - 14:00 | ART Risks13:00 - 16:00 | Team Breakouts14:00 - 14:15 | Confidence Vote16:00 - 17:00 | Draft Plan Review14:15 - ??  |Plan Rework?17:00 - 18:00 | Management Review and Problem Solving?? | Planning Retrospective and Moving Forward

Source: scaledagileframework.com/pi-planning

This agenda might be perfect for you, or you might make changes based on the needs of your teams.

Distributed teams, very large ARTs, and other factors might require you to be creative with the schedule. Some sessions may need more time, while others can be shortened. If you have teams in multiple time zones, your PI Planning agenda may need to go over 3-4 days. If it’s your first PI Planning event, try the standard agenda, get feedback from your teams, and experiment with different formats next time.

What happens in the first part of the PI Planning meeting?

The first part of the PI Planning meeting is designed to set the context for the planning that happen next.

Day 1 usually kicks off with a presentation from a Senior Executive or Business Owner. The agenda allows an hour to talk about the current state of the business. They highlight specific customer needs, how the current products address these needs, and potential gaps.

After that, the Product Management team will share the current vision for your product or solution. They’ll talk about any changes that have occurred since the last PI Planning session (usually around 3 months prior). They’ll describe what’s coming up, including milestones and the next 10 features that are planned. This session should take around 1.5 hours.

Why is a confidence vote held at the end of PI Planning?

The confidence vote is a seemingly small but very important part of PI Planning towards the end of the event.

It is important the team is confident in committing to the objectives and work that is planned. The Release Train Engineer will ask teams to vote on this.

Everyone participating in planning needs to vote. This could be via a raise of hands (and fingers) or it could be via the tool you’re using. For example, the Team Planning board in Easy Agile Programs allows each team member to enter their confidence vote.

If the average vote across the room is at least three out of five, the plan is a go-ahead. If it’s less it’ll need reworking (until it reaches a high confidence level). If anyone votes just one or two, they’ll have the chance to share their reasoning.

The confidence vote is all about making sure that the attendees are in alignment and that they agree that the plan in its current form is possible within the given timeframe. Speaking of timing, let’s talk about how and where PI Planning actually fits into your company calendar.

When is PI Planning held?

Many companies find that 8-12 weeks (which adds up to 4-6 x 2-week iterations) is the right amount of time for an increment.

Some companies hold quarterly PI Planning, for example:

• Q1 PI Planning: December
• Q2 PI Planning: March
• Q3 PI Planning: June
• Q4 PI Planning: September

However, the timing and frequency will depend on how long each program increment is scheduled to last and may need to accommodate holidays.

The good thing about PI Planning events is that they happen regularly on a fixed schedule, which means you can plan for them well ahead of time. That means teams and Business Owners have plenty of notice to ensure they can show up for the event.

This means that what happens in preparation for PI Planning can be just as important as the event itself.

What is a pre-PI Planning event and when is it needed?

A pre-planning event - separate to PI Planning - is to make sure that the ART is aligned within the broader Solution Train before they do PI Planning. It’s all about synchronizing with the other ARTs to ensure the solution and organization are heading in the right direction, together.

You’ll need to organize a pre-PI Planning event if you’re operating at the Large Solution, Portfolio, or Full SAFe levels. Essential SAFe is more basic and does not have a Solution Train, so if you’re operating at this level, you won’t need pre-PI Planning so formally.

Here are a few of the roles that should be invited to the pre-planning event:

• Solution Train Engineer
• Solution Management
• Solution Architect/Engineering
• Solution System Team
• Release Train Engineers
• Product Management
• System Architects/Engineers
• Customers

They’ll look at the top capabilities from the Solution Backlog, Solution Intent, Vision, and Solution Roadmap. It’s really a lot like PI Planning but at a higher level, across the overall solution and not just the individual ART.

The event starts with each ART summing up their previous program increment and accomplishments to set the context. Next, a senior executive will brief the attendees on the current situation before Solution Management discusses the current solution vision and any changes from what was shared previously. Other things that are often discussed or finalized include:

• Roadmaps
• Milestones
• Solution backlogs
• Upcoming PI features from the Program Backlog

In the next section, we'll help to define a few key terms that have been touched on.

PI Planning in SAFe

If you’re adopting SAFe for the first time, chances are it will start with PI Planning. That’s because it forms the foundation of the Scaled Agile Framework.

As Scaled Agile says, "if you are not doing it, you are not doing SAFe."

Definition:

SAFe or the Scaled Agile Framework™ is a series of guidelines and practices designed to help bring agility into larger organizations, across all teams and levels of the business. The framework is geared at improving visibility, alignment, and collaboration and should lead to greater productivity, better results, and faster delivery.

Whether you’re adopting all 5 levels or just essential SAFe, the foundation of your transformation and the driver for everything is the PI Planning ceremony.

Scrum and Kanban are also agile frameworks (that you may be more familiar with), and these have historically been very effective at the individual team level. SAFe helps to scale agility across teams; to have multiple teams come together to work on the same products, objectives, and outcomes. It goes beyond the team level to include every stakeholder, outlining what should happen at each level of the organization to ensure that scaled planning is successful.

The purpose of SAFe is to improve the visibility of work and alignment across teams, which will lead to more predictable business results.

This is increasingly important for organizations as they respond to changing circumstances and customer expectations. The traditional waterfall approaches fall short because they’re slow and inefficient.

Bigger companies (often with thousands of developers) can’t keep up with the innovation of smaller, more nimble startups. Along with bigger teams, larger organizations often have stricter requirements around governance and compliance, making it more complex to launch a new feature and deliver new value to customers.

These companies are looking for new ways to organize people into projects and introduce more effective ways of working that use resources more effectively and provide more predictable delivery. If they don’t, they may not survive.

SAFe is a way for these companies to start moving in a more agile direction.

PI Planning is a vital element of SAFe. It’s a ceremony that brings together representatives from every team to help them work together, decide on top features to work on next, identify dependencies, and make a plan for the next Program Increment. As a result, there’s greater visibility across all the teams, changes are made more frequently, and teams work with each other - not against each other. From there, these massive companies can speed up their processes, work more efficiently, compete with newer and more nimble companies, and stay viable.

SAFe and PI Planning are powerful enablers for organizational agility.

While SAFe is a framework designed for larger organizations, there isn't a reason stopping smaller companies from doing a version of PI Planning, too. All you need is more than one agile team to make it worthwhile.

PI Planning in Scrum

You can also use PI Planning as part of a simple Scrum approach.

Scrum Framework diagram shows when and how scrum teams can implement PI Planning

Source: Scrum.org

Scrum is an agile framework that helps teams get things done. It’s a way for teams to plan and organize their own work and tackle user stories and tasks in smaller time boxes. This is often referred to as a sprint.

If multiple scrum teams want to work better together (but aren’t necessarily operating within SAFe), they could adopt a version of PI Planning.

For example, these scrum teams could:

• Meet every 10 weeks and discuss the features they are planning to work on
• Get product managers to combine backlogs and prioritize together
• Share resources across the teams, as needed
• Map dependencies and coordinate joint releases

The good news here is that there’s no “one size fits all” approach to PI Planning, so think about how you could adopt the ideas and principles and make it work for your organization and context.

What is the difference between a PI Roadmap and a Solution Roadmap?

There are different types of roadmaps in SAFe, so it’s important to understand the differences and what each roadmap is meant to do.

PI Roadmap

A PI Roadmap is created before your PI Planning event and also reviewed and updated by Product Management after the event is finished. It will usually cover three Program Increments:

1. The current increment (work that’s committed)
2. The next forecasted increment (planned work based on forecasted objectives)
3. The increment after that (further planned work based on forecasted objectives)

Quarterly PI Planning will outline around 9 months of work. The second and third increments on your PI Roadmap will likely change as priorities shift, but they’re still an important part of the roadmap as they forecast where the product is headed next.

Solution Roadmap

The Solution Roadmap is a longer-term forecasting and planning tool for a specific product or service.

It will usually cover a few years at a time, with more specific details available for year one (like quarterly features and capabilities), and more general information (like objectives) for year two and beyond.

What is a program?

A program is where agile teams are grouped together to form a larger group. This is often referred to as the “team-of-teams” level. In simple terms, a program is a group of agile teams.

When you hear people talking about “team-of-teams” or “scaled agile”, they mean taking agile beyond a single team, and asking more teams to join in.

For example, there might be 4 teams working on a NASA spaceship mission to Mars.

NASA decides they want to see if agile can help these teams do better work. So, to start with, the Oxygen team switches from working with traditional Waterfall project management methods to embracing agile principles.

1. Launch team
2. Food team
3. Oxygen team (Agile)
4. Landing team

After a few months, NASA decides that the way the oxygen team is working is going well, so the remaining three teams similarly adopt more agile methodologies:

1. Launch team (Agile)
2. Food team (Agile)
3. Oxygen team (Agile)
4. Landing team (Agile)

Each of these 4 teams are self-organizing, meaning they’re responsible for their own work.

However, now that these teams are all working in the same way, they can be grouped together as a program.

Once you add in the business owners, product management team, systems architect/engineer, and release train engineer, you have all the roles needed to continuously deliver systems or solutions through the Agile Release Train (ART).

What is a program board?

Program Boards are a key output of PI Planning.

Traditionally, they’re a physical board that’s mounted on the wall, with columns drawn up to mark the iterations for the increment, and a row for each team. Teams add sticky notes that describe features they’ll be working on.

• Feature 1
• Feature 2
• Feature 3

Once all the features are added, they work to identify dependencies (features that’ll affect other features) and mark this up by connecting them with red string.

SAFe program boards don’t have to be physical, though. There are a lot of advantages to using a digital program board like Easy Agile Programs, which integrates directly with Jira. We’ll talk more about how you can use Jira for PI Planning towards the end of this guide.

Equip your remote, distributed or co-located teams for success with a digital tool for PI Planning.

Easy Agile Programs

Free Trial

Who is involved in PI Planning?

There are 5 key roles in a PI Planning event:

1. Release Train Engineers
2. Product Managers
3. Product Owners
4. Scrum Masters
5. Developers

Here are the responsibilities for each of these roles during PI Planning:

Release Train Engineer

The Release Train Engineer is a servant leader and coach for the ART. Their role focuses mainly on planning and facilitating the PI Planning event. This means they help:

• Establish and communicate the annual calendars
• Get everything ready (including pre and post-PI Planning meetings)
• Manage risks and dependencies
• Create Program PI Objectives from Team PI Objectives and publish them
• Track progress towards expected goals
• Ensure strategy and execution alignment
• Facilitate System Demos

As the facilitator for the 2-day event, the Release Train Engineer presents the planning process and expected outcomes for the event, plus facilitates the Management Review and Problem Solving session and retrospective.

Product Manager

A Product Manager’s job is to understand the customers’ needs and validate solutions, while understanding and supporting portfolio work.

Before PI Planning happens, Product Managers take part in the pre-PI Planning meeting, where they discuss and define inputs, objectives, and milestones for their next PI Planning events.

In PI Planning, the Product Managers present the Program vision and upcoming milestones. So that they can manage and prioritize the flow of work, they review the Draft plan and describe any changes to the planning and scope based on the Management Review & Problem Solving session. Once the PI Planning event is over, they use the Program Objectives from the Release Train Engineer to update the roadmap.

Following PI Planning, Product Managers play a critical role in communicating findings and creating Solution PI Objectives.

Product Owner

The Product Owners are responsible for maintaining and prioritizing the Team Backlog, as well as Iteration Planning. They have content authority to make decisions at the User Story level during PI Planning Team Breakout sessions.

Product Owners help the Team with defining stories, estimating, and sequencing, as well as drafting the Team’s PI Objectives and participating in the Team Confidence Vote. They’re also responsible for conveying visions and goals from upper management to the team, as well as:

• Reporting on key performance metrics
• Evaluating progress, and
• Communicating the status to stakeholders

Scrum Master

The Scrum Master is a servant leader to the Product Owner and Development team, which means they manage and lead processes while helping the team in practical ways to get things done.

They facilitate preparation for events (including PI Planning) and prepare System Demos. They help the team estimate their capacity for Iterations, finalize Team PI Objectives, and manage the timebox, dependencies, and ambiguities during Team Breakout sessions. The Scrum Master also participates in the Confidence Vote to help the team reach a consensus.

Developer

Developers are responsible for researching, designing, implementing, testing, maintaining, and managing software systems.

During PI Planning, they participate in Breakout sessions to create and refine user stories and acceptance criteria (alongside their Product Owner) and adjust the working plan. Developers help to identify risks and dependencies and to support the team in drafting and finalizing Team PI Objectives, before participating in the Team Confidence Vote.

Do you have a key role in PI Planning? See how the right tool can help you manage your release train or program better.

Watch an Easy Agile Programs product demo

How to prepare for PI Planning

If you want to succeed at PI Planning, you need to prepare.

Every PI Planning event relies on good preparation so that your organization and attendees get the most out of the event and achieve your planning objectives.

The first step is to ensure that everyone involved properly understands the planning process. All people participating in PI Planning (along with key stakeholders and Business Owners) must be clear on their role and aligned on strategy.

Any presenters will also need to get content ready for their presentations.

To ensure that the PI Planning event runs smoothly, make sure that the tools you need to facilitate planning are available and working properly. Be sure to test any tech that you are relying on ahead of time (including audio, video, internet connectivity, and access to PI Planning applications), to ensure that your distributed teams can participate in the PI Planning event. Don’t forget to plan for enough food for everyone, too (planning is hungry work).

What happens after PI Planning?

After PI Planning, teams do a planning retrospective to discuss:

• What went well
• What went not-so-well
• What could be better for next time
• There will also be a discussion of what happens next, which can include things like:
• Transcribing the objectives, user stories, and program board into your work management tool (like Jira)
• Agreeing on meeting times and locations for daily stand-ups and iteration planning
• Making sure that everyone has their belongings and leaves the event rooms clean when they go

The other thing that usually happens after PI Planning events is a post-PI Planning event.

What is a post-PI Planning event?

These are similar to the pre-PI Planning events we looked at earlier. A post-PI Planning event brings together stakeholders from all ARTs within the Solution Train to ensure they’re synchronized and aligned.

Post-PI Planning happens after all the ARTs have completed their PI Planning for the next increment. They present the plans, explain their objectives, and share milestones and expected timelines.

Like PI Planning events, post-PI Planning involves using a planning board, but rather than features, it outlines capabilities, dependencies, and milestones for each iteration and ART. Potential issues and risks are identified, discussed, and either owned, resolved, accepted, or mitigated. And similar to regular PI Planning events, plans go through a confidence vote to ensure they meet the solution’s objectives, and are reworked until the attendees average a vote of 3 or more.

Remote or hybrid PI Planning

PI Planning in person was once standard, but with teams more likely to be distributed, gathering everyone at the office isn't always feasible. This doesn't have to be a barrier.

The most important principle is to ensure that the teams who are doing the work are able to be 'present' in the planning in real-time, if not in person.

This may require some adjustments to the agenda and timing of your planning, but with forethought and support from the right technology, your PI Planning will still be effective.

Tips for remote PI Planning

Remote PI Planning is ideal for organizations with distributed teams or flexible work arrangements. It’s also a lot cheaper and less disruptive than flying folks in to do PI Planning every few months. If you have the right tools and technology, you can run PI Planning and allow everyone to participate, whether they’re in the same room or on the other side of the world.

Here are a few tips for remote PI Planning:

Embrace the cloud

Use online shared planning tools to allow your team to access and interact with information as soon as possible - ideally in real-time. Ensuring that all participants have instant access to the information simplifies the process of identifying dependencies and maintaining a centralized point of reference for your planning. This helps prevent errors that arise from working with different versions and transferring data between sources.

Livestream the event

Live-streaming audio and video from the PI Planning event is a viable alternative to in-person planning. Actively encourage your remote team members to use their cameras and microphones during the event. While it may not fully replicate the experience of having them physically present, it does come remarkably close.

Record the PI Planning event

Ideally, everyone will participate in the PI Planning live. But if your teams are distributed across multiple time zones or some team members are ill, it’s a good idea to record the event. Having a recording to refer back to could also be useful for attendees who want a refresher on anything that has been discussed.

Be ready to adapt

Some teams will change the standard PI Planning agenda to fit multiple time zones, which could mean starting the event earlier or later for some, or even running it across 3 days instead of 2.

Set expectations

A common issue that can arise from having distributed teams tune in remotely is too much noise and interference. Before your first session kicks off, communicate about when it’s acceptable to talk and when teams need to use the mute button. That way, your teams will avoid getting distracted, while still ensuring everyone can participate.

For more tips, check out our blog on how to prepare for distributed PI Planning.

Whether distributed or in person, if your team gets PI Planning right, it makes everything in the upcoming increment so much easier.

📣 Hear how PNI media have embraced virtual PI planning

Common PI Planning mistakes

PI Planning doesn’t always run smoothly, especially the first time. And the framework itself may present a challenge to some organizations. Here are some common mistakes and challenges to keep in mind (and avoid):

Long, boring sessions

Avoid starting your PI Planning event with long sessions filled with dense content. Think of creative ways to make these sessions more engaging, or break them into shorter sessions. Consider different formats that help to involve and engage participants. And be sure to make room for team planning and collaboration.

Tech issues

Any event is vulnerable to technical mishaps, but if you’re streaming audio and video to a distributed team, this can really impact the flow of the event. It’s a good idea to carefully test all the equipment and connections ahead of time to minimize potential problems.

Confidence vote

Some PI Planning participants struggle with the confidence vote concept. People may feel pressure from the room to vote for a plan to go ahead, rather than speaking up about their concerns. Failing to address issues early only increases the risk of something going wrong during the increment.

Time constraints

When you have a large ART of 10 or more teams, there are a lot of draft plans to present and review, so less time is allocated to each team. Chances are that the feedback will be of poorer quality than a smaller ART with 8 teams.

Not committing to the process

PI Planning isn’t perfect and neither is SAFe. However, the process has been proven to work for many organizations, when the organization is committed. Start with the full framework as recommended; you can adapt the framework and your PI Planning event to suit your organization, but be sure to commit to the process that follows. Anything that is half-done will not deliver full results.

Sticking with the same old tools

If something is not working, fix it. For example, too many teams stick with traditional SAFe Program Boards even though they’re not always practical. If the post-it notes keep escaping, the data entered into Jira seems incorrect, or you have a distributed team who want a digital way to be part of your PI Planning event… it’s time to upgrade to a digital program board like Easy Agile Programs.

Using Jira for PI Planning

Jira is the most popular project management tool for agile teams, so chances are you're already using it at the team level.

When you need to scale team agility as part of an ART, it can be difficult to properly visualize the work of multiple teams in Jira. The only way you can do that in the native app is by creating a multi-project board, which is rather clunky.

Traditional PI Planning on a physical board using sticky notes and string may achieve planning objectives for co-located teams, but what happens next? After the session is over, the notes and string need to be recreated in Jira for the whole team so that work can be tracked throughout the increment. This is a cumbersome and time-consuming process that is open to error as sticky notes are transcribed incorrectly, or go missing.

The best way to use Jira for PI Planning is to use an app like Easy Agile Programs to help you run your PI Planning sessions. The integrated features mean you can:

• Set up a digital Program Board (no more string and sticky notes!)
• Do cross-team planning
• Visualize and manage cross-team dependencies, create milestones
• Identify scheduling conflicts to mitigate risks
• Get aligned on committed objectives for the Program Increment
• Visualize an Increment Feature Roadmap
• Conduct confidence voting
• Transform Jira from a team-level tool to something that’s useful for the whole ART

Join companies like Bell, Cisco, and Deutsche Bahn who use Jira to do PI Planning with Easy Agile Programs (from the Atlassian Marketplace).

Looking for a PI Planning tool for Jira?

We’ll continue to revisit this guide in the future. If you have any questions about PI Planning or you notice there’s an aspect we haven’t covered yet, send us an email 📫

Backlog prioritization is a never-ending task for product owners and product managers. As priorities evolve in response to changing business needs, or even as work is completed, or adjustments to team resourcing are made, it's important to maintain focus on the work that will deliver the most value by keeping your backlog in good shape. Agile estimation techniques can make prioritizing your backlog faster and easier.

So, let's take a look at some specific methods to prioritize your backlog and see how agile estimation can help deliver the most value to your end-users and stakeholders.

5 ways to prioritize a backlog

Of course, there are more than five ways to prioritize work items in a backlog. But, we've picked a few of our favorites that, when combined with an agile estimation process, help keep our product backlog prioritized so we can breeze through sprint planning.

1. Weighted Shortest Job First

Wow, is that a mouthful! Let's use the "WSJF" acronym to refer to this SAFe technique. Not as intimidating as it sounds, WSJF is a simple formula that assigns a business value to product backlog items.

WSJF = Cost of Delay ÷ Job Duration

Cost of Delay is the sum of three relative metrics:

• User/Business Value: the relative importance of the work item.
• Time Criticality: the decline of user/business value over time.
• Risk Reduction: the reduction of business or technical risk.

To determine the relative size for Cost of Delay, think of the lowest business value, the smallest decline in value over time, and the least risk reduction as a 1 value. The same as with Fibonacci sequence story point estimation, adjust that score appropriately when comparing work items to score them relative to one another.

The Job Duration is also expressed in relative terms. If you estimate your work items using relative estimation with story points, the story point value equals the Job Duration.

If you're using this technique to prioritize a large amount of work in a backlog where some items have only been t-shirt sized, convert your t-shirt sizes to standard Fibonacci numbers and use that value.

Warning: Be careful with converting t-shirt sizes to story points. You'll need a way to flag the t-shirt size work items that you converted to story points. You and your Scrum Master need to recognize those as t-shirt level estimations rather than the real story point estimates that come with fully refined work items.

See more at a glance in Easy Agile TeamRhythm, to make prioritizing your backlog faster

💡Tip: Add up to three extra fields on issue cards

SEE HOW

2. MoSCoW

Must-have, should-have, could-have, and won't-have are the buckets used to prioritize a backlog with the MoSCoW technique. The product team defines these designations based on the product's unique features and competitive offerings.

Each work item falls into one of those categories. The easiest part of this process is sending Won't-have items directly to the trash and getting them out of your way. Next, prioritize must-haves first and then should-haves. The could-have items naturally fall to the bottom of the backlog.

Take these items through your regular refinement meetings with your team members, and assign each item a t-shirt size or story point value. You're then ready to add the right amount of work items to your sprints or releases based on your teams' velocity or the number of story points they expect to finish during a sprint.

3. Kano

The Kano model of prioritization uses five classifications:

• Must-be: the basic functionality that your users expect.
• Attractive: a pleasant surprise for your users, but no one is going to be upset if it's not there.
• One-Dimensional: work items that make your users happy and will disappoint them if they aren't part of your product.
• Indifferent: work items that are unimportant to your customers. Often, these work items represent technical debt or enhancements that help the software development team develop more efficiently or work in the latest versions of their tech stack — but your customers really don't care about them.
• Reverse: the process of undoing a previous feature or update. If you've ever built a feature or made a UI update that your users hated, you understand reverse work items. Oops. Unfortunately, sometimes these are necessary evils, especially when it comes to security features or transitioning users to a new product after retiring a legacy product.

Like the MoSCoW method, you'll estimate these work items during refinement and then add them to your iteration or release plan. But, different from MoSCoW, you may want to balance out your sprints and releases with work items from each classification.

4. Stack Ranking

The most brutal of all prioritization techniques, stack ranking forces teams to have a linear rank of work items, which means there is only one top priority, one second priority, one third priority, and so on. Brutal!

Once you get used to it, stack ranking is a useful way to force product managers to make tough choices between work items. Even if two work items can be completed during the same sprint, it's up to the PO to determine which one gets done first, and then that choice is reflected in the sprint backlog.

Often, this job becomes easier when it's put in dire terms. For instance, if you only had one day to attract new users to your product, what work would you want in production? BOOM! There's your top priority.

The nice thing with stack ranking is that it allows POs to slide smaller work items into current sprints when other higher-priority work is too large. Adding the larger work item over-commits the team based on their velocity. Those small work items serve to fill up sprints so teams can maintain velocity and be as productive as possible. So, just because a two-story point work item is two-thirds the way down the backlog doesn't mean it will never get done.

5. Story Mapping

Story mapping helps you visualize the customer's journey through your product from start to finish. (Yep, we stole that straight from our other excellent article on story mapping.) For advanced story mappers, take what you’ve learned about story mapping, and think about how you can add MoSCoW or Kano techniques to your story maps.

Perhaps your epic backbone at the top of the user story map could represent the buckets in the MoSCoW method?

If you're like us, your story mapping sessions are productive brainstorming activities, and you'll leave the sessions with way more work than you can accomplish. By applying MoSCoW or Kano principles to the stories in your user journeys, you’ll discover the most important stories to prioritize and the stories that can wait for a later release.

Building agile estimation into backlog prioritization

We've given you five different techniques to corral your work items into an organized, prioritized, value-delivering product backlog:

1. Weighted Shortest Job First
2. MoSCoW
3. KANO
4. Stack Ranking
5. Story Maps

We've also shown you ways to incorporate agile estimates like t-shirt sizes and story points into your prioritization process to keep your team delivering the most important work while maintaining velocity and dazzling your customers and stakeholders.

We encourage you to take these ideas, share them with your team, and give them a try. If you need help using the Story Map concept, try Easy Agile TeamRhythm. However your team prioritizes its product backlog, remember to put the most important work first and then adjust those priorities as needed. Keep it easy and keep it agile!

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

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

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

How Easy Agile uses TeamRhythm retrospectives to maximise team time

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

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

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

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

3. Facilitators categorize items before the meeting

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

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

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

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

Wrapping it up

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

Just one more thing…

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

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

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

Retrospectives help create an environment where team members can freely share their wins and challenges. By encouraging this feedback, you get critical insights into what can be improved in the next iteration. But while it sounds straightforward in theory, many teams struggle to make agile retrospectives work in practice.

So if we know team retrospectives can be a great way to drive continuous improvement and deliver value – why do so many teams struggle to get it right?

The slippery slope to becoming a tick box exercise

According to Easy Agile Product Marketing Manager Tenille Hoppo, the struggle with retrospectives often lies behind two key challenges. "If you’re having the same discussions week after week, and the team can’t see anything changing, then people can become fatigued, disengaged, and bored," said Tenille. "Over time, retrospectives become less respected and less effective as a process, and eventually become nothing more than a tick box exercise".

"Then there’s the challenge around capturing actions in real-time," said Tenille. "We’ve all been guilty of having great ideas while working on something, but by the time the next retrospective comes around, the idea is gone".

The challenges around keeping retrospectives fresh, productive, and integrated with the work in Jira are behind the development of Easy Agile TeamRhythm, an app designed to overcome these common issues and help teams deliver value to their customers more quickly.

Integrating user story maps and retrospectives

"We believed if we could integrate the retrospective process right alongside the work in Jira, teams would be better able to deal with the issues blocking their progress and work more effectively," said Tenille. "So, we mapped out the groundwork as part of an Inception Week project, and soon after that, Easy Agile TeamRhythm was born".

Easy Agile TeamRhythm replaces our first app, Easy Agile User Story Maps, and integrates team user story maps with team retrospective boards. The user story maps are used for planning and managing work (including sprint planning and backlog refinement), while retrospective boards help teams do that work better. "It made sense to build on the sprint planning and backlog refinement capabilities of Easy Agile User Story Maps and introduce retrospective boards to capture and collate ideas for improvement," said Tenille. "With retrospectives colocated where work is managed in Jira, you can turn action items into Jira issues and schedule work, ensuring retrospectives are effective and valuable".

Elevating retrospectives with Easy Agile TeamRhythm

Easy Agile TeamRhythm supports teams from planning through to release and retrospectives. It covers user story mapping, sprint planning, version planning, backlog refinement, and team retrospectives.

By featuring a team retrospective board integrated alongside your Jira boards, agile teams can use the app to:

Capture feedback in real-time

Team members can capture feedback quickly and easily as they do their work. As a result, feedback and ideas don’t get lost and, instead, are there waiting for you when you run the next retrospective.

Combat fatigue with templates

You can access different templates to help change the format of retrospectives, frame things differently, and keep team members interested. This can also help teams see things from different angles and come up with new ideas.

Current templates include:

• Foundation
  A highly customizable template based on the Start, Stop, & Continue model. The team looks at looks at the actions they want to introduce, those that aren't working, and what can continue into the next cycle.
• Get Rhythm
  A music-themed template using the 4 L’s retrospective format, to understand what is “Loved, Learned, Loathed, and Longed for”. The team calls out what they appreciate, what the sprint taught them, what went wrong, and what they would’ve wanted more of.
• Space Mission
  A stellar-themed template based on the Sailboat retrospective format, examining the approaches that inhibit progress, or reap desirable outcomes, and establish a direction for planning the next iteration.
• Rose Blossom
  A rose-themed template based on the Starfish model, that involves rating the efficacy of action items to determine the methodologies they should keep, discard, and apply in the next round.

Improve the next iteration by applying insights

The ‘Actions’ column is where you turn feedback into tangible actions and create in-built accountability. In just two clicks, you can turn an action item into a Jira issue that is automatically added to your backlog. You can then assign an owner and schedule it into an upcoming sprint or release.

“We’ve improved our communication and team alignment, which has helped give us faster results”.

Casey Flynn, Adidas

Make your next release better

"Agile isn’t about wringing every ounce of work you can get from your team, and it’s also not about wasting time in unproductive meetings that don’t drive an outcome," said Tenille. "With Easy Agile TeamRhythm, we provide the framework and functionality to help share learnings, plan solutions, and take action. And as teams focus on incremental improvements, they can start working better together, feel happier in their role, and deliver better outcomes".

TRY EASY AGILE TEAMRHYTHM FREE FOR 30 DAYS

Like to hear more?

Tenille presented on this topic in a webinar with Atlassian Solution Partner Almarise. Watch the full presentation below.

‍

The seventh principle of the Manifesto for Agile Software Development is:

Working software is the primary measure of progress.

Not story points, not velocity, not estimates: working software.

Jason Godesky
Better Programming

Estimation is a common challenge for agile software development teams. The anticipated size and complexity of a task is anything but objective; what is simple for one person may not be for another. Story points have become the go-to measure to estimate the effort involved in completing a task, and are often used to gauge performance. But is there real value in that, and what are the risks of relying too heavily on velocity as a guide?

Agile estimation

As humans, we are generally terrible at accurately measuring big things in units like time, distance, or in this case, complexity. However, we are great at making relative comparisons - we can tell if something is bigger, smaller, or the same size as something else. This is where story points come in. Story points are a way to estimate relative effort for a task. They are not objective and can fluctuate depending on the team's experience and shared reference points. However, the longer a team works together, the more effective they become at relative sizing.

The teams that I coach have all experienced challenges with user story estimation. The historical data tells us that once a story exceeds 5 story-points, the variability in delivery expands. Typically, the more the estimate exceeds 5 points, the more the delivery varies from the estimate.

Robin D Bailey, Agile Coach, GoSourcing

Scale of reference

While story points are useful as an abstraction for planning and estimating, they should not be over-analyzed. In a newly formed team, story points are likely to fluctuate significantly, but there can be more confidence in the reliability of estimations in a long-running team who have completed many releases together. Two different teams, however, will have different scales of reference.

At a company level, the main value I used to seek with story points was to understand any systemic problems. For example, back when Atlassian released to Server quarterly, the sprints before a release would blow out and fail to meet the usual level of story point completion. The root cause turned out to be a massive spike in critical bugs uncovered by quality blitz testing. By performing better testing earlier and more regularly we spread the load and also helped to de-risk the releases. It sounds simple looking back but it was new knowledge for our teams at the time that needed to be uncovered.

Mat Lawrence, COO, Easy Agile

Even with well-established teams, velocity can be affected by factors like heightened complexity with dependencies scheduled together, or even just the average number of story points per ticket. If a team has scheduled a lot of low-complexity tickets, their process might not handle the throughput required. Alternatively having fewer high-complexity tickets could drastically increase the effort required by other team members to review the work. Either situation could affect velocity, but both represent bottlenecks.

Any measured change in velocity could be due to a number of other factors, like capacity shifting through changes in headcount with team members being absent due to illness or planned leave. The reality is that the environment is rarely sterile and controlled.

Relative velocity

Many organizations may feel tempted to report on story points, and velocity reports are readily available in Jira. Still, they should be viewed with caution if they’re being used in a ‘team of teams’ context such as across an Agile Release Train. The different scales of reference across teams can make story points meaningless; what one team considers to be a 8-point task may be a 3-point task for another.

To many managers, the existence of an estimate implies the existence of an “actual”, and means that you should compare estimates to actuals, and make sure that estimates and actuals match up. When they don’t, that means people should learn to estimate better.
…
So if the existence of an estimate causes management to take their eye off the ball of value and instead focus on improving estimates, it takes attention from the central purpose, which is to deliver real value quickly.

Ron Jefferies
Co-Author of the Manifesto for Agile Software Development
Story Points Revisited

Seeking value

However, story points are still a valuable tool when used appropriately. Reporting story points to the team using them and providing insights into their unique trends could help them gain more self-awareness and avoid common pitfalls. Teams who are seeking to improve how they’re working may wish to monitor their velocity over time as they implement new strategies.

Certainly, teams working together over an extended period will come to a shared understanding of what a 3 story point task feels like to them. And there is value in the discussion and exploration that is needed to get to that point of shared understanding. The case for 8 story points as opposed to 3 may reveal a complexity that had not been considered, or it may reveal a new perspective that helps the work be broken down more effectively. It could also question whether the work is worth pursuing at all, and highlight that a new approach is needed.

The value of story points for me (as a Developer and a Founder) is the conversations where the issue is discussed by people with diverse perspectives. Velocity is only relatively accurate in long-run teams with high retention.

Dave Elkan, Co-CEO, Easy Agile

At a company level, story points can be used to understand systemic problems by monitoring trends over time. While this reporting might not provide an objective measure, it can provide insights into progress across an Agile Release Train. However, using story point completion as a measure of individual or team performance should be viewed with considerable caution.

Story points are a useful estimation tool for comparing relative effort, but they depend on shared points of reference, and different teams will have different scales. Even established teams may notice velocity changes over time. For this reason, and while velocity reporting can provide insights into the team's progress, it must be remembered that story points were designed for an estimation of effort, rather than a measure. And at the end of the day, we’re in the business of producing great software, not great estimates.

Looking to focus your team on improvement? Easy Agile TeamRhythm helps you turn insights into action with team retrospectives linked to your agile board in Jira, to improve your ways of working and make your next release better than the last. Turn an action item into a Jira issue in just a few clicks, then schedule the work on the user story map to ensure your ideas aren’t lost at the end of the retrospective.

Many thanks to Satvik Sharma, John Folder, Mat Lawrence, Dave Elkan, Henri Seymour, and Robin D Bailey for contributing their expertise and experience to this article.

We are thrilled to announce that Easy Agile has successfully achieved SOC 2 Type II compliance, a significant milestone in our unwavering commitment to maintaining high standards of security and privacy.

What is SOC 2 Type II Compliance?

System and Organization Controls (SOC) 2 is a widely recognized security standard developed by the AICPA that specifies how organizations should manage customer data. A SOC 2 report is often the primary document that security departments rely on to assess a service provider's ability to maintain adequate security.

Service providers like Easy Agile voluntarily undergo a rigorous audit and assessment to ensure their security controls meet AICPA’s Trust Services Criteria, including:

• Security
• Availability
• Processing integrity
• Confidentiality

SOC 2 compliance comes in two forms: A SOC 2 Type I report describes the design of a service provider’s system controls to meet relevant trust criteria as of a specific point in time, while a SOC 2 Type II report details the operational effectiveness of those systems controls to perform as designed over a specified period. An independent auditor, Johanson Group, has reviewed and certified that our processes, procedures, and controls are properly designed to meet the SOC 2 standards.

What does this mean for you?

Our achievement of SOC 2 Type II compliance means that when you use Easy Agile's services, you can continue to do so with the confidence that we have robust controls in place to secure your data. We believe that security is a shared responsibility, and this milestone is part of our ongoing effort to provide transparent and secure practices that support your business.

We want to thank you for your trust and support in Easy Agile. Your data security and privacy are our top priorities, and we are committed to delivering services that not only meet but exceed industry standards.

When is ISO 27001 coming?

Now that we've completed our SOC 2 Type II compliance we'll be setting our sights on ISO 27001 compliance in the next 12 to 18 months.

Where can I learn more?

Visit our Trust Report to access security reports and monitoring.

For any questions or more information about our SOC 2 Type II compliance and what it means for you, please feel free to reach out to our team at security@easyagile.com.