The PI Planning meeting is a hallmark practice for the Scaled Agile Framework (SAFe).  In this 2-day meeting, everyone from development teams, architects, business leadership, and stakeholders meet to align the Agile Release Train (ART) for the upcoming Program Increment (PI).  When done correctly, the benefits can be staggering: as reported in a 2018 SAFe Summit presentation, AT&T was able to reach consensus for an important design decision in a three-hour meeting, which would normally have taken weeks of voicemails and instant messaging. Because the development teams are in close contact and alignment, during a different PI Planning meeting for AT&T, a development team was able to use another team’s feature instead of creating their own, saving almost a million dollars in development costs alone.

PI Planning is a two-day meeting where normally all the members of the ART are present in a single room. With distributed development, this may not always be possible.  If organizations are attempting a distributed PI Planning meeting, the use of technology, especially audio-visual technology, becomes important.

Regardless of whether the PI Planning Meeting is in a “big room” or distributed, the agenda usually looks similar to the example below:

Day 1 AgendaDay 2 Agenda
8AM – 9AM Business Context8AM – 9AM Planning Adjustments
9AM – 10:30AM Product/Solution Vision9AM – 11AM Team Breakout sessions
10:30AM – 11:30AM Architectural Vision & Development Practices11AM – 1PM Final Plan Review & Lunch
11:30AM – 1PM Planning Context & Lunch1PM – 2PM Program Risks
1PM – 4PM Team Breakout sessions2PM – 2:15PM Confidence Vote
4PM – 5PM Draft Plan Review2:15PM – ?:?? Plan Rework
5PM – 6PM Management Review & Problem Solving(After rework) Planning Retrospective & Moving Forward

If your PI Planning meeting is geographically distributed, you may be using a mix of the following technologies:

  • audio/visual web conferencing (e.g. Zoom)
  • chat-based conferencing room (e.g. Slack)
  • Jira, Confluence, or Trello for creating and storing artifacts created during PI planning

In this article, we’ll explore using Trello to create the artifacts that are normally seen during PI planning. We’ll start with those artifacts that can be created easily, without the use of enhancements, or Trello power-ups.

Risk Board

During the second day, risks are identified by the teams and presented to the Agile Release Train. The ART then takes each risk and places it in one of four columns:

  • Resolved – The risk is closed with agreement that it is not a concern
  • Owned – A team takes ownership of managing the risk
  • Accepted – The risk may be allowed to happen. It may also be a statement of fact or a potential problem
  • Mitigated – Mitigation steps are performed to prevent the risk from occurring

Confidence Vote

After the risk identification session, each team signals its confidence in meeting PI Objectives by voting in a “fist of five” format.  Any votes less than 3 will warrant further discussion and a rework of the plan.

PI Retrospective

One of the closing steps in a PI Planning event is that the Release Train Engineer (RTE) moderates a brief retrospective to identify what worked well the past two days, what didn’t work well, and what can be improved upon the next PI Planning meeting.

Big-Room Planning Artifacts with Trello Power-ups

Power-ups allow Trello to link with other tools. This may be needed to extend the functionality of Trello cards, allowing them to link to Jira issues, to create card hierarchies, or other added functionality.

Let’s take a look at a few PI Planning artifacts that will use Trello power-ups for added functionality.

Team PI Objectives

Here, PI Objectives belong in one of two columns: (1) Committed, which indicates that the team will allocate capacity to meeting this objective, and has committed to it; (2) Stretch, where the team has allocated capacity, but makes no commitment on meeting the objective.  

Inside each PI Objective is where power-ups can make a difference. The heart of the PI Objective is the Business Value. There are two entries for Business Value for each PI Objective: the Initial value, set by the business stakeholders at PI Planning, and the Actual Business Value, determined by the business stakeholder after demonstration or actual deployment.  We use the Custom Fields power-up to define the two Business Values.

Each objective can also be linked to a Jira issue which is a feature that implements the objective.