The Product Manager’s Role in PI Planning

This is a guide to understand the Product Manager’s role in PI Planning. As such, the article will describe what a Product Manager must do during PI planning. Read our earlier article about PI planning preparation to understand how to get ready for the event PI Planning is often described as the heartbeat of the Agile Release Train.  This event is more than a mere planning event. This is the event where the strategy gets validated against the practicalities of delivering realities.

 Product Managers Role in PI planning : The Value Gurdian

Product Managers act as a keeper of Value for the Agile Release Train- (ART). During the PI planning, a PM helps stakeholders and the teams to align, and decide what matters most, and how we will deliver it. This article will not go in depth about the PI Planning structure. This article in scaled agile website describes PI planning structure well. Here, I will talk about how a PM shows up—before and during the event—to make it actually work. Before PI Planning: What a PM must align before Day 1 Most of your impact as a PM happens before PI Planning starts. If you walk into Day 1 hoping alignment will happen in the room, you’re already late. Here I will share a few things you need to get in place early. First, stakeholder alignment. Business, Architecture, and Engineering should not be debating fundamental priorities during PI Planning. You don’t need perfect agreement—but you need enough clarity to move forward towards the intended objective Second, priority clarity. Your “Top 10” features shouldn’t be a vague wishlist. They should reflect real decisions—what makes it in, what doesn’t, and why. When you decide priorities, it is tempting to focus all your energies on the low-hanging fruit. Do not fall for the trap. Make sure to balance new features with Architecture runway. Third, dependencies. If there are known cross-team dependencies, start conversations early. Don’t wait for teams to discover them during breakouts. And finally, trade-offs. Go in with a point of view. If capacity doesn’t allow everything—and it won’t—what gives? Preparation is less about documents and more about decisions.

The Product Managers Core Role  During PI Planning

Once PI Planning starts, your role becomes very visible. At a high level, you need to

• Set the direction through the vision
• Balance priorities against capacity
• Negotiate scope when capacity, skill or dependency issues arise
• Work with stakeholders to get the Business Value (BV) numbers established
• Participating in risk management (ROAM)

What you’re NOT  responsible for is micromanaging team plans. A common mistake is trying to be everywhere and solve everything. That usually creates more noise than clarity. Your role is to anchor the conversation around value—and step in only when alignment is at risk.

Presenting the Vision: What You Must Bring to the Table

The vision presentation at the start of PI planning sets the tone for everything that follows. And it’s easy to get this wrong. Reading through slides won’t cut it. Teams need to understand:

• What are we trying to achieve this PI?
• Why does it matter?
• What are the few things we really care about?

The “Top 10 Features” matter—but not as a list. As a clear signal of priority. If everything sounds equally important, teams will struggle to make decisions later. Also, give guardrails:

• What does success look like?
• Are there constraints teams should be aware of?

  A good vision presentation helps the team with clarity about what they should focus on.

Supporting Teams During Breakouts

Breakouts are where the real planning happens. I have seen that, during the breakouts, many PMs either overstep or disappear completely. Both do not help. The balance is important. You’re there to:

• Explain focus and priority when teams are not clear
• Help negotiate scope as an when needed – This can be because
• Facilitate alignment across Product Owners

  You’re not there to dictate how teams should plan their work.

Participate in Draft Plan Reviews

Draft plan reviews are where the ART leadership (PM /RTE and system architect) first sit down with the teams to discuss the plan. This is not just a status update—it’s your chance to catch issues early. Look at:

• Team-level PI Objectives: Are the team-level PI objectives outcome-focused, or have the team just listed down the sequence of stories?
• Commitment levels: What’s committed vs uncommitted—and why? Have the teams created their commitment only on capacity basis or have they considered uncertainties like skill issues/technical feasibility and dependencies
• Capacity alignment: Are teams overloading themselves? Have they considered day to day overheads

Also, pay attention to dependencies. The ART planning board is your friend here. It helps you see where things might break before they actually do. It is often helpful to start the rough ART planning board in this segment. Don’t just listen to what teams present—look for what’s missing.

 Management Review & Problem Solving: Where PMs Shine

This is usually the most intense part of PI Planning. Plans don’t fit. They don’t look like what we had hoped for. Capacity is exceeded. Dependencies create friction. This is where a skilled and prepared PM makes a difference A good Product manager should come prepared with:

• Trade-off options, not just problems – Talk about what changes and trade offs can help us go closer to our earlier ambitions – be ready with a view on what can move out if something else must come in
• Ideas on how uncommitted work could become committed – what help you need?
• Stay firm on what can not really be done – do not set unrealistic expectations. It is critical to balance Business Urgency with team capacity and technical feasibility
• Champion the Architecture runway – do not lose focus on maintaining a balance with immediate feature value and being ready for what comes next

Assigning Business Value (BV): More Than a Number

Assigning Business Value often becomes a mechanical exercise. It shouldn’t be. This is where you help stakeholders understand what really matters. Once stakeholders really “see” what your teams will be doing – alignment is easy to follow A few things to keep in mind:

• Not everything can be “high value” – encourage stakeholders to show what matters most to them
• Explain Architectural runway  –  help the stakeholders truly sppericiate the impact they will have if teams ignore the runway completely in favor of only immediate value
• Explain Uncommitted objectives are not low priority and team will not be ignoring those—The uncommitted status reflects uncertainty

Use this moment to create shared understanding, not just assign numbers.

Common Pitfalls in PI planning

Some patterns show up very often. Good PMs take care to avoid these. Overcommitment is the big one. Planning at 100% capacity seems efficient—but it rarely works in reality. Plan adequate but transparent buffers to allow for unexpected Another anti-pattern of is to actually plan feature delivery work in the IP iteration – This will quickly kill both innovation and your planning for the next PI Then there’s the silent PM. Being unavailable or disengaged during PI Planning creates confusion quickly. Another one is ignoring architectural runway. It’s easy to deprioritize it in favor of visible features—but the cost shows up later. And finally, over-controlling. Trying to drive every decision slows teams down and reduces ownership. The goal is not control—it’s clarity.

How to be an effective PM during PI planning

Being effective during PI Planning isn’t just about what you know—it’s about how you interact during PI planning First, presence. You don’t need to be everywhere—but you do need to be accessible. Especially in high-risk discussions. Second, knowing when to step in. — Step in when teams are not clear about priorities. If they’re debating execution details—step back Third, reading the room. — Confusion, hesitation, repeated questions—these are signals that something isn’t clear. Fourth bring clarity to management and stakeholders – help them understand trade-offs —Discuss what can and can not be done — explain the need for innovation and architecture  runway Finally comes decision-making. — you will be asked to make a lot of decisions. You won’t have complete information. That’s normal. Some factors to consider are Value , risk , capacity and technical feasibility. Also consider face trade-offs: Short-term delivery vs long-term architecture or Business pressure vs technical reality Sometimes you push. Sometimes you adapt.

Conclusion: Bring enough clarity start execution

At the end of PI Planning, you’ll have a plan. But more importantly, you’ll have a level of alignment. The confidence vote is not about perfection. It’s about whether teams believe in what they’ve planned. Your role doesn’t end here. The plan needs to translate into a living backlog. Priorities need to hold—or be consciously adjusted. PI Planning is not about getting everything right upfront. It’s about creating enough clarity and alignment so that when things change—and they will—teams know how to respond. That’s what good product leadership looks like.  

The post The Product Manager’s Role in PI Planning appeared first on World Of Agile.

How to prepare for PI Planning: A Practical Guide from the Trenches

How to  prepare for PI planning? In Other words, do you have a checklist for PI Planning Readiness

When I help organizations with their SAFe journey, I often get a request, do you have a PI Planning Readiness checklist? That is the question I am planning to answer with this article

 Introduction: Why Preparing for Your First PI Planning feels overwhelming (and why it doesn’t have to be)

Getting ready for your first PI Planning often feels like tackling a mountain of scary and unclear work There are multiple teams that will participate, So many senior senior stakeholders to take care of , A lot of people have big expectations from SAFe  They are expecting measurable business outcomes from this PI and they want PI planning to ensure the magic.

Somewhere in the middle of all that, you’re expected to help “align everything.” It’s not surprising most people are a little (or a lot) overwhelmed.

I remember my first PI planning—I thought the challenge was ensuring that the two days go smoothly. It wasn’t. The real challenge was everything that what we should have done before those two days.

I am here to make that part clear…. Once you see PI Planning as a time and opportunity to get ready for the upcoming PI and not just an event. It then to starts to feel a lot more manageable. And honestly, a lot more valuable.

Common mistakes first-timers make as they Prepare for their First PI planning

The biggest mistake I see? Treating PI Planning as a two-day activity. By the time those two days begin, has already to be done already be done. PI planning is a time for Agile Teams , ART leadership, Management and Stakeholders to align their thoughts on what work we will do in the PI and how we will do it. It is not the time to start thinking fresh for the first time on what work we will do in the PI? Some other patterns tend to show up:

• People walk in without a clear sense of priorities  and the Goal
• Not considering Architecture Runway and having no idea about their percentage capacity allocation….
• Backlogs that are either over-detailed or completely unclear
• Major Dependencies only get discovered during breakout sessions
• There’s an expectation that the plan will be “final” and perfect

I’ve been in a PI where everything looked well-prepared on paper. We were so sure of our success in the PI . But on the ground, once the PI started, we realised we had not accounted for some day-to-day maintenance work we had to do… That kind of thing slows everything down.

PI Planning Preparation starts weeks before (not days before)

If you take away one thing from this article, let it be this: PI Planning wins or loses before it begins. Here is a simple checklist Few  weeks before: You focus in shaping the direction of the PI

• What is the business impact we are trying to achieve this PI?
• What are our top priorities for this PI?
• Who are the key stakeholders? Are they roughly aligned?

You don’t need all the answers—but you need a strong starting point. 1–2 weeks before: Now you start sharpening things.

• Understand  the top backlog items
• Start identifying dependencies
• Begin early conversations across teams

This is where most of the real alignment work happens. Final week: You’re not “building”—you’re checking.

• Are there any major gaps?
• Are stakeholders aligned enough?
• Do teams understand what’s coming?
• Any major dependencies

If you have been focusing in earlier week, it actually starts to feel easier at this time

Clarity on Vision, Priorities, and Outcomes is the Key To Success in PI Planning

A lot of PI Planning issues come down to one thing: unclear priorities. Not lack of effort. Not lack of tools. Just unclear direction. It is really not about detailing everything. It’s about being clear on what matters most. I’ve seen backlogs with 40 “top priorities.” That doesn’t work. Teams don’t need more items—they need clarity:

• What are the few things we really care about this PI?
• Why do they matter?
• What does success look like?

When the “why” is clear, teams make smarter calls during planning. When it isn’t, they fill in the gaps themselves—and that’s where misalignment creeps in.

 Get the Backlog Ready (without over-engineering it)

Many teams tend to overprepare the backlog. They want every story refined. Every detail thought through. Every i dotted and every t crossed.It feels responsible. It’s not always useful. What you actually need is a backlog that’s good enough to have a conversation. That means:

• The top items are clear
• There’s enough context to discuss
• Priorities are visible

That’s enough! Over-refinement can backfire. I’ve seen teams spend days breaking work down, only to rework everything once cross-team conversations begin. Also, don’t try to eliminate uncertainty. You won’t be able to do that. The goal is to surface it early, not pretend it doesn’t exist.

The fine line: Prepared enough vs over-prepared

There’s a point where preparation stops helping and starts getting in the way. You’ll notice it when teams spend more time polishing stories than actually talking about what needs to be built. It feels like progress—but it’s not always the kind that helps during PI Planning. I’ve seen teams walk in with extremely detailed backlogs—everything estimated, everything broken down neatly. And then within a few hours, half of it gets reworked because priorities shift or dependencies come up. Worse still, you notice people are not having conversations – they are merely ticking off the checklist… Assuming that things are already planned and “frozen!!”… That’s a dangerous assumption. It leads to people not speaking up even when they do notice something ….. Over-preparation usually shows up as:

• Too much detail too early
• Refining things that aren’t even top priority
• Trying to “lock” the plan before alignment actually happens

The intent is good—you want things to go smoothly. But PI Planning isn’t about validating a pre-built plan. It’s about building it together. Prepared enough means you’re ready for meaningful discussions—not that you’ve removed the need for them.

Align Stakeholders before the PI Planning

If there’s one thing that will derail your PI Planning quickly, it’s stakeholder misalignment. When Business, Product, and Architecture aren’t on the same page, it shows up fast—and publicly. Try to get ahead of that:

• Are priorities agreed upon?
• Are there known trade-offs?
• Is there any major disagreement that hasn’t been addressed?
• Last but not least – do they understand what PI planning is about?

You don’t need perfect alignment—but you do need enough alignment to move forward. The worst place to discover fundamental disagreements is in the middle of planning.

Prepare Teams (and not just the Product Owner) Before PI planning

A common pattern: Only the Product Owner is doing all the preparation work. The teams are waiting to hear from “somebody” to tell them what they will do next PI That does not help…. Teams need context. Without it, they’re starting the PI Planning in the dark. Before PI Planning:

• Share the vision and priorities
• Talk through key constraints
• Highlight known dependencies
• Explain high level stories /items
• Think about what other type of work team has to do (Build Architecture runway/deal with technical debt? / Handle some defects?) – a discussion about % capacity allocation goes a long way

This doesn’t have to be heavy. A short briefing, a walkthrough, even informal conversations go a long way. Also, make roles clear:

• Product  Manager sets direction
• Teams plan how to deliver and how much they can deliver
• Facilitators keep things moving
• Business validates alignment

When everyone knows their role, the event feels a lot less chaotic.

Logistics matter more than you think

This is one of those things you only appreciate after it goes wrong. If tools don’t work, if breakout rooms aren’t ready, if people can’t access boards—it drains energy fast. Check the basics:

• Tools are working and accessible
• You have set up the board 
• Breakouts are planned
• Considered the timebox

It sounds simple, but smooth logistics make a big difference to how the session feels.

 What “good preparation” actually looks like

Good preparation isn’t about having everything figured out. It’s about having enough context to plan…. Having the right people to Plan You’re in a good place when:

• Priorities are clear
• Stakeholders are mostly aligned
• Dependencies are visible
• Capacity  allocation and availability is understood
• Teams feel prepared—neither in dark  nor ready with a “frozen” plan.  If everything feels completely locked before PI Planning even starts, that’s usually a red flag—not a sign of readiness. You should still need the conversations.

Final checklist: Are you ready?

Before you start, do a quick check:

• Are the top priorities clear?
• Do you understand the high level business imperative for PI
• Is the backlog ready enough?
• Are stakeholders aligned?
• Have key dependencies been identified?
• Do teams have context?
• Are tools and logistics sorted?

If you’re ticking most of these, you’re in good shape.

Closing: PI Planning is a leadership moment

PI Planning very quickly exposes how things really work in your organization. It shows how well you align. How realistic your plans are. How clearly you communicate. It’s also a moment where leadership becomes appreant—not just in decisions, but in how well teams are set up to succeed. You don’t need a perfect plan. That’s not the goal. What you need is shared understanding, realistic direction, and teams that feel confident about what they’re committing to. Get that right, and PI Planning stops feeling overwhelming—and starts becoming genuinely useful

The post How to prepare for PI Planning appeared first on World Of Agile.

Real-Life Scenarios when multiple Teams are working on the Same Product

In this section, we will look at some real-life scenarios that Scrum Team(s) often face when multiple Teams are working on the Same Product . This article is part of an ongoing series on real-life scenarios that many Scrum Teams face. Adding more teams to a product should increase speed. That’s the expectation. However, in many organisations, the opposite happens. Despite having multiple Scrum Teams working in parallel, delivery slows down, dependencies increase, and alignment becomes harder. Teams stay busy, but product progress feels inconsistent. The problem is not the number of teams—it is the complexity that comes with them. Working with multiple teams on the same product requires a different level of discipline, collaboration, and clarity. Without it, scaling Agile can quickly turn into scaling confusion. Based on my experience working with multi-team environments across Scrum, SAFe, and Kanban setups, here are some real-life scenarios that frequently emerge.

1. “We are done” (But Others cannot use it!!)

Team A completes their work and marks their stories as “Done.” However, when Team B tries to use the same functionality, they run into issues—missing APIs, incomplete validations, and inconsistent behaviour. From Team A’s perspective, the work is complete. From Team B’s perspective, it is not usable.

Snehamayee’s perspective

What’s happening here? Each team delivers their work with their own interpretation of what “Done” means. There is a clear lack of a shared understanding at the product level. Impact: Work appears complete on dashboards, but real progress is not seen. Instead, the teams struggle with rework, delays, and frustration What we can do?

• A shared Definition of Done across teams is critical. It should include integration, usability by other teams, and alignment with product-level quality standards. “Done” should mean usable—not just complete within a team boundary.
• Integrated Solution level or Product level reviews – SAFe (Scaled Agile Framework ) recommends regular System demos. These are integrated demos – These will enable teams to “see” how their work is being used by other teams. These demos also help the teams as they encourage collaboration

2. Dependency Chaos Between Teams

A very common situation in multi-team setups is when one team’s progress depends heavily on another. You often hear statements like: “We can’t start until Team B finishes their part.” Or “We’re blocked waiting for the API from Team C.” Snehamayee’s perspective What’s happening here? Some possible reasons are

• Component Teams -Teams are often structured around components rather than features. This leads to tight coupling between teams.
• Inefficient work slicing – In addition, the work slicing (splitting work across teams) often creates additional dependencies across team boundaries

Impact: Planning becomes uncertain, commitments become unreliable, and teams lose their ability to deliver independently. Instead of enabling speed, multiple teams create bottlenecks. What we can do?  

• Reducing dependencies should be a continuous focus. This may involve rethinking backlog slicing, re-assignment of work, or even restructuring teams toward more feature-oriented ownership.
• Dependency Board – Visually tracking the multi-team dependencies will help the teams identify critical path to monitor, bottlenecks to be aware about and trigger remedial actions in advance to reduce dependencies. Another SAFe technique the ART planning board will help.
• Design Feature Teams –Teams that are designed to deliver end to end value rather than a specific component help with easier coupling

3. Conflicting Priorities Across Teams

In another setup, each team appears busy and productive. However, when viewed from a product perspective, progress is slow and scattered. Different teams work on different priorities—some on new features, others on technical improvements, and some addressing stakeholder requests.

Snehamayee’s perspective

What’s happening here?

There is no clear alignment at the product level. Teams optimize for their own backlog rather than a shared product goal.

Impact: High activity does not translate into meaningful outcomes. Work gets fragmented, and the product evolves in an inconsistent manner. What we can do?

• Clear product-level prioritization is essential. Whether through a single Product Owner, a Chief Product Owner, or a well-aligned Product Management function, teams need a shared understanding of what matters most.
• A cross-domain planning session – A common planning session across teams will help the teams to align their priorities and expectations.

4. Integration Becomes a Nightmare

Integration of work is one of the most common challenges for the multi-team product. Each team develops and tests its work independently. Everything works fine within team boundaries. However, when all components come together, issues start to surface—unexpected defects, incompatible interfaces, and performance problems.

Snehamayee’s perspective

What’s happening here?

Integration happens too late. Teams work in silos with limited visibility into how their work interacts with others.

Impact: Integration risks accumulate over time. On top,  these integration risks will often surface at the worst possible moment—close to release timelines.

What we can do?

• Frequent integration is key. Practices such as continuous integration, shared environments, and automated testing help reduce surprises. Integration should not be treated as a separate phase—it should be part of everyday development.
• A common Sprint Duration – A common Sprint Duration will provide a cadence needed for frequent integration
• Regular Integrated demos Or System demos as defined by SAFe will help. These demos help to enforce regular integration

5. Ownership Confusion – “Who Owns This?”

In multi-team environments, features often span across teams. This creates situations where responsibility is unclear. When an issue arises, the response is often: “This part belongs to Team A.” or “That integration is handled by Team B.” or “This is not our responsibility”

Snehamayee’s perspective

What’s happening here?

Ownership is divided along component or functional lines, rather than end-to-end product outcomes.

Impact: Slow decision-making, blurred accountability and issues that take longer to resolve. In some cases, important items fall through the cracks because no team feels responsible.

What can we do? Clear ownership of outcomes is critical. Even if multiple teams contribute, there should be clarity on who is accountable for delivering the feature end-to-end. Shifting toward feature ownership rather than component ownership can help address this challenge.

Final Thoughts on Real-Life Scenarios Faced by Scrum Teams When Multiple Teams Work on the Same Product

Working with multiple teams on the same product is not just about adding capacity(or people). It is about managing complexity. Many of the challenges discussed above are not caused by a lack of skill or effort. They arise from gaps in alignment, communication, and shared understanding. Some common issues I have seen across many customers are:

• Lack of shared standards – for example, a common integrated Definition of Done or common  quality standards
• High dependencies between teams means a tight coupling and more limitations
• Misaligned priorities lead to effort wastage and rework
• Limited focus on integration and ownership

  It takes conscious effort to address these challenges. Some tips that help are

• Better Alignment among teams by planned multi team events like structured cross-domain planning
• Establishing collaboration forums like dependency boards
• Designing feature teams that deliver end to end value and move away from component teams

Organisations that recognise and actively address these patterns are more likely to realise the true benefits of scaling Agile. Those that do not often find themselves adding more teams—but not necessarily delivering more value.    

The post Real-Life Scenarios Faced when multiple Teams are working on the Same Product appeared first on World Of Agile.

As part of the Introduction to Scaled Agile Framework series, this article will explain how the backlogs scale in SAFe.

The Enterprise Backlog Structure

A hierarchical backlog structure is necessary to manage the work to be done at Scaled world. This mechanism organizes the Enterprise around value delivery at all levels. Depending on the configuration selected, SAFe uses up to 4 backlogs (full SAFe configuration):

• Portfolio Epics are split into Capabilities or features
• Capabilities are split into Features
• Features split into Stories .

Of course, items are not required to originate from a higher-level backlog only. Some items may also arise locally. The items that flow through from the higher backlogs tend to be more long-term and strategic. Diagram below summarizes the backlog structure, primary roles responsible, and duration and scope of various backlog items

The post How The Backlogs Scale in SAFe appeared first on World Of Agile.

As part of the Introduction to Scaled Agile Framework series, this article will explain Events in SAFe and how they scale.

Events in SAFe At Essential SAFe Layer

Essential SAFe covers 2 layers the Team and ART Layer- each layer has its own event. The ART events contain the iteration events within the PI – The Planning Interval

ART Events Drive The Planning Interval

ART events drive the Planning Interval. The Planning Interval (Pl) is a timebox during which an Agile Release Train (ART) delivers incremental value. This value is in the form of working, tested software and systems. Pis are typically 8 – 12 weeks long. The most common pattern for a Pl is four development Iterations, followed by one Innovation and Planning (IP) Iteration. Each individual Iteration has its own events. The section below will describe the individual Iteration events.. This section discusses about events at the ART or PI level.

PI Planning

Planning Interval planning (PI Planning) is a two-day event. PI Planning is a cadence-based, face-to-face event that serves as the heartbeat of the Agile Release Train (ART). This event aligns all the teams on the ART to a shared mission and Vision.

In this event, everyone in the ART gets together to agree team and overall PI objectives. They also forecast which iteration the priority features on the ART backlog will be completed. As part of this event, dependencies between teams are identified and planned in. While risks are identified and either resolved, owned, accepted or mitigated.

PI planning happens during the IP iteration of last PI. For an example, for the PI 3, the PI planning will happen during IP iteration of PI 2.

ART Sync, Scrum of Scrums and PO Sync

Over the course of the PI, there are regular check in sessions for team representatives. During this event representatives discuss progress towards the PI objectives and other topics. The ART Sync is the parent ART event that combines the Product Owner (PO) Sync and Scrum of Scrums (SoS).

For large ARTs, usually ART sync is divided in two separate meetings, PO Sync and SoS

In the scrum of scrums events the RTE, scrum masters and other selected team members Join. These particpants discuss progress, impediments and inter-team dependencies. Usually the RTE acts as the meeting facilitator

In PO Sync events where product manager, product owner and other selected stakeholders join. These participants discuss progress, priorities and scope adjustment.

For smaller ARTs, the PO sync and SOS meetings can be combined into one single meeting .

System Demo

Shortly after the end of each iteration in the PI, the completed work from all of the teams is integrated into a staging environment and is demonstrated to business owners and other stakeholders. It is essential that the demonstration is of fully integrated work. This event does not replace, but is in addition to, the team’s iteration reviews.

Inspect and Adapt workshop

This event takes place right at the end of the PI dueing the IP iteration of that PI.

This event has of three parts: the PI system demo; quantitative and qualitative measurement; and the problem‑solving workshop.

• The PI system demo is similar to the system demo, but it shows the current state of the solution. It highlights the work done throughout the whole PI, not just in the last iteration. Also, every member of ART attends this event.
• During the quantitative and qualitative measurement part, the RTE presents ART metrics to the members of the ART.
• In the problem-solving workshop, the teams conduct a relatively short (1-2 hours) retrospective on the PI. The focus is to identify the root causes of problems and identify actions that can address the root cause to stop the issues presenting themselves in future programme increments.

Iteration Level Events

Each iteration has the events similar to those explained in the Scrum Guide

• Iteration Planning
• Team Sync
• Iteration Review/ Demo
• Iteration Retrospective

The diagram below shows how the terms used by SAFe relate to those in the Scrum Guide

Events in SAFe at Solution Level Events

For a large solution, the cadence does not change from the ART level, it is still a Planning Interval of 8-12 weeks. At the large solution level, the solution backlog contains, capabilities of the system, rather than features or stories.

Pre- and Post-PI Planning
In order to coordinate work across multiple ARTs and also with suppliers, there is an alignment meeting both before and after the individual ART PI planning sessions. Synchronisation of the PI planning events is essential in order for the pre- and post-PI planning events to be meaningful and happen within a few days of each other.

Solution Demo
During the solution demo, the development efforts of the solution train (multiple ARTs and work from suppliers) are made visible to customers and other stakeholders. This event is a both a celebration of the work achieved in the last PI and an opportunity to gain feedback ahead of the next one. It is an opportunity for the customer and other stakeholders to influence upcoming work. During the event, capabilities are demonstrated, including any stated compliance and non-functional requirements.

Attendees usually include, customers, large solution stakeholders, representatives from each of the ART (e.g. product managers and product owners), solution management, lean portfolio management (if used) and the solution train engineer (STE), who is likely to be facilitating this event.

The post Events in SAFe appeared first on World Of Agile.

As part of the Introduction to Scaled Agile Framework series, this article will explain different Roles in SAFe

Roles in Scaled Agile Framework Scale up from the team level roles usually Associated with Scrum. Please refer to the Red box in the above diagram. This Red box highlights the placement of Roles in the SAFe big Picture.

Key SAFe roles at Team Level

The key roles at Team are:

• Agile Team members -Do the day to day work. Team as a whole is responsible for delivery and quality of the work undertaken.
• Scrum Master/Team Coach – This person is the servant leader, coaches of the Agile Team. They also help remove impediments and foster an environment for high­ performing team dynamics, continuous flow, and relentless improvement.
• Product Owner – Product Owners are accountable for User story Prioritization. They help everyone understand the well described stories

Key roles at Program Level

The key at program level are:

• Product Manager – Product Managers prioritize well described features. They help everyone to understand them
• Release Train Engineer – responsible for ensuring the agile release train (the team of agile teams) work well together and follow the processes.
• Customer – consumes the output from the agile release train. Could be external customers or people within the organisation. The customers are the people who will have the final view on whether the output was valuable.
• Business Owner – key stakeholders who are ultimately responsible for the business outcome.
• System Architect/Engineer – responsible for designing and sharing the architectural vision across the agile release train, which means the work delivered will be fit for purpose.

Key roles at Solution Level

The key SAFe roles the solution level are:

• Solution Manager – Solution Management is responsible for defining and supporting the building of desirable, feasible, viable, and sustainable large-scale business solutions that meet customer needs. They work with the Solution Backlog and are accountable for responsible for prioritising capabilities and ensuring they are well defined and understood.
• Solution Architect/Engineer – responsible for designing and sharing the architectural vision across multiple agile release trains, which means the solutions delivered will be fit for purpose.
• Solution Train Engineer – responsible for facilitating and guiding the work done by all of the agile release trains delivering the solution.

Key roles at Portfolio level

The key at portfolio level are:

• Epic Owners – responsible for defining an epic, articulating its benefits and facilitating its implementation.
• Enterprise Architect – drives architectural initiatives for the portfolio.

Other key SAFe roles include:

• SAFe Programme Consultant (SPC) – use their technical knowledge of SAFe to advance the organisation’s systems, and processes for developing systems. They are key to successfully implementing SAFe and often come from an internal centre of excellence or from an external consultancy. Agility in Mind has qualified SPCs as members of its consulting team.

The post Roles in SAFe appeared first on World Of Agile.

A part of the Introduction to SAFe® series, this article will give an overview of SAFe Configurations

SAFe® or the Scaled Agile Framework enables the complete range of Value Stream development. To achieve this, SAFe comes with four built in or out-of-the-box configurations. We have given highlights of the configurations below.

Please read SAFe for Lean Enterprises – Scaled Agile Framework to get more information. The diagram below showcases how the four configurations work together

Below we have explained each configuration briefly

Essential SAFe

The Essential SAFe is the base configuration. And as such, is the most accessible form of SAFe. It has the least number of artifacts, events and roles needed to operate and Agile system. This configuration uses the Agile Release Train (ART) structure to organize and enhance business flow. Teams working in in remote or international business environments can also this configurations.

Essential SAFe is best suitable for a single program with about 50-120 people and around 10 Agile teams. That is why it has 2 layers – Team and ART. Please note that using essential SAFe will definitely have benefits. However, using only essential SAFe will not lead to business Agility – This is why the top Green bar showing Business Agility is missing in this section.

Only 4 of the seven core competencies and Few of the Spanning palette elements are necessary for essential SAFe. However, the ART is free to leverage other competencies or Spanning palette elements.

Large Solution SAFe

The Large solution SAFe is a more advanced configuration than essential SAFe. It offers a wider range of practices, roles and guidance for huge and complex solutions. The configuration builds upon Essential SAFe and adds the enterprise solution delivery competency. This new addition enables those who need several ARTs and suppliers to achieve more intricate results. This configuration also uses all the elements of Spanning Palette. However, this configuration is limited to the solution and enterprise, or portfolio constructs are not included. It is often used by locomotive, government, aerospace and defense organizations. There are 3 layers in this configuration – Team, Program and Solution.

The Solution Train used here synchronizes the efforts of multiple ARTs and suppliers, allowing larger-scale businesses to incorporate Agile practices. This configuration focusses on governing the solution itself not the portfolio or enterprise governance. Due to this reason, top blue ribbon of Business Agility is missing.

Portfolio SAFe

This configuration adds the Lean portfolio management, organizational agility and continuous learning culture. This configuration provides the minimum requirements for a portfolio or an enterprise to operate in Agile manner. This is the Reason we can see the Blue Business Agility section at the top. The section also describes the “measure and grow” apprach to quantifying the progress. This configuration uses 3 layers – Team, Program and Portfolio

Portfolio execution is the highlight for this configuration. Enterprise strategy and organization are developed around one or more value streams while assisting portfolio strategy and investment funding. Lean Portfolio management and Agile governance principles guide, the value stream and ARTs to achieve the required results. These principles also help with deciding the suitable level of investment.

Full SAFe Configuration

The Full SAFe configuration is the largest and most encompassing configuration. This configuration includes all seven core competencies. Most often very large companies use Full SAFe configuration to maintain and govern their portfolios and/or complex solutions. It may incorporate several smaller configurations of SAFe running alongside it. This configuration uses all four layers – Team, Program, Solution and Portfolio.

The post SAFe Configurations appeared first on World Of Agile.

A part of the Introduction to SAFe® series, this article will give an overview of SAFe Big Picture

The SAFe Big Picture

The Scaled Agile Framework or SAFe® website shows the SAFe big picture. This is a visual and interactive model of the Framework. The SAFe big picture is the primary user interface to access this knowledge base. Each image is a clickable icon. Once you click on the icon it takes you can article explaining details about the same. The right bottom corner shows the version (5.1 in this case). The SAFe Big Picture can be broken down in below components

1. Business Agility
2. Foundation
3. Core Competencies
4. The Spanning Palette
5. The Main Section that shows SAFe Configurations
6. The Tabs to choose configurations
7. Roles in SAFe
8. The Agile Delivery Train
9. How The Requirements Scale up – The different backlogs

1- Business Agility

Business Agility is the ability to compete and thrive in the digital age by quickly responding to market changes and emerging opportunities with innovative, digitally-enabled business solution

The blue business Agility bar indicates that SAFe helps to achieve Business Agility. This Bar will be shown only for the portfolio or full configuration. This indicates that while you can use SAFe even for just a small program within your organization, Business Agility can be achieved only if we implement SAFe at portfolio level. We have marked the Business Agility section as component 1 in the diagram above.

2–Foundation

Situated at the bottom of the SAFe big picture, this grey box highlights the foundational elements of SAFe. Key Icons here are

• Core Values -SAFe follows four core values which are as given below – These values define the belief and value system for SAFe.
  • Alignment,
  • Transparency,
  • Respect for people
  • Relentless Improvement
• Lean Agile MindSet – The lean Agile mindset forms the philosophy behind SAFe. This philosophy provides a foundation for adopting and applying SAFe principles and practices. The Lean-Agile Mindset is the combination of beliefs, assumptions, attitudes, and actions of SAFe leaders and practitioners who embrace the concepts of the Agile Manifesto and Lean thinking.
• SAFe Principles – The practices mentioned in the scaled agile framework are based upon the 10 SAFe principles. These principles are based upon agile mindset and methods, DevOps and system thinking. In addition, they also bring in decades of practical experience of the creators.
• Lean Agile Leadership The leadership has the final and ultimate accountability to ensure Business Agility. SAFe describes a leadership style, where the leaders are tasked to be the lean thinking managers and teachers who lead from the front. To indicate this, Leadership as a core competency is shown in the foundation of the big picture
• Implementation Roadmap SAFe provides a built in implementation road map that can help the enterprise on their journey towards Business Agility
• SPC The SAFe practice consultants or the SPCs are trained change agents who leverage their experience and knowledge of SAFe to help the organizations progress towards Businesses Agility
• Continuous Learning

3-The Core Competencies

SAFe 5 is built around the seven core competencies required in any lean enterprise. These competencies can be thought lens that can help to understand and implement SAFe. Each of these competencies describes the knowledge, skills and behaviors required on the journey to achieve Business Agility.

4-The Spanning Palette

The spanning palette is highlighted as “Number 4” in the diagram above. It represents various roles / artifacts that may be needed for a specific team, program, large solution, or portfolio context. The spelling palette is an essential component that drives SAFes flexibility as well as adaptability. It contains some additional guiding elements which are applicable only in certain contexts. The elements of this palette are as explained below

• Vision – The vision describes a future view of the solution to be developed. While doing so it reflects customer and stakeholder needs. It also lists the Features and Capabilities proposed to satisfy the said needs.
• OKRs – Objectives and Key Results (OKRs)help to define clear goals along with quantifiable outcomes.  When used within SAFe, they can help to support the Core Values of Alignment as well as transparency between the Enterprise and Portfolio strategy. These OKRs also provide guidance to Teams in Agile Release Trains to deliver on this strategy. Additionally, OKRs will also help to quantify organizational improvement activities, including the desired outcomes for the SAFe transformation.
• Roadmap – The roadmap describes and shares timeline of planned deliverables and milestones for ART and value stream
• Artificial Intelligence (AI) is a term used to describe a wide range of smart machines capable of performing tasks that typically required human intelligence. AI can be applied at all levels of SAFe to build intelligent customer solutions, automate value stream activities, and improve customer insights. It is a technology that can revolutionize solutions developed by SAFe organizations and has the potential to dramatically influence the operational and business models of enterprises as well.
• Shared Services – Describes the niche or special roles required for an ART or Solution Train’s success. These are the roles that cannot be dedicated full time to any specific train.
• Community of Practice (CoP) – A community of practice is an informal group of people, (team members and/or other experts) acting within the context of a program or enterprise. A CoP is dedicated to sharing practical knowledge relevant domains(s).
•  System Team – The system team is a special Agile Team which helps in building or leveraging the continuous delivery pipeline. Where necessary, System team also helps to validate the full end-to-end system performance.
• Measure and Grow The section also shows “Measure and Grow” at the very bottom. Measure and Grow is the built-in Mechanism in SAFe to measure the progress towards Agility and plan for next steps.

5-The Main Body Of the SAFe Big Picture / 6 The Selection Tabs

The main area of SAFe Big Picture describes how SAFe works at various levels or configurations. SAFe can be used right from a smallish program containing 50-125 people to an entire Organization having various size programs and large initiatives with thousands of people. You can imagine that this section shows four layers of Scaling – Team, Program, Solution and Portfolio.

To ensure ease of use across this vast range, have defined four SAFe configurations. Essential /Large Solution /Portfolio and Full. Please review the Tabs on top right (section 6) to read about Specific configurations. The Overview tab gives information about core competencies

The section describes how the Agile Release train works (marked as section 8) . It also describes also how to scale up the business requirements by scaling up the backlog (marked as section 9).

The four configurations and how they use the layers is briefly explain in this article.

7-Roles in SAFe

SAFe uses Scrum and Kanban at individual team levels. It leverages the 3 team level roles. As the teams scale up SAFe introduces additional roles that manage complexity and establish Agile at Enterprise level. Please look for section 7 to identify these Roles

8- Agile Release Train

The Agile Release Train (ART) is of Agile teams. This is a long-lived team. The ART, along with other stakeholders, incrementally develops, delivers, and where applicable operates, one or more solutions. The ART is arranged around in a value stream.

9- Scaling The Backlogs

In a single team way of working, Product Backlog captures everything to do. The Product Goal helps the team to align. When we are working with multiple teams across many Value chains , then we need to Scale the product backlog up – SAFe handles this by having a Team Backlog / Program Backlog / Solution Backlog and a Portfolio Backlog. Pls look for section 9 in above diagram

The post SAFe Big Picture – An Overview appeared first on World Of Agile.

As a part of the Introduction to SAFe® series, we will explore, “How SAFe® helps with Business Agility” – in this Article.

We Are in The Software and Digital Age

It is said that major technology revolutions that disrupt the common person’s life happen once in a generation – The last five revolutions are shown in the diagram above. Right now we are in Age of Software and Digital. Software and technology are impacting business in all industry areas.

Everything moves fast in the software / digital age.  The market conditions demand that the business is able to pivot the direction quickly with any mercy or guilt. At the same time, business have to balance this Speed of innovation with the stability and efficiency to stay competitive

What is Business Agility

Major technology advances like AI, DevOps and Cloud are unlocking new ways to enhance value at a furious pace. Because of these technology advances, enterprises in traditional industries are fast becoming software focused enterprises. Regardless of domain or the scale of your enterprise, almost all capital investments have a technology component

To thrive in this environment, the companies need to adapt their traditional way of working, Dean leffingwell, creator of the Scaled Agile Framework says

“Every business is a software business now. Achieving a state of Business Agility means that the entire organization—not just development—is engaged in continually and proactively delivering innovative business solutions faster than the competition“

Business Agility can be defined as the ability to compete and thrive in the digital age by quickly responding to market changes and emerging opportunities with innovative, digitally-enabled business solutions. It requires

1. Technical agility
2. A business-level commitment to product and Value Stream thinking.
3. everyone involved in delivering business solutions uses Lean and Agile practices.

How SAFe® helps with Business Agility

The Scaled Agile Framework leverages Agile philosophy, values and Principles. Along with Agile, the framework relies upon the systems thinking and Lean product development. This enables the businesses to develop and deliver best in -class solutions built upon latest technology and maintain the quality and quick turn around time.

SAFe^® 5 for Lean Enterprises is a knowledge base of proven, integrated principles, practices, and competencies for achieving Business Agility by implementing Lean, Agile, and DevOps at scale

This framework is freely available online at their website https://www.scaledagileframework.com/

The post How SAFe® helps with Business Agility appeared first on World Of Agile.

In this series we plan to give an Introduction to Scaled Agile Framework ^® or SAFe^®

The 15th State of Agile Report states that

Scaled Agile Framework (SAFe®) continues to be the most popular with 37% of respondents identifying it as the framework they most closely follow. SAFe® signifi cantly outdistances the next nearest scaling method, Scrum@ Scale/Scrum of Scrums (9%).

As stated on the ScaledAgile website, Scaled Agile Framework or the SAFe ® is the world’s most trusted system for business agility. SAFe has fast become the Framework of Choice for Leading Organizations. More than 1,000,000 practitioners and 20,000 enterprises worldwide in nearly every industry trust the Scaled Agile Framework® (SAFe®). Gartner names SAFe the #1 most considered and adopted framework for scaling Agile.

Since the earliest days at Scaled Agile, the core belief has been simple: better software and systems make the world a better place. SAFe Version 5 enables the business agility. This focus on Business Agility helps large enterprises to compete and thrive in the digital age. Business Agility requires every part of the organization involved in delivering technology-based solutions. In this section of our blog, we will be giving a brief introduction and few highlights of the SAFe framework. Please pursue the https://www.scaledagileframework.com/ website to get Indepth details about this industry leading framework.

Some of the topics covered in this series are

1- Why do we enterprises need to leverage Scaled Agile?

2- Some Basic concepts about Scaling

3- How SAFe provides a Dual Operating System to balance speed of Innovation and Stability/efficiency

4- How SAFe helps to achieve Business Agility?

5- How to read the SAFe Big Picture

6– SAFe configurations

7– Roles in SAFe

8- How the events scale up in SAFe or how a Program Increment works

9- How The Backlogs Scale in SAFe

The post Introduction to Scaled Agile Framework appeared first on World Of Agile.