How to improve dependencies management with visualization
Teams who are building products or completing projects necessarily rely on each other. Identifying and keeping track of dependencies can be difficult, particularly across multiple teams or external or shared teams. Dependencies management is often something that can be taken for granted as part of a standard operating procedure. In this article, we will look more closely at the process of identifying, troubleshooting and resolving any dependencies that prevent work from being delivered.
A common example is if one piece of working software depends on an external plugin or third party tool. If that plugin fails to operate, then the working software may fail as well. Similarly, large organizations working on multiple pieces of software at once may have habitual or recurring dependencies between different teams in order to operate. This is why agile teams need processes to monitor dependencies so they won’t disrupt development or inhibit flow.
The more complex dependencies become, ironically, the more simple a process you need to manage them at scale. Complexity compounds complexity, so finding an approach whether it is a tool or a framework that works within the context of your teams and your organization is the key to unlocking dependency management in a sustainable way.
Let’s take a closer look at how you may approach managing dependencies within your organization.
Similarly, agile frameworks such as LeSS and SAFe can help with dependencies management in large organizations. Finally, finding ways to visualize the dependencies in an organization is a highly effective way to mitigate the risks of delaying projects.
Want to empower your teams to manage their dependencies?
Try Easy Agile Programs - Watch on demand demo
Now, close your eyes and imagine the rest. Just kidding, read on...as if your agility depends on it. 😂
Types of dependencies in project management
Before we discuss tools and frameworks, let's outline a few different types of dependencies:
- Direct dependency: This common dependency type is one where one project or feature depends on the delivery of another.
- Transitive dependencies: This is where we have an indirect connection between two projects, usually by way of a connecting project. For example, Feature A depends on Feature B, and Feature B depends on Feature C. Therefore, Feature A indirectly depends on Feature C.
- External dependencies: These dependencies can be out of the remit of your team, group of teams or organization. It helps to be aware of them and it is worth identifying them separately as the addressing of these dependencies may be outside of the scope of the team or group level ceremonies.
Let’s dive in now to some frameworks for a blueprint of how to approach this.
Agile frameworks for organizations to improve dependency management
You're probably familiar with the most common agile frameworks for software development — Kanban and Scrum. These frameworks are mostly suited for individual team organizations. But what about frameworks for cross-functional agile teams in a large organization who need help with dependencies management?
LeSS for dependency management
LeSS is a framework that helps multiple Scrum teams who are working together on a single project to scale. Think of LeSS as Scrum at a large enterprise scale — you still have a single product backlog, a product owner, a Scrum master, and software developers. But the key difference is that there are many teams working towards the same goal and the same definition of done (rather than a single team).
One of the most important tasks for the product owner role in the LeSS framework is making sure that dependency information is provided across teams. In LeSS, product backlog refinement (PBR) is an organized event that makes sure dependency risks are consistently identified. PBR allows multiple teams to plan sprints in parallel and to identify if there are any cross-team dependencies that risk project completion.
SAFe approach to managing dependencies
The SAFe (Scaled Agile framework) provides principles and workflow patterns to guide organizations through their dependencies. SAFe promotes transparency and alignment across large organizations so they can be more nimble in meeting their business objectives. Being able to respond to changes quickly can be hindered by size and scale. Dependencies can often tangle work and trip up teams due to the inability to see and appreciate cross-functional team dependencies.
Just as scrum has ceremonies to keep a single agile team aligned, an essential ceremony to keep multiple teams aligned and communicating with each other according to the Scaled Agile Framework (SAFe) is Program Increment / Planning Interval Planning - better known as PI Planning. During PI Planning, teams create their dependencies and through cross-functional collaboration can adjust their plans to manage these dependencies.
Unlike startups, who are small and can typically make organizational changes quickly, large organizations often become too big to make rapid changes. One common cause of this is the inability to manage dependency resolution because dependencies are less visible for cross-functional teams.
Just as Scrum has ceremonies to keep a single agile team aligned, an essential ceremony to keep multiple teams in the Scaled Agile Framework communicating with each other is Program Increment (PI) Planning. It’s a way to keep even the largest organizations nimble.
One key output of PI Planning is the program (dependency) board or ART planning board (SAFe 6.0).
Easy Agile Programs: Equip your remote, distributed or co-located teams for success with a digital tool for PI Planning.
Watch on demand demo
PI Planning for large organizations
PI Planning is a periodic ceremony that happens throughout the year. Teams within an organization gather to compile their thoughts on product features and the product roadmap, and to discover any dependencies that exist between them.
One key feature of PI Planning is an ART planning board (program board). ART planning boards help give Agile Release Trains (ART) — a group of agile teams working together on a common goal — a visual representation of what the teams have planned to complete from their PI Planning.
Visualize your dependencies
Easy Agile Programs for Jira is a complete tool for dependencies management at a program level. By utilizing visualizations and by providing transparency across projects, teams can confidently scale without the risk of unforeseen dependencies and disruptions. It does this by providing three views:
- Program roadmap: an overview of all of the scheduled increments or iterations for a program or group of teams
- Program Board (ART Planning Board): an at-a-glance visualization of all of the teams within a program, including all of their cross-team dependencies
- Team planning board: where teams break down committed features for the upcoming increment, create dependencies with other teams, estimate and schedule their work.
Visualise dependencies with Easy Agile Programs: Filter the Program Board by at risk, healthy or blocked dependencies for effective conversations.
Watch on demand demo
Try free for 30 days
Unlock your organization's common dependencies
Managing dependencies comes first from being able to see what you need to manage and then to be able to focus where is needed. As a highly visual and filterable tool, Easy Agile Programs can support in many ways:
- Highly visual dependencies: The color of the dependency lines reflects their health status. A red dependency represents a conflict, yellow indicates at risk, green signifies a healthy state and black indicates external dependencies outside the current view, such as work in the backlog or in an other Program Increments. The colours support product managers, release train engineers or scrum masters to know where to focus. To avoid bottlenecks, you need to address the red dependencies and the yellow where possible.
- Team alignment to each other and business outcomes: Adding in third level hierarchy issues to capture and communicate higher level business initiative or priorities helps teams to understand the context of the bigger picture and why they are delivering what is scheduled. Making sure that all of your ART or group of teams work is represented and visible on a board that is always up to date helps keep teams aligned.
- Focus mode: Alignment needs to be maintained beyond planning. With a number of filters applicable to the program board to focus on teams, epic or issue status, dependency health or initiative, it is easy to focus the work - and conversations - on what is most important.
Related Articles
WorkflowHow to use dependencies to improve the flow of work
Success for agile software teams revolves around collaboration, flexibility, and efficiency. Whether you're a coach or Release Train Engineer supporting multiple teams, or a scrum master or engineer aiming for improvement within your team, honing your dependency management skills will boost efficiency and productivity.
While dependencies often seem like hurdles, here's an insight: they can be a powerful strategic tool to enhance your agile team's performance. In this post, we'll explore how you can leverage dependencies to guide your team towards greater efficiency and success.
Agile Team Autonomy
At the heart of agile is the concept of autonomy and self-management. It's all about empowering teams to own the end-to-end delivery of their work with minimal dependencies. This means optimizing their workflow rather than relying on other teams to deliver value to users. When teams need to depend on others, the flow of work becomes less predictable.
In larger, more complex companies, dependencies are often unavoidable due to the sheer size and intricacy of systems. The real challenge is transforming these dependencies into opportunities for improvement rather than roadblocks. By improving the visibility of these dependencies, teams can better understand them, prioritize and sequence work effectively and manage delivery planning and execution more efficiently.
More than one-third of agile teams report that team silos and the delays that result are a problem
17th State of Agile Report, Digital.AI
Dependency visualization
Improving the visibility of dependencies starts with open communication and transparency. When team members are comfortable sharing their tasks and challenges, you create a culture of trust and collaboration. This transparency is critical for identifying dependencies early and managing them effectively.
Software that allows teams to map out dependencies clearly can be a great tool for improving the visibility of work, making it easier to track their status and plan accordingly. Regularly updating and reviewing the dependencies you've mapped keeps everyone on the same page and helps you anticipate potential bottlenecks before they occur.
Easy Agile TeamRhythm is a user-friendly app that integrates seamlessly with Jira to support team planning, which includes visualizing dependencies. You can display dependencies by type and risk, and see dependencies both within your team and with other teams.
Dependency Patterns
Once you're able to see dependencies clearly, you might recognize patterns forming. These dependency patterns can show where a team is relying too heavily or too dependent on another team to deliver work.
Consistent bottlenecks highlight opportunities for improvement, like a change in team composition. When you notice these patterns, it's essential to reassess and implement strategies to become more self-reliant, ensuring a smoother flow of work and improved delivery timelines.
Prioritizing and Sequencing Work
Once dependencies are identified and made visible, you can improve the flow of work by organizing tasks in a sequence that avoids work being delayed by other tasks. Not all tasks carry the same weight or urgency, and understanding the critical path—the sequence of tasks that determines the fastest time to deliver value—can help focus efforts where they are needed most.
Sequencing work thoughtfully ensures that dependent tasks are tackled in the right order, minimizing delays and rework. This strategic approach to task management not only enhances team efficiency but also supports a smoother workflow and avoids delivery being derailed at the last minute.
Better Collaboration
By identifying and visualizing dependencies, you spot bottlenecks early, re-prioritize tasks, and manage delivery plans effectively. More importantly, it empowers your team to take complete ownership of their tasks while constantly improving their workflows.
Remember, every dependency is a piece of a larger puzzle that holds the potential to boost your team's efficiency. By understanding and managing these dependencies proactively, you can ensure smoother workflows, fewer roadblocks, and a highly efficient agile team.
Agile Best PracticeHow SAFe & Visualization of Dependencies Empower Businesses at Scale
Many organizations, especially those in highly regulated industries, struggle to manage large-scale projects. SAFe, or the Scaled Agile Framework, can provide a solution. (OR That's where SAFe, or the Scaled Agile Framework, comes into play.)
SAFe is a framework designed to help businesses make sustainable changes on a large scale. It offers training and guidance for implementing agile practices across the enterprise, whether it's at a small team level, department level, or throughout the entire organization.
In this blog post, we will delve deeper into the benefits of implementing SAFe, focusing specifically on how it can be utilized within the financial services industry to create a lean enterprise.
Benefits of SAFe for financial services
SAFe (Scaled Agile Framework) is an incredibly valuable approach for organizations looking to enhance their operations. By adopting SAFe, financial services firms can achieve numerous benefits that are specific to their industry.
- Business Agility: SAFe enables financial services firms to become more adaptable and responsive to market dynamics. By adopting SAFe practices at an enterprise level, organizations can foster a culture of continuous improvement, allowing them to quickly adapt to changing customer demands, regulatory requirements, and emerging technologies.
- Enhanced Customer Experience: In today's competitive financial services landscape, providing exceptional customer experiences is paramount. SAFe promotes customer-centricity by encouraging regular feedback loops with customers throughout the development process. This allows financial institutions to gather insights, identify pain points, and rapidly iterate on their products and services, ensuring they meet the evolving needs and expectations of their customers.
- Accelerated Time-to-Market: Time is of the essence in the financial industry. SAFe empowers organizations to speed up their time-to-market by breaking down silos and fostering collaboration between departments. By leveraging agile practices, financial services firms can respond quickly to market opportunities, launch innovative solutions faster ensuring they are first to seize market opportunities
- Risk Mitigation: Compliance and risk management are critical considerations for financial services organizations. SAFe provides a structured governance framework that incorporates compliance requirements into the development process. This ensures that products and services adhere to regulatory standards.
- Improved Operational Efficiency: Financial services firms deal with significant complexity, from managing intricate financial systems to addressing regulatory demands. SAFe helps optimize operational efficiency by promoting transparency, communication, and continuous improvement. By implementing Lean principles and agile practices, organizations can eliminate waste, optimize processes, and enhance overall operational performance.
- Employee Engagement and Empowerment: SAFe emphasizes the empowerment of teams, fostering a culture of collaboration, innovation, and continuous learning. This approach leads to increased employee engagement, as team members feel more involved in decision-making processes and have a sense of ownership over their work. The result is a motivated and empowered workforce that drives organizational success.
Visualizing Dependencies for Seamless Collaboration and Timely Delivery
In the intricate world of SAFe, covering every aspect can be overwhelming. For the purpose of this blog, let's focus on a specific use case.
The financial services industry often deals with complex projects involving multiple teams and stakeholders. In such scenarios, visualizing and understanding dependencies among teams becomes critical. This is where the SAFe program board comes in. It acts as a centralized space for teams to effectively visualize, manage dependencies, and progress transparently.
Consider the example of Easy Agile Bank, preparing to launch its self-service banking platform. Various teams, including software, marketing, and customer success, collaborate to make this launch successful. To ensure a seamless rollout, understanding team dependencies and efficient work scheduling are paramount. The goal is to prevent bottlenecks that could delay the launch of the new self-service banking app.
Let’s take a closer look at what this might look like. Below you can see the Team Planning board in Easy Agile Programs for the Software team. The red, yellow, green and black lines indicate dependencies. Some dependencies exist within the software team, while others are cross-team dependencies with the marketing team.
The color of the dependency lines reflects their health status. A red dependency represents a conflict, yellow indicates at risk, green signifies a healthy state and black indicates external dependencies outside the current view, such as work in the backlog or in an other Program Increments. To avoid bottlenecks, you need to address the red dependencies and the yellow where possible.
With Easy Agile Programs, visualizing dependencies becomes effortless. Teams can act swiftly and adjust plans accordingly to prevent delays in the app launch. For instance, the software team identifies a red dependency with the marketing team regarding the live chat system. While the software team plans to set it up in Sprint 2, the marketing team don’t plan on mapping out the live chat experience and messaging until Sprint 3. The dependency line serves as a visual indicator, prompting teams to discuss and reschedule work.
After a brief discussion, the software team decides to reschedule the live chat setup to Sprint 4. As a result, the dependency line turns green, indicating a smooth progress and successful avoidance of a potential bottleneck.
“When I would ask colleagues how long it would take to untangle and understand dependencies, they would suggest a week. With Easy Agile Programs, it took us three minutes”.
Stefan Höhn, NFON
Harness the Power of the SAFe Program Board
Overall, the program board can help teams prioritize their work and make informed decisions about resource allocation. By visualizing dependencies, teams can identify critical path items and focus their efforts on the most important tasks that need to be completed first. This ensures that teams are working in a coordinated, transparent manner and reduces the risk of unnecessary delays or conflicts.
The SAFe program board acts as a valuable tool for teams to effectively manage dependencies, promote collaboration, and achieve alignment in large-scale agile projects.
Easy Agile Programs allows teams to identify and create dependencies effortlessly, empowering teams to navigate the complex financial services landscape with ease.
WorkflowThe 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:- What is PI Planning?
- Why do PI Planning?
- What is the goal of PI Planning?
- What should be included in the PI Planning agenda?
- What happens in the first part of the PI Planning meeting?
- Why is a confidence vote held at the end of PI Planning?
- When is PI Planning held?
- What is a pre-PI Planning event and when is it needed?
- PI Planning in SAFe
- PI Planning in Scrum
- What is the difference between a PI Roadmap and a Solution Roadmap?
- What is a program?
- What is a program board?
- Who should be involved in PI Planning?
- How to prepare for PI Planning
- What happens after PI Planning?
- What is a post-PI Planning event?
- Remote or hybrid PI Planning
- Common PI Planning mistakes
- Using Jira for PI Planning
Let’s start with the basics…
What is PI Planning?
PI Planning stands for Program Increment Planning.
PI Planning sessions are regularly scheduled events where teams within the same Agile Release Train (ART) meet to align and agree on what comes next. Teams will aim to align on goals and priorities, discuss features, plan the roadmap, and identify cross-team dependencies.
The goal is to align the teams to the mission and each other. Here are the essential elements of PI Planning:
- 2 full day events run every 8-12 weeks (depending on the length of your increments)
- Product Managers work to prioritize the planned features for the increment beforehand
- Development teams own user story planning and estimation
- Engineers and UX teams work to validate the planning
Why do PI Planning?
PI Planning is incredibly beneficial for large-scale agile organizations. PI Planning enables:
- Communication
- Visibility
- Collaboration
To understand the impact, let’s look at an example of a large organization that hasn’t yet implemented PI Planning. This organization has 250 teams and 6,500 team members. These teams rarely speak to each other, outside of dealing with a critical issue that has forced them to collaborate.
Alignment across these teams happens at the leadership team level, and they have multiple levels of managers in between who cascade information down with varying success. There is a constant battle for resources, budget, and opportunities to work on the most exciting projects.
Their projects have a habit of conflicting - one team would release something and then it would break something in another team’s project.
PI Planning is the first time many big companies get their teams together in a room or on the same call to talk to each other. This is a chance to have important conversations about who is working on what.
Why is this important?
- When you’re touching a system or a code repository, you need to know how it’s going to impact another team
- You might need to do some work to enable another team to work on their feature first (and vice versa)
With proper planning and collaboration, teams can get things done more effectively, release with more predictability, and stay on budget.
All very good reasons to do PI Planning.
What is the goal of PI Planning?
PI Planning is an essential part of the Scaled Agile Framework, a framework that’s designed to bring agile to large companies with multiple teams.
SAFe PI Planning helps teams in the Agile Release Train (ART) synchronize, collaborate, and align on workflows, objectives, releases, and more.
Without PI Planning, teams don’t have structured communication. They may not know what the other teams are working on, which can cause a lot of problems. For example, two teams might be working on different features without realizing there’s a dependency, which could hold up the release or require a significant rework of the code.
The goal of PI Planning is to have all your teams aligned strategically and enable cross-team collaboration to avoid these potential problems.
Now that we’ve covered off the “why”, let’s dig a bit deeper into the “what”. The best way to get a picture of what happens during PI Planning is to take a look at an agenda.
What should be included in the PI Planning agenda?
Here’s a standard PI Planning agenda template:
Day 1 AgendaDay 2 Agenda8:00 - 9:00 | Business Context8:00 - 9:00 | Planning Adjustments9:00 - 10:30 | Product/Solution Vision9:00 - 11:00 | Team Breakouts10:30 - 11:30 | Architecture Vision and Development Practices11:00 - 13:00 | Final Plan Review and Lunch11:30 - 13:00 | Planning Context and Lunch13:00 - 14:00 | ART Risks13:00 - 16:00 | Team Breakouts14:00 - 14:15 | Confidence Vote16:00 - 17:00 | Draft Plan Review14:15 - ?? |Plan Rework?17:00 - 18:00 | Management Review and Problem Solving?? | Planning Retrospective and Moving Forward
Source: scaledagileframework.com/pi-planning
This agenda might be perfect for you, or you might make changes based on the needs of your teams.
Distributed teams, very large ARTs, and other factors might require you to be creative with the schedule. Some sessions may need more time, while others can be shortened. If you have teams in multiple time zones, your PI Planning agenda may need to go over 3-4 days. If it’s your first PI Planning event, try the standard agenda, get feedback from your teams, and experiment with different formats next time.
What happens in the first part of the PI Planning meeting?
The first part of the PI Planning meeting is designed to set the context for the planning that happen next.
Day 1 usually kicks off with a presentation from a Senior Executive or Business Owner. The agenda allows an hour to talk about the current state of the business. They highlight specific customer needs, how the current products address these needs, and potential gaps.
After that, the Product Management team will share the current vision for your product or solution. They’ll talk about any changes that have occurred since the last PI Planning session (usually around 3 months prior). They’ll describe what’s coming up, including milestones and the next 10 features that are planned. This session should take around 1.5 hours.
Why is a confidence vote held at the end of PI Planning?
The confidence vote is a seemingly small but very important part of PI Planning towards the end of the event.
It is important the team is confident in committing to the objectives and work that is planned. The Release Train Engineer will ask teams to vote on this.
Everyone participating in planning needs to vote. This could be via a raise of hands (and fingers) or it could be via the tool you’re using. For example, the Team Planning board in Easy Agile Programs allows each team member to enter their confidence vote.
If the average vote across the room is at least three out of five, the plan is a go-ahead. If it’s less it’ll need reworking (until it reaches a high confidence level). If anyone votes just one or two, they’ll have the chance to share their reasoning.
The confidence vote is all about making sure that the attendees are in alignment and that they agree that the plan in its current form is possible within the given timeframe. Speaking of timing, let’s talk about how and where PI Planning actually fits into your company calendar.
When is PI Planning held?
Many companies find that 8-12 weeks (which adds up to 4-6 x 2-week iterations) is the right amount of time for an increment.
Some companies hold quarterly PI Planning, for example:
- Q1 PI Planning: December
- Q2 PI Planning: March
- Q3 PI Planning: June
- Q4 PI Planning: September
However, the timing and frequency will depend on how long each program increment is scheduled to last and may need to accommodate holidays.
The good thing about PI Planning events is that they happen regularly on a fixed schedule, which means you can plan for them well ahead of time. That means teams and Business Owners have plenty of notice to ensure they can show up for the event.
This means that what happens in preparation for PI Planning can be just as important as the event itself.
What is a pre-PI Planning event and when is it needed?
A pre-planning event - separate to PI Planning - is to make sure that the ART is aligned within the broader Solution Train before they do PI Planning. It’s all about synchronizing with the other ARTs to ensure the solution and organization are heading in the right direction, together.
You’ll need to organize a pre-PI Planning event if you’re operating at the Large Solution, Portfolio, or Full SAFe levels. Essential SAFe is more basic and does not have a Solution Train, so if you’re operating at this level, you won’t need pre-PI Planning so formally.
Here are a few of the roles that should be invited to the pre-planning event:
- Solution Train Engineer
- Solution Management
- Solution Architect/Engineering
- Solution System Team
- Release Train Engineers
- Product Management
- System Architects/Engineers
- Customers
They’ll look at the top capabilities from the Solution Backlog, Solution Intent, Vision, and Solution Roadmap. It’s really a lot like PI Planning but at a higher level, across the overall solution and not just the individual ART.
The event starts with each ART summing up their previous program increment and accomplishments to set the context. Next, a senior executive will brief the attendees on the current situation before Solution Management discusses the current solution vision and any changes from what was shared previously. Other things that are often discussed or finalized include:
- Roadmaps
- Milestones
- Solution backlogs
- Upcoming PI features from the Program Backlog
In the next section, we'll help to define a few key terms that have been touched on.
PI Planning in SAFe
If you’re adopting SAFe for the first time, chances are it will start with PI Planning. That’s because it forms the foundation of the Scaled Agile Framework.
As Scaled Agile says, "if you are not doing it, you are not doing SAFe."
Definition:
SAFe or the Scaled Agile Framework™ is a series of guidelines and practices designed to help bring agility into larger organizations, across all teams and levels of the business. The framework is geared at improving visibility, alignment, and collaboration and should lead to greater productivity, better results, and faster delivery.
Whether you’re adopting all 5 levels or just essential SAFe, the foundation of your transformation and the driver for everything is the PI Planning ceremony.
Scrum and Kanban are also agile frameworks (that you may be more familiar with), and these have historically been very effective at the individual team level. SAFe helps to scale agility across teams; to have multiple teams come together to work on the same products, objectives, and outcomes. It goes beyond the team level to include every stakeholder, outlining what should happen at each level of the organization to ensure that scaled planning is successful.
The purpose of SAFe is to improve the visibility of work and alignment across teams, which will lead to more predictable business results.
This is increasingly important for organizations as they respond to changing circumstances and customer expectations. The traditional waterfall approaches fall short because they’re slow and inefficient.
Bigger companies (often with thousands of developers) can’t keep up with the innovation of smaller, more nimble startups. Along with bigger teams, larger organizations often have stricter requirements around governance and compliance, making it more complex to launch a new feature and deliver new value to customers.
These companies are looking for new ways to organize people into projects and introduce more effective ways of working that use resources more effectively and provide more predictable delivery. If they don’t, they may not survive.
SAFe is a way for these companies to start moving in a more agile direction.
PI Planning is a vital element of SAFe. It’s a ceremony that brings together representatives from every team to help them work together, decide on top features to work on next, identify dependencies, and make a plan for the next Program Increment. As a result, there’s greater visibility across all the teams, changes are made more frequently, and teams work with each other - not against each other. From there, these massive companies can speed up their processes, work more efficiently, compete with newer and more nimble companies, and stay viable.
SAFe and PI Planning are powerful enablers for organizational agility.
While SAFe is a framework designed for larger organizations, there isn't a reason stopping smaller companies from doing a version of PI Planning, too. All you need is more than one agile team to make it worthwhile.
PI Planning in Scrum
You can also use PI Planning as part of a simple Scrum approach.
Scrum Framework diagram shows when and how scrum teams can implement PI Planning
Source: Scrum.org
Scrum is an agile framework that helps teams get things done. It’s a way for teams to plan and organize their own work and tackle user stories and tasks in smaller time boxes. This is often referred to as a sprint.
If multiple scrum teams want to work better together (but aren’t necessarily operating within SAFe), they could adopt a version of PI Planning.
For example, these scrum teams could:
- Meet every 10 weeks and discuss the features they are planning to work on
- Get product managers to combine backlogs and prioritize together
- Share resources across the teams, as needed
- Map dependencies and coordinate joint releases
The good news here is that there’s no “one size fits all” approach to PI Planning, so think about how you could adopt the ideas and principles and make it work for your organization and context.
What is the difference between a PI Roadmap and a Solution Roadmap?
There are different types of roadmaps in SAFe, so it’s important to understand the differences and what each roadmap is meant to do.
PI Roadmap
A PI Roadmap is created before your PI Planning event and also reviewed and updated by Product Management after the event is finished. It will usually cover three Program Increments:
- The current increment (work that’s committed)
- The next forecasted increment (planned work based on forecasted objectives)
- 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.
- Launch team
- Food team
- Oxygen team (Agile)
- 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:
- Launch team (Agile)
- Food team (Agile)
- Oxygen team (Agile)
- 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
Who is involved in PI Planning?
There are 5 key roles in a PI Planning event:
- Release Train Engineers
- Product Managers
- Product Owners
- Scrum Masters
- 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 📫