No items found.

Our Blog

Stories by Easy Agile

The latest industry news, interviews, technologies, and resources.

The Ultimate Guide to PI Planning

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:

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

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 📫

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
  • Agile Best Practice

    Unlocking the Potential of Teams with People-Centered Retrospectives

    When I first began working as a Scrum Master, I quickly became focused on the world of metrics. I believed that for my teams to succeed, they needed to have a continuously improving velocity, a stable cumulative flow diagram, or a perfect burn-down chart.

    Sound familiar?

    The problem with these metrics is that they are efficiency, not value focused.

    It doesn't matter if a team builds one hundred new features rapidly if none of those actually deliver value to the customer. Efficiency metrics also have a habit of being misused and misunderstood, and this can breed malcontent.

    Rather than focusing heavily on the data in retrospectives, I aim to focus on the people. The Agile Manifesto after all is about enabling people and their interactions.

    Each of us are beating hearts behind our devices

    Making time for human interaction...has resulted in far better outcomes than any beautifully constructed burndown chart.

    Through embracing a human-first approach, a team I once worked with learned that they as a group were avid gamers. They'd been working together for years but hadn't known. This team was under a lot of pressure to deliver to difficult timescales and retros had fallen by the wayside.

    This was the first thing I focused on; getting them believing in retrospectives again. Taking a human-centred approach, I melted the ice with some unfettered time to talk about non-work stuff “What was your favourite childhood video game”.

    Just a few minutes of idle chatter about Sonic, Legend of Zelda, and Mario kicked off a chain of events that started with a few of them arranging to game together that evening, and before long, we had weekly video game-themed zoom backgrounds and retrospectives always had a gaming twist. Think Dungeons & Dragons, Tetris, Pokémon & Among Us.

    Another great sign that a team is on the right track is how much they laugh together. This team was noticeably happier as a consequence, the change was drastic, almost tangible.

    We aren't just avatars on our screens, each of us are beating hearts behind our devices, with passions, likes, dislikes, and aspirations. Making time for human interaction and building retrospectives that focus on our human side, has resulted in far better outcomes than any beautifully constructed burndown chart.

    Why embrace a People-Centred approach?

    Let’s delve a little into why you should focus on the human side. What’s in it for you?

    • Increased Team Engagement and Participation: When retros are people-centered, team members will feel more connected to their colleagues, they’ll feel more comfortable actively participating, and have an increased sense of ownership of the team's successes and challenges.
    • Improved psychological safety: With a people-centric approach, you can more easily create a safe and inclusive environment for team members to share their thoughts and experiences openly, without fear of judgement. This can foster a sense of belonging and increase the overall morale of the team.
    • More enjoyment: We spend 8 of our waking hours working and half or more of our adult lives working. We owe it to ourselves to have a bit of fun in the process. A people-centric approach can result in people looking forwards to the next retro. More enjoyment, more engagement, and better outcomes. Simple.
    • Better profitability: Oh, and it’s also better for the bottom line. A study by Gallup found a clear link between engagement and profitability in companies. Why are highly engaged teams more profitable? Teams that rank in the top 20% for engagement experience a 41% decrease in absenteeism and a 59% decrease in turnover. Engaged employees come to work with enthusiasm, focus, and energy.

    The perfect conditions for continuous improvement.

    Looking to get started with a few people-focused retrospectives?

    Try a few of these free templates;

    5 Dysfunctions Retro - Chris Stone - Easy Agile
    Autonomy, Mastery, Purpose Retro - Chris Stone - Easy Agile
    Healthy Minds Retro - Chris Stone - Easy Agile
    Psychological Safety Retro - Chris Stone - Easy Agile
    Spotify Team Health at Scale Retro - Chris Stone - Easy Agile

    Psychological Safety Retro

    The Aristotle project led by Google, found that the presence of psychological safety was the biggest factor in high performance for teams. Use this format to build the foundations of psychological safety with your teams, baseline the current levels and develop actions to improve.

    Healthy Minds Retro

    You wouldn’t let your car go without a service, and I bet your phone battery rarely goes below 10%. Why don’t we place the same focus on looking after our own needs, individually or collectively? Use this retro to narrow in on improvements that improve your team's health.

    Spotify Health Check Retro

    Famed for the agile framework that was never intended as a framework, some coaches at Spotify also released a team health check format which is great for measuring and visualising progress as a team. The simplicity of this format and its ability to highlight areas of focus as well as progress over time is particularly powerful. The best bit? It’s the team's perspective, not any external maturity model or arbitrary metric.

    Autonomy, Mastery, Purpose Retro

    Based upon the book ‘Drive’ by Dan Pink which highlighted the surprising things that motivate us, this retro helps teams to investigate the areas of their work which amplify or dampen our sense of autonomy, mastery & purpose. This book was a game changer for me and this retro could change the game for your teams.

    5 Dysfunctions of a Team Retro

    Another format based upon a highly acclaimed book, this retro builds upon the works of Patrick Lencioni and his 5 dysfunctions of a team. Using this retro, you can highlight the dysfunctional behaviours in your team and collectively solve those challenges together. One team, our problems, our solutions.

    Let’s leave you with some things to think about

    The key to unlocking the true potential of your teams lies in embracing a people-centered approach to retrospectives. By focusing on the human side of our teams, we can foster stronger connections, create a safe and inclusive environment, and ultimately drive better outcomes for both the team and the organization.

    Remember, the Agile Manifesto is about enabling people and their interactions, and by placing people at the heart of our retrospectives, we can build stronger, happier, and more productive teams.

    Forget about chasing the perfect metrics, and instead focus on building meaningful connections and fostering a culture of continuous improvement that is rooted in the human experience.

    Retrospectives integrated with your work in Jira

    Hoping to improve how your team is working together? Easy Agile TeamRhythm helps you turn insights into action, to improve how you’re working and make your next release better than the last.

    TRY TEAMRHYTHM FREE FOR 30 DAYS

    About Chris

    For ten years now, Chris Stone has been fostering an environment of success for high-performing teams and organizations through the use of agility. He has worked across a wide range of industries and with some of the largest organizations in the world, as well as with smaller, lean enterprises.

    ​As The Virtual Agile coach, Chris intends to enable frictionless innovation, regardless of location, and is a firm believer in enabling agility whilst working virtually. Find him online at Virtually Agile >>

  • Agile Best Practice

    How to win with SAFe® flow accelerators by delivering value faster

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

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

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


    Why flow begins with having the right mindset


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

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

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


    How improving flow improves customer outcomes


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

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

    What are the eight SAFe® flow accelerators?

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

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

    Easy Agile Podcast

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

    Listen now

    4 steps to winning with  SAFe® flow accelerators

    1. Build a hypothesis

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

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

    2. Choose high-impact accelerators

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

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

    3. Decide when to check progress

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

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

    4. Use flow metrics correctly

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

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

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

    Accelerating flow helps teams focus on delivering value

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

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


    Easy Agile Programs

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

    Try Easy Agile Programs

  • Workflow

    How to set your Agile teams up for success

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

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

    Setting your Agile team up for success

    WATCH NOW

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

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

    Nick Muldoon, Co-CEO at Easy Agile

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

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

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

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

    Empowering your teams

    Culture eats strategy for breakfast

    Peter Drucker

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

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

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

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

    Qualities of high-performing, Agile teams

    1. Create a solid foundation

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

    2. Open to learning and adapting

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

    3. Share feedback and do the retrospective

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

    Using Easy Agile to set your Agile teams up for success

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

  • Workflow

    From surviving to thriving: remote PI Planning with Easy Agile Programs

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

    Agile Manifesto, 2001

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

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

    But what about our agile ceremonies?

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

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

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

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

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

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

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

    Remote PI Planning with Easy Agile Programs

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

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

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

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

    The PI Planning Agenda

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

    2-day PI Planning agenda
    Source: Scaled Agile

    Setting the business context

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

    Image of the edit program modal in Easy Agile Programs, showing the ability to link to anothersite to share business objectives

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

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

    Setting the Product/Solution Vision

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

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

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


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

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

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

    Image of the Program Board with milestones depicted

    Team Breakout Sessions

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

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

    Setting capacity on team planning board

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

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

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

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

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

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

    Creating dependencies on the team planning board

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

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

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

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

    Free trial of Easy Agile Programs

    Try now

    Program Risks

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

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

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

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

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

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

    GIF showing the ability to filter the Program Board

    Plan rework

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

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

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

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

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

    GIF showing the ability to inline edit estimations on issues in the Team Planning Board and the sprint capacity updating as a result

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

    Join a product tour to walk through Easy Agile Programs

    Join a demo

    What about beyond planning?

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

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

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

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

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

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

  • Workflow

    SAFe Program Board 101: Everything You Need To Know

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

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

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

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

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

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

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

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

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

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

    What is a program board?

    What does your teams plan or schedule typically look like?

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

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

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

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

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

    But how does a program board help the planning process?

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

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

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

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

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

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

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

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

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

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

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

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

    1. Setting up the board itself

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

    There are two key elements here:

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

    Here is what this may look like:

    Set up of the Program board with swimlanes for each team and columns for each iteration

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

    Set up of Program board within Easy Agile Programs

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

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

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

    2. Start with features and milestones

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

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

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

    Visualisation of the Program board with sticky notes in the swimlanes to represent milestones and featues

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

    An image of Easy Agile Programs program board with milestones running through the swimlanes and features scheduled as Jira epics

    Milestones are highly visual

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

    Features are native Jira issues

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

    Join a product tour to walk through Easy Agile Programs

    Want to bring your Program Board into Jira?

    Join a demo

    3. Identify dependencies

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

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

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

    To explain this, let’s consider an example.

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

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

    Program board showing dependency lines between features

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

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

    Dependency health is represented as follows:

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

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

    Image of red, green, orange and black dependency lines on the program board in Easy Agile Programs

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

    The Team Planning Board within Easy Agile Programs and it depicting the dependency lines

    Program boards are needed for better collaboration

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

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

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

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

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

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

    You can with Easy Agile Programs

    TRY NOW

  • Company

    Ownership at Easy Agile

    💬 “We know we’ve created something special, an ESOP like no other…”

    Nick and I started Easy Agile after returning home to Australia from living and working in San Francisco where we witnessed the good and not-so-good sides of startups.

    We were lucky to experience first-hand the amazing career opportunities and growth that working for successful companies such as Atlassian and Twitter can provide. On the other hand, we also saw companies start-up, consume vast amounts of funding and flame out. There was a terrible toll taken on our founder friends and their families who put life balance aside in pursuit of success at any cost.

    We took all of this into consideration when we started Easy Agile. We didn't want to default to the standard VC-backed journey so we set our own pace. We wanted to learn what it was to build a customer-funded, sustainable growth product business, even if that meant a more difficult learning curve as we carved our own path.

    Well, that was 6 years ago and here we are happily customer-funded for over 5 of those years, growing at an exciting rate, we believe is healthy and sustainable. We're proud that we're bootstrapped and we're not really looking to change that.

    💬 “We can do things differently”

    One part of the common startup playbook which we did want to retain is employee ownership. We have been dying to introduce an ESOP for a long time, however, being bootstrapped and customer-funded makes creating an Employee Share Option Plan a bit more complicated. Off-the-shelf plans are usually based around the concept of a planned (or hoped for) exit event, as it’s the only time cash-burning companies can realise value for shareholders. This would not work for us and we were looking to provide a more accessible way for our team to realise the value gains as we grow.

    We also knew in our hearts that our ESOP had to be a reflection of Easy Agile's values. We understand the wonderful people that make up Easy Agile are all at different stages of their careers and have different needs financially so we designed our ESOP to take this into consideration.

    Our ESOP also had to be generous. Nick and I really want to continue to pay forward the generosity we’ve been privileged to experience and enable our entire Easy Agile team to have the opportunity to achieve financial freedom. We hope one day many of our Easy Agile team will find themselves as founders of successful companies and continue this tradition with their own ESOPs. 🤞

    Now our ESOP is live, we know we’ve created something special, an ESOP like no other. There’s no standard template for what we’ve built as very few startups or scale-ups in Australia are in our position. We’re growing fast, we’re profitable and we aren’t constrained by investor demands.

    It means we can do things differently.

    How the Easy Agile ESOP is different

    1. Generous valuation from the start

    For our initial grant of options, we valued Easy Agile using a super-low valuation. This gives our initial option grant the highest immediate appreciation of value on paper we can give.

    This type of valuation based on our "Net Tangible Assets" (NTA) is made possible by the Australian Start-up Tax Concessions. Being a software company, our assets are limited to the cash in our bank and some laptops. We have no debt.

    At the same time, we also have a “Fair Market Value “(FMV) calculated similarly to other SaaS companies. It worked out that our NTA valuation for our initial grant was 44 times lower than our FMV valuation meaning by accepting your options, on paper, your options are already worth 44 times more than you will ever pay to exercise them.

    We feel this is pretty special.

    2. Real $ value for our team more often through an Option Buy-Back

    We understand that our team members all have different needs financially. Some have mortgages. Others want to buy a house. Others are happy to rent and invest in other things.

    We’ve ensured our team has the opportunity to realise an exit at a time more suitable to their personal needs.

    Our Option buy-back scheme allows Easy Agile, to offer to buy back vested options from our team at the Fair Market Value. Our team can choose to take advantage of the company’s growth and turn some of their Options into cash far more readily than waiting for an exit event (IPO, secondary, sale, etc). This is a profoundly different concept from most SaaS companies. They can also choose to hold onto their Options for the long-term gains we all work together to achieve.

    3. Dividends

    Most SaaS product companies don't really get to a dividend issuing phase. They simply don’t have the profits available. Once again, we're different here. We have a sustainable growth trajectory enabling Nick and I to issue dividends to shareholders over the course of the life of Easy Agile. We will continue to do this in the future and so Easy Agile shareholders will benefit long-term with dividends and voting rights that come with Ordinary shares.

    4. You can nominate a trust

    We allow you to nominate a trust to hold your share-holding. Nick and I are fans of getting serious about financial planning and literacy (just ask our team!). We wanted to give our team the most flexibility we could, so we allow for our team members to nominate a trust to receive their options instead of themselves personally.

    What’s next?

    We’re thrilled to be at this stage in our journey as it enables Nick and I to better reward the team who have built Easy Agile with us.

    We’re even more excited about the journey ahead. We have big plans, the ability to invest in our team, our products, our growth and most importantly the impact we are having for our customers.

    We’re always hiring so please reach out if you want to be part of the team that’s leading the way in helping companies around the world be agile.

    💬 “We hope one day many of our Easy Agile team will find themselves as founders of successful companies and continue this tradition with their own ESOPs”

  • Agile Best Practice

    A straightforward guide to building smart PI objectives

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

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

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

    At a glance:

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

    What are PI objectives?

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

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

    The benefits of having smart PI objectives

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

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

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

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

    What makes a good PI objective?

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

    Good PI objectives:

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

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

    PI objectives need to be SMART

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

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

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

    Tips for writing SMART (and smart) PI objectives

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

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

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

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

    Learn more

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

    You can with Easy Agile Programs

    Ready to bring your PI Objectives into Jira?

    Watch Demo

  • Workflow

    Should you form cross-functional agile teams?

    Should you form cross-functional agile teams?

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

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

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

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

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

    Key points

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

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

    What are cross-functional agile teams?

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

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

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

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

    William Rojas, Adaptavist

    What are the benefits of cross-functional agile teams?

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

    1. Cross-functional teams communicate and collaborate better

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

    2. Cross-functional teams are responsive

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

    3. Cross-functional teams are innovative

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

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

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

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

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

    What are the downsides of cross-functional agile teams?

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

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

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

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

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

    William Rojas, Adaptavist

    The first step is to just get started

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

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

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

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

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

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

  • Agile Best Practice

    Agile Ceremonies: Your Ultimate Guide To the Four Stages

    This guide looks at the four ceremonies that bring one of Agile’s most popular frameworks, Scrum, to life.

    Learn how each agile ritual helps empower teams and drive performance while highlighting some tips to help your organization get the most from your ceremonies.

    At a glance:

    • The four agile ceremonies are Sprint Planning, Daily Stand-Up, Sprint Review and Sprint Retrospective
    • Ceremonies in agile facilitate visibility, transparency, and collaboration.
    • Each ceremony has a clear structure and objective.
    • Clear communication, flexibility, and cultural alignment are the keys to successful ceremonies.

    What are the main agile ceremonies?

    Agile ceremonies refer to the four events that occur during a Scrum sprint. Other forms of agile development, such as Kanban and Lean, also have similar practices.

    The agile ceremonies list includes:

    1. Sprint Planning
    2. Daily Stand-Up
    3. Sprint Review
    4. Sprint Retrospective

    While each ceremony is different, they facilitate the same overall purpose. The ceremonies bring teams together with a common goal under a regular rhythm, and they help teams get things done.

    "With today's enterprises under increased pressure to respond quickly to the needs of their customers and stakeholders, they must bring new products to market faster and accelerate improvements to existing solutions and services." - State of Agile Report

    Why are agile ceremonies important?

    Agile ceremonies help organizations adapt to change and succeed. With work planned in smaller portions and over shorter timeframes, they help teams quickly shift direction and course-correct when needed. They form a key part of the broader agile approach that’s now widely adopted in organizations worldwide.

    With agile ceremonies, teams in your organization can benefit from:

    • Enhanced ability to manage changing priorities
    • Acceleration of software development
    • Increase in team productivity
    • Improved business and IT alignment

    It’s important to remember that while ceremonies are an essential part of Scrum, they’re just one of many rituals that help create agile teams and workplaces. To realize the true benefits of agile, you’ll need to do more than include one or more of the ceremonies into your waterfall project.

    1. Sprint Planning

    The Sprint Planning ceremony sets teams up for success by ensuring everyone understands the sprint goals and how to achieve them.

    StructureAttendeesTimingDurationAgile FrameworkThe Product Owner brings the product backlog to discuss with the Development Team. The Scrum Master facilitates. Together, the Scrum Team does effort or story point estimations. The product backlog must contain all the details necessary for estimation. The Product Owner should be able to clarify any doubts regarding the product backlog. The entire Scrum Team (the Development Team, Scrum Master, and Product Owner)At the beginning of each sprintOne to two hours per week of iteration. So, if you're planning a two-week sprint, your Sprint Planning should last two to four hours. Scrum. Although Kanban teams also plan, they do it less formally and per milestone, not iteration.

    Outcomes

    After some team negotiation and discussion, you should have a clear decision on the work that the Development Team can complete during the sprint by the end of Sprint Planning. This is known as the sprint goal.

    The sprint goal is an increment of complete work, and everyone should feel confident about the commitment.

    The product backlog defines priorities that affect the order of work. Then, the Scrum Master transforms that decision into the sprint backlog.

    Top tips

    • Focus on collaboration rather than competition.
    • Break user stories into tasks to get things more operational for the Development Team. If there's time, assign those tasks during the event.
    • Factor in public holidays and any team member’s time off or vacations.
    • Keep your team’s pace in mind – a track record of the time it took to implement similar user stories would be helpful.
    • Focus on the product backlog and nothing else in terms of work for the sprint.

    2. Daily Stand-Up

    The daily stand-up brings the team together and sets everyone up for the day. The team uses this time to identify blockers and share plans for the day.

    StructureAttendeesTimingDurationAgile frameworkThis is an informal, standing meeting. All members of the Development Team inform everyone about what they did the day before and what they’re doing today. Members discuss any blockages they have and ask for help from the team if required. Due to time restrictions, the updates should be brief.Development Team, Scrum Master, Product Owner (optional) Daily, usually in the morningShort and sharp. No longer than 15 minutesScrum and Kanban

    Outcomes

    The Scrum Master should clear all the blockages that slow down or prevent the Development Team from delivering. As a result, the development process might need to change.

    This daily pulse check keeps the team in sync and helps build trust. Together, the group finds ways to support and help each other.

    Top tips

    • Use a timer to keep this meeting to 15 minutes.
    • Hold your stand-up at the same time every day.
    • Only discuss the work for the day ahead.
    • If the team is distributed, use video conferencing with cameras on.
    • Long discussions should happen after the event.
    • As the stand-up encourages progress, everyone should provide an update, and everyone should feel accountable.

    3. Sprint Review

    The Sprint Review is the time to showcase the team’s completed work and gather feedback from stakeholders. A variety of attendees from outside the team offer valuable insights from different viewpoints. This event also helps build trust with both external and internal stakeholders.

    StructureAttendeesTimingDurationAgile frameworkThe Scrum Master takes on the logistics of event preparation. The Product Owner should ask stakeholders questions to gather as much feedback as possible. They should also answer any of their stakeholder’s questions.Development Team, Scrum Master, Product Owner. Optionally, management, customers, developers, and other stakeholders At the end of the sprintOne hour per week of the sprint. In a one-week sprint, the Sprint Review lasts one hour.Scrum and Kanban. Kanban teams do these reviews after the team milestones, not sprints.

    Outcomes

    After this ceremony, the Product Owner might need to adjust or add to the product backlog. They might also release product functionality if it's already complete.

    Top tips

    • Schedule in time to rehearse before the meeting to help your team present with confidence, especially if external stakeholders are coming along.
    • Don’t showcase incomplete work. Review your Sprint Planning and the original criteria if you’re not sure whether the work is complete.
    • Besides product functionality, focus on user experience, customer value, and the delivered business value.
    • Consider ways you can introduce a celebratory feel to acknowledge the team’s effort.

    4. Sprint Retrospective

    In this final scrum ceremony in the sequence, you look back on the work you’ve just done and identify ways to do things better next time. The Sprint Retrospective is a tool for risk mitigation in future sprints.

    StructureAttendeesTimingDurationAgile frameworkThe teams discuss what went well throughout the sprint and what went wrong. The Scrum Master should encourage the Development Team to speak up and share not only facts but also their feelings. The goal is to gather rapid feedback for continuous improvement in terms of process. It’s also an opportunity to emphasize good practices that the team adopted and should repeat.Development Team, Scrum Master, Product Owner (optional)At the end of the sprint45 minutes per sprint weekScrum and Kanban (occasionally)

    Outcomes

    After this session, the team should clearly understand the problems and the wins that happened throughout the iteration. Together, the group comes up with solutions and an action plan to prevent and identify process problems in the next sprint.

    Top tips

    • Focus on both facts and feelings
    • Gather information that helps you focus on continuous improvement – this might include tools and relationships
    • Be honest and encourage ideas that solve process-related problems
    • Even if everything went well, have this meeting – retrospectives provide ongoing guidance for the next sprint.

    "With the speed of change expected to continue, the need has never been greater for an operating model that keep up." - McKinsey

    Agile lessons to live by

    As a team of experienced agile practitioners, we’ve picked up some key learnings about what it takes to get the most out of your agile ceremonies and create the foundations of a truly agile organization.

    Here are our top tips to make your ceremonies a success:

    • Be deliberately present - During the ceremonies, remember to take moments to pause and remind yourself of why you’re there. Show others that you’re present by giving them full attention and using your body language. In a remote setting, angle your camera as though you’re sitting across from them, look into the lens regularly, and use a distraction-free background.
    • Practice active listening - Think about what the person is saying, who they are, and what they need from you. Are they looking for a soundboard, do they need your help or opinion, or are they looking for an emotional connection?
    • Understand motives - Understand the motivations of your teammates before speaking. Consider why they should care about what you’re saying by connecting your message with their own motivations. Provide context where possible to let them know why your message matters.
    • Be flexible - It's important to remember that there is not a one size fits all approach to agile ways of working. What works for one team may not work for another, so you need to experiment to find out what works then tailor processes to suit your team's needs.
    • Create cultural alignment - The best processes in the world won’t deliver what you need if you don’t have the culture to support their delivery. Agile ceremonies need to be supported by a culture where people are actively engaged, confident to raise issues, and value continuous improvement.

    Agile ceremonies lead to better results

    While it can take time for teams new to agile to adjust to agile ceremonies, they are worth the effort. By providing a clear structure and achievable outcomes, they help align everyone on the product, communication, and priorities.

    The result? Agile teams that provide better quality products faster – and deliver real business outcomes.

    Wherever your organization is on your agile journey, it’s worth keeping in mind that each team and each suite of products are different, so there’s no standard recipe for success. The good news is that by working within the continuous improvement mindset the agile framework promotes; you too can iterate and improve your agile ceremonies over time.

    Ready to get started?

    Easy Agile TeamRhythm supports your team's agile practices in Jira. Supporting your team from planning right through to retrospective, TeamRhythm helps you and your team work better together to deliver value to your customers.

    Features include:

    • Agile sprint and version planning tool - Planning is quick and easy when you create and estimate issues on the story map. View your work under initiatives and epics, and see swimlane stats at a glance, ensuring team capacity is filled but not overcommitted
    • Agile story mapping - Map the customer journey using initiatives, epics, and stories alongside your agile Jira boards. Quickly and easily add new or existing stories inside the story map. Drag and drop to prioritize by value to the customer.
    • Product backlog refinement - Escape your flat backlog and view your work on the story map matrix. Drag and drop issues to prioritize or schedule. Quickly update story summaries and story point estimates with inline editing for a better backlog.
    • Team retrospectives - Celebrate success, gain insights, and share learnings with team retrospective boards for scrum and kanban, encouraging collaboration and transparency, so you and your team are continuously improving.