You’re an RTE in PI Planning. As you walk around the tables or move between virtual breakout rooms, you hear the following conversations: 

If this sounds familiar, it might be time to create or refine your Definition of Ready for PI Planning. 

At a high level, the Definition of Ready is criteria that an Agile Team or a SAFe® Agile Release Train (ART) can use to know they are prepared to start planning, working, deploying or releasing. It’s an agreement among all parties involved. It illuminates misalignment around priorities, confusion, wasted time and incomplete commitments. 

You’ll often hear it in the context of accepting work into an Iteration. However, you can create a Definition of Ready in multiple areas. PI Planning, Iteration Planning, and backlog refinement, all will benefit from a Definition of Ready.

For this post, let’s focus on the PI Planning event in the Scaled Agile Framework. 

The Definition Ready is Subjective

Your Definition of Ready will have items specific to your organization, ART and team. You won’t find an effective cookie cutter definition. Instead, seek answers to the questions below to find the right Definition of Ready for your PI Planning. 

Quick refresher: In PI Planning, you’ll start with business context, a roadmap and vision, and the top features the teams will plan around. The outputs of PI Planning are committed PI objectives and a program board, showing dependencies and the plan to meet those objectives. 

A good Definition of Ready for PI Planning will help the Agile Teams, Product Managers, System Architects and Business Owners align on what’s necessary to plan work and create objectives. Alignment going into PI Planning will lead to alignment throughout the PI. 

Your PI Planning Definition of Ready will likely revolve around two things: features and knowledge.

Questions About Features

To form a Definition of Ready, you’ll want to answer the following questions about your features. 

  • What does your organization need to prioritize features? Arriving at a prioritized program or team backlog can require one or many inputs:  WSJF, stakeholder input, cross-ART dependencies. A clear priority for proposed features is essential to focus your planning efforts on the right areas.  
  • Which stakeholders need to know about the proposed features? Backlog items may require review or discussion from many stakeholders to be ready for planning. Are you sharing technology with other ARTs? Are there security, legal or compliance considerations? Will training, corporate communication or marketing need to be in place? Understanding internal and external implications will prevent surprises in planning and throughout the PI. 
  • What questions do the Agile Teams have about the features? Giving the teams and their Product Owners a chance to review features early helps them – and you – understand the context, complexity and dependencies that might come up. 
  • What information will the teams need to break features into stories, estimate and create PI objectives? In PI Planning, the Agile Teams decompose features and create a loose plan so they can commit to PI objectives. Are your descriptions, benefit hypotheses and acceptance criteria clear? How do you know? Are you using a common lexicon? 

Work Your Definition of Ready Into Your Flow

Once you have a Definition of Ready around Features, you have a powerful tool to ensure you meet that definition: the Program Kanban. Add your ready criteria as steps in the workflow. Making these steps visible will prevent a last-minute scramble before PI Planning. 

Questions About Knowledge

You’ll also want to ensure that the people in the ART have the information they need to plan the PI. Answer the following questions about knowledge to create your Definition of Ready for PI Planning.

  • Does everyone in the ART understand what’s expected in PI Planning? If it’s your first PI Planning, the SAFe® for Teams class helps the whole ART learn how to plan together. In future events, or as ART membership changes, consider refreshers, overviews, and new classes to prevent confusion. 
  • Have there been changes in the business context, roadmap or vision? It may be tempting to recycle these first elements of PI Planning. Instead, take a moment and ask what’s new. You can ensure alignment with up-to-date briefings. 
  • Do the teams understand the technology and UX needs? Is there something new from an architecture, engineering or user experience standpoint that you’re introducing in this PI? Will the teams need exploration enablers? Significant changes in these areas may require more than updated briefings. 
  • How do the teams find their capacity? A critical part of effective team breakouts is making sure teams aren’t overloaded. Do they know how to calculate base capacity? Do they have access to historical capacity? 
  • Is everyone in the ART invited? PI Planning works because it is a whole-ART event. This means Business Owners, Product Management, System Architects and Engineers, the RTE, and entire Agile Teams, including Scrum Masters are all participating. Setting timely expectations will help prevent conflicts. 

Relentless Improvement: Update as Needed

Even with asking and answering all these questions, you might not find your perfect Definition of Ready the first time. That’s ok. Your needs may evolve. You might see opportunities to change it in the PI Planning retrospective, throughout the PI and in your Inspect and Adapt Event. 

Find what works. Change what you need to change, and keep improving.