No items found.
Workflow
#
min read

The Ultimate Guide to PI Planning

Published on
June 14, 2024
Contributors
Written by
Jasmin Iordanidis
Jasmin Iordanidis
Product Marketing Manager
Contents
This is some text inside of a div block.
This is some text inside of a div block.
This is some text inside of a div block.
Subscribe to our newsletter
All posts

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 📫

Easy Agile Programs
Scale planning and collaboration across teams
Learn more

Related Articles

  • Agile Best Practice

    How to Get the Most From the 4 Key Agile Meetings

    We’re off to the races! 🏃🏃‍♀️ Sprints are a key component of agile methodology. A sprint is a predefined time period in which agile teams work together towards an agreed-upon sprint goal. There are four types of agile meetings that occur over the course of a sprint, and each is vital to ensuring the success of the agile process. It’s all about sprinting through a predetermined amount of work to get to the finish line, where you learn from your process and begin the race again (only better off because of what you learned during the previous sprint).

    Agile meetings are used to get team members, leaders, and stakeholders on the same page, and they guide the process of an agile sprint or Scrum.

    This post will cover the four key agile meetings, which include sprint planning, daily standups, sprint reviews, and sprint retrospectives. Plus, we’ll discuss a bonus agile meeting that’s utilized for backlog refinement.

    Agile meetings vs. Scrum meetings

    Scrum is an agile methodology that’s most commonly used in software development. Scrum meetings are technically a type of agile meeting, but they have more specific parameters designed to fit within the Scrum framework. The process revolves around a 2-4 week sprint involving a product owner, Scrum Master, and the entire Scrum team.

    We covered Scrum meetings (ceremonies) in detail in another article. For the purposes of this post, we’ll focus on the four main agile meeting types. These processes and best practices can be applied across multiple agile methodologies, including Scrum and Kanban. This framework can also be applied across industries beyond software development and can adapt to the needs of most teams.

    Simply put: Scrum has a more rigid framework that follows four ceremonies/meetings. The agile process is much the same, with four very similar meetings, but there’s more flexibility to adjust the time frame of the sprint and adapt the process when not following Scrum guidelines specifically. Okay, maybe that’s still not simply put, but it wouldn’t be agile if it was linear and straightforward.

    The 4 types of agile meetings

    There are four central agile meetings: sprint planning, daily standups, sprint reviews, and sprint retrospective meetings. A sprint starts with a sprint planning meeting. Each day, a daily standup meeting is held. Finally, at the end of the sprint, a sprint review and retrospective are held. The process repeats with new springs until the product, project, or work is complete.

    1. Sprint planning meeting

    The sprint planning meeting occurs at the beginning of a sprint and involves the entire team. In sprint planning, the entire team meets to discuss and agree upon which work tasks (backlog items) should be moved to the sprint backlog — the items that need to be completed by the end of the sprint. During the meeting, sprint goals are determined, and the team aligns on expectations.

    Without a sprint planning meeting to outline the sprint backlog (tasks that need to be completed), the team will waste time during the sprint trying to determine which work takes precedent.

    Sprint planning mistakes to avoid:

    • Starting planning without a refined backlog
    • Not being on the same page as your stakeholders
    • Ignoring the customer and the customer journey when making plans
    • Creating a rigid plan that doesn’t have room to grow or adapt
    • Using bland, flat product maps that lack critical context
    • Failing to incorporate retrospective insights in the following planning session

    Learn more about common agile planning mistakes and how your development team can avoid these pitfalls.

    2. Daily standup meeting

    The daily standup meeting occurs every day of the sprint. In the Scrum process, this meeting might also be called the daily Scrum meeting. It’s a chance for the team to connect about the work that was completed the previous day and what each person or team plans to complete over the course of the next 24 hours.

    The meeting aims to answer three important questions:

    • What work was completed since the last standup to help the team reach the sprint goal?
    • What work do you plan to complete today?
    • Is there anything currently in your way or hindering your progress?

    This is a good time to address any bottlenecks. If work planned from the previous day wasn’t completed, what caused the delay, and how can the team work together to solve any problems keeping the work from moving forward?

    A standup meeting is short and to the point so everyone can get back to the work they hope to complete. So short that it’s often recommended participants stand for the duration of the meeting. Hence the name daily standup. It includes all team members and ideally takes place at the same time every day to ensure everyone can always attend.

    Daily standup mistakes to avoid:

    • Not keeping track of the time during the meeting
    • Continually going over the allotted meeting time
    • Rambling participants who aren’t prepared to answer the meeting’s key questions
    • Skipping the meeting due to lack of time
    • Team members showing up late to the meeting or missing it altogether
    • Allowing the loudest voices to overshadow the rest of the team
    • Letting someone state the same task on multiple consecutive days
    • Failing to address potential bottlenecks
    • Assigning work beyond a person's capacity

    3. Sprint review meeting

    The sprint review is an opportunity for the team to showcase the work they accomplished during the sprint. This meeting might be an internal presentation or a more formal demo to stakeholders, depending on the needs of the project and how far along work is.

    Sprint review mistakes to avoid:

    • Not properly preparing for the meeting or demonstration
    • Not bringing stakeholders in on your process
    • Failing to demonstrate how the work brings value to the customer
    • Exaggerating or embellishing successes
    • Failing to address any problems and how they were solved
    • Not incorporating sprint review feedback into the next sprint planning meeting

    4. Sprint retrospective meeting

    The retrospective is a crucial part of the agile process. The meeting comes at the end of the sprint, bringing the entire team together to assess their processes and discuss how they can improve next time.

    Which aspects of the sprint went well, and what can you learn from that success? What didn’t go so well, and what bottlenecks did the team hit? What could be done better next time? Since agile is all about learning and iterating, there are lessons to be learned after each sprint. Everything from the good to the bad to the mediocre can be transformed into actionable improvements.

    Retrospective mistakes to avoid:

    • Blaming individual team members for bottlenecks
    • Allowing only the loudest voices to provide insight
    • Failing to empower the softer voices in the room
    • Repeating the same questions over and over without changing things up
    • Allowing the retrospective to run too long (aim for two hours for a two-week sprint)
    • Skipping a retrospective due to a lack of time or resources
    • Forgetting about or not including stakeholder insights or needs
    • Failing to improve upon the sprint retrospective process (retrospective the retrospective!)
    • Failing to incorporate retrospective insights in the next sprint

    Bonus: Backlog refinement meeting

    It could be argued that there’s a fifth agile meeting, especially in the product development world. Before the sprint planning meeting, the product owner must create a product backlog, which comprises all of the tasks and items the team needs to complete in order to fully develop the end product or project. The items include user stories, bug fixes, features, and other tasks that must be addressed to achieve the end goal.

    Backlog refinement prepares the backlog for sprint planning by ordering items to deliver the most impact over the next sprint. During backlog refinement, a product owner ensures that product backlog items contain enough information, detail, and prioritization for the team to make smart decisions about what to tackle when.

    A meeting to refine the backlog may occur before sprint planning begins, depending on the current state of the product backlog. Outside of the product development industry, the product backlog might be akin to a master project task list.

    Backlog refinement meeting mistakes to avoid:

    • Not completing backlog refinement in time for sprint planning
    • Leaving too much backlog refinement for the planning meeting
    • Failing to prioritize items that provide customer value
    • Not incorporating new stakeholder feedback, questions, and concerns

    Agile meetings: Final review

    So there you have it! The four key agile meetings are sprint planning, daily standups, sprint reviews, and sprint retrospectives, with an honorable mention going out to backlog refinement.

    Let’s review each meeting’s purpose:

    • Sprint planning gets everyone on the same page about what needs to be accomplished over the course of the coming sprint.
    • Daily standups ensure the team stays on track and helps them address and resolve any potential bottlenecks.
    • Sprint reviews are an opportunity for the team to showcase the work accomplished during the sprint to stakeholders and receive critical feedback.
    • Sprint retrospectives allow the team to come together to discuss what went well, what didn’t go well, and how they can improve next time.
    • Backlog refinement prepares the backlog for sprint planning in order to deliver the most impact over the next sprint.

    Hold effective agile meetings with Easy Agile

    Easy Agile is committed to helping teams work better with agile. Easy Agile builds products specifically designed for Jira users to help agile teams work more efficiently and effectively.

    We regularly publish lists of tools, advice articles, and how-to guides for agile teams. If you work with Jira, you’ll find our resources are especially helpful in navigating the ins and outs of product development and the Jira apps that will improve the way your team collaborates.

    Read more
  • Agile Best Practice

    Daily Scrum: Best Practices and Pitfalls to Avoid

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

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

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

    What is the Daily Scrum Meeting?

    daily Scrum meeting

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

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

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

    Importance of Daily Scrum

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

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

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

    Key Participants in the Daily Scrum

    Development team

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

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

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

    Scrum master and product owner

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

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

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

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

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

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

    Daily Scrum Best Practices

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

    1. Complete the daily scrum in a time box

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

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

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

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

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

    Daily Scrums for Remote or Distributed Teams

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

    Leverage Video Meetings Intelligently

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

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

    Manage Time Zones Wisely

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

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

    Utilize Visual Tools

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

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

    Define Working Agreements

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

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

    Daily Scrum Pitfalls

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

    1. Using the meeting as a status update

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

    2. Turning it into a problem-solving session

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

    3. Focusing on a task board

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

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

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

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

    Master Daily Scrum and Become an Agile Pro

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

    Read more
  • Agile Best Practice

    How to Lead Agile Retrospectives for Constant Improvement

    Agile retrospectives offer opportunities for introspection. As with many things in life, the end is almost as important as the beginning. That’s why it’s important to improve what went wrong throughout the iteration and repeat what went well.

    The retrospective meeting should be held at regular intervals to analyze team processes and outcomes. Reflecting on the last sprint should help guide the next one.

    Sprint retrospectives are also informal but structured. Informality is a typical characteristic of the retrospective meeting, which motivates problem-solving.

    In this article, we’ll review what an agile retrospective is, how to lead it successfully, and how to use the retrospective format.

    What is an agile retrospective?

    An agile retrospective is also known as the sprint or sailboat retrospective.

    The Scrum Guide provides a clear definition of the agile retrospective. The Guide says the agile team can use the sprint retrospective as an opportunity to gather rapid feedback for continuous improvement. Continuous improvement takes place through ongoing teamwork and work analysis.

    During the meeting, the team discusses what went well and what didn’t. They should identify the good, that they will aim to repeat as well as the areas to adjust, so the next sprint can go more smoothly.

    Here’s how the 12 principles of the Agile Manifesto describes retrospectives: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.”

    How to implement a sprint retrospective format

    You can either implement the agile retrospective after each sprint, quarter, or the entire project. However, you should have a retrospective at regular intervals to continue iteration and improvements.

    Use a retrospective format for each meeting. Creating a retrospective board is a great place to start, it sets the scene for the team involved and they know exactly what is expected.

    We've added retrospective boards to Easy Agile TeamRhythm to help you and your team through more of the agile cycle, from planning through to review.

    Easy Agile TeamRhythm

    Here’s how to plan the sprint retrospective:

    1. Preparation

    Like a standup meeting, your preparation time for the retrospective should take about 15 minutes. The retro is like a lean coffee meeting where the agenda is relatively unstructured but democratic. Everyone gets to contribute.

    Ideally, you want to have a retrospective board where team members can capture feedback as it arises. Be sure to remind team members to add their thoughts to the board prior to the meeting.

    The retrospective board helps guide the retro process through tasks where the team fell short or excelled with action items. It also helps to identify areas of improvement and the actions the group must apply to effect change.

    If in-person team members don’t use software to facilitate their agile retrospective, they can use another technique. This technique usually involves a whiteboard, Post-Its, and markers to guide brainstorming throughout the meeting.

    Whichever methodology (Scrum or Kanban) the scrum master uses, a visual representation helps facilitate the best possible outcomes for future workflows.

    Hot tip 🔥

    It is best to rope in a neutral facilitator or agile coach to guide this process. This technique should help encourage team members to participate and share without feeling pressured.

    2. Use the retrospective template to guide your agenda format

    The retrospective board helps direct the agenda for the meeting format. Whether you choose start, stop, continue, glad, sad, mad, or our team's personal favourite - high notes, low notes and keeping the beat. Make sure you customise it to suit your teams needs.

    Typically, the process follows six steps:

    2.1 Set the stage

    Refresh your memory about themes and stories in the last sprint if necessary. Set a timer and give the team a little extra time to add any last minute thoughts or items that may be missing

    At the start of the retrospective, the Scrum master should introduce the product owner, team members, and other relevant stakeholders.

    Welcome everyone and let them know that their participation is valuable. Inform team members that honesty is critical in producing positive outcomes. Ensure new teams know that questions are welcome, and that sharing experiences is vital to a successful sprint retrospective.

    Throw in an icebreaker to set the tone of the meeting. A brief game of “two truths and one lie” can quickly promote a relaxed atmosphere if you have enough time.

    Let the team know the amount of time it should take to complete each section of the sprint review. To keep everyone on track, the timer can come in handy again here.

    2.2 Celebrate the wins

    Congratulate team members who excelled. Discuss posting success stories on LinkedIn or elsewhere before moving on with the sprint review. Interact with items made on the retro board, react with an emoji or leave a comment.

    2.3 Gather data

    Data gathering includes collecting information from team members about sprint retrospective problems. The purpose is for the team to uncover the root cause of the problems.

    Team members begin this process by sharing sprint experiences. Whether the experience was good, bad, or ugly—share it. It’s always a good idea to capture how everyone is feeling, take a mood survey to understand the overall team feeling.

    Share the processes you used and which milestones you accomplished. If team members applied new technologies, share how those went. If they used new tools, let everyone know the pros and cons of each tool. Whatever the experience, let everyone know what worked well and what was a disappointment.

    The Scrum master can facilitate this phase by using the “five whys” methodology. The “five whys” essentially refers to asking why a problem occurred, five times. Repeating the question multiple times supports deep thinking to get to the root cause of the problem.

    2.4 Brainstorm solutions

    Once the team members identify the shortcomings of the previous sprint, they can brainstorm solutions.

    The team meeting should now revolve around associations between problems and solutions. Linking problems and solutions involves understanding. Once the team understands their mistakes, they can brainstorm several solutions to fix each problem area with better action items.

    Throw in as many ideas as possible to have several solutions for consideration. Once the team has alignment on the action item, be sure to capture this so the appropriate next steps can be taken.

    The retrospective board in TeamRhythm sits alongside your work in Jira, so that retrospective items can be added as the sprint or version progresses. Action items from the retrospective can be turned into Jira issues so that items worth actioning aren’t lost at the end of the discussion.

    The Scrum master should also ensure that the team has the authority to follow through with relevant solutions at this stage. If they don’t have the authority to solve problems, the Scrum master must bump the issue up to a higher level.

    2.5 Select viable solutions

    Not all solutions from the brainstorming phase will be viable — ask the Scrum team, including the product owner, to choose three promising solutions for each problem. You can use different techniques to narrow this process, and ask team members to vote. You might want to try a dot vote, or up vote by giving the solution a thumbs up.

    The simple vote requires everyone to select the solution that resonates best with them in the follow-up activity. In the dot vote, meeting participants find the best three solutions by placing a dot on three of the ideas they believe hold the most value.

    Lastly, the multiple vote system means that the scrum master gives everyone points. The scrum team must then give these points to one or more of the best ideas.

    2.6 End the meeting

    End the meeting on a positive note before continuing to the next sprint. Try to leave with:

    • A detailed synopsis of the previous sprint
    • A detailed sprint planning exercise for the next sprint meeting
    • Clear action items and next steps
    • Collaborate as a team to determine whether this outcome is effective or needs improvements for the next iteration

    3. Sprint retrospective meeting outcomes

    Software development teams can use the S.M.A.R.T. criteria to analyze their solutions. Getting the product owner's inputs is a valuable part of the retrospective meetings as they diversify priorities and perceptions

    The agile coach or Scrum master takes the S.M.A.R.T. solutions and translates these into item actions. The Scrum master should ask team members to take responsibility for activities to promote ownership and encourage behavioral change.

    Once the product owner agrees, each activity should then become part of the backlog.

    How to achieve successful retrospectives from in-depth introspection

    An in-depth introspection promotes continuous improvement and productivity. Following a retrospective template helps achieve these goals, while supporting integrated teamwork. The product owner also benefits from your team efforts with each sprint retrospective, which is a primary objective.

    Gain team alignment with team retrospectives

    Easy Agile TeamRhythm supports agile retrospectives, helping you and your team gain a shared understanding of the work, and how you work best together. Designed for Jira users, our goal is to help agile teams work together effectively.

    Try Easy Agile TeamRhythm free for 30 days

    Read more