“The people who plan the work do the work” is the unwritten rule of the Scaled Agile Framework.
Yet, this can be easier said than done when we’re looking at multiple teams of people needing to plan together.
Add in the complexities of large enterprises that face their own unique challenges - ranging from product development to budget to implementing feedback to final delivery - and suddenly the idea of how to bring teams together for planning can feel harder again.
If you’re familiar with the Scaled Agile Framework, you will already be aware SAFe is designed to facilitate better collaboration and communication between multiple cross-functional groups. The core way to do this with SAFe is Program Increment or PI Planning (Planning Interval Planning in SAFe 6.0)
A plan can take on so many different forms - even just between teams - but with SAFe it is easier to see what ‘good’ looks like when it comes to efficient PI Planning.
The SAFe program board or ART planning board (SAFe 6.0), is a critical tool and output of PI Planning. It is a visual summary of features or goals, cross-team dependencies, and other factors that impact their delivery. Not only does this help with transparency, but it also increases flexibility that, in turn, helps minimize delays and unhealthy dependencies.
What is often overlooked is that PI Planning plays a crucial role in setting teams or the entire program up for success - including implementing other SAFe ceremonies or events.
In this article, we’ll discuss everything you need to know about program boards, including why they’re important in the planning process and how larger teams can use them in PI Planning and beyond.
We’ll also explore exactly how Easy Agile Programs digitises the SAFe program board, not only allowing the people who plan the work to do the work, but also allowing you to plan the work in the environment where the work gets done - in Jira.
NB: while the program board is referred to as 'ART Planning Board' in the updated 6.0 version of the Scaled Agile Framework, it is the same artefact and plays the same role in PI Planning and beyond.
What is a program board?
What does your teams plan or schedule typically look like?
Would it indicate to you what work was being done? Who was doing it? Perhaps even an indication of when they would and any key deadlines these teams are working towards?
The headline here is that a program board is all of this, but also more.
The program board is a visualization of the work being committed to during the Program Increment / Planning Interval or PI. It is simultaneously the facilitator of planning as well as the plan itself.
A typical idea of a program board - especially for collocated PI Planning sessions - is literally a physical board on a wall.
It would show:
- Columns: marking the iterations for the increment
- Rows: representing different teams within that increment
- Sticky notes: describing the features that teams are working on or used to indicate milestones that they’re working towards
- Strings: between these features to indicate if there are any dependencies
But how does a program board help the planning process?
A program board facilitates better team collaboration because it streamlines project communication and planning, while also ensuring better communication between the involved teams.
Moreover, program boards help define the responsibility of each team involved in making the idea a reality, which in turn, helps to streamline the process as a whole.
During PI Planning, the program board supports teams to visualize and manage dependencies across the PI; giving them greater clarity of the work in detail, how the work relates to what the business is trying to achieve and to each other, what tasks need to be done, and crucially, whether there are any issues that may cause delays.
A program board is simultaneously the facilitator of planning as well as the plan itself.
To understand how program boards help with the planning process, let’s go over the different components found on them.
How to set up your SAFe program board for successful PI planning
According to Scaled Agile, there are two primary outputs of PI Planning:
- Committed PI Objectives
- Program board - with new feature delivery dates, dependencies among teams and relevant Milestones
So if you’re following SAFe and doing PI Planning you should finish PI Planning with a program board.
During PI Planning, not only do teams discuss and define the features and dependencies, but they also establish milestones across the PI.
Here are a few tips to help you create a SAFe program board.
1. Setting up the board itself
Not to be underestimated, the bare bones of the program board need to be set up.
There are two key elements here:
- Sprint or iteration columns:
- The right number based on how many iterations/sprints will be in your PI, including a final one for iteration planning
- Rows or swimlanes:
- One for milestones/events - typically the first
- One for each team
- May also have a swimlane for shared services, suppliers or other teams not in the Agile Release Train (ART)
Here is what this may look like:
If you were at this stage of your program board in Easy Agile Programs, your board would look like this:
In Easy Agile Programs, each team represented in a dedicated swimlane represents an agile board in Jira. So the issues that you will be scheduling for this team in sprints during PI Planning and beyond, will be reflected on their agile board and vice versa.
The start and end date for the PI and the number and length of your sprints can all be edited to suit your organisation’s workflows.
When you are in editing mode and are ready to schedule features, the shared team features swimlane also appears at the top to visually indicate if there is work to be scheduled across multiple teams.
2. Start with features and milestones
During PI Planning, Product Management shares the product/solution vision and this commonly also means the next top 10 upcoming features for the teams to take into the PI from the backlog. (We know from our customers that sometimes this can be a lot more!)
We also want to start by knowing which milestones we are working towards. Often these can represent product release dates, external deliverables or deadlines like preparing a demo or showcase for a trade show, marketing launches or events. Having these visualized on the program board helps teams to easily see what they are working towards, but also to inform prioritization of the specific features needed to help meet delivery of that milestone.
If you are working with a physical or simple digital program board, features and Milestones are represented by ‘sticky notes’ - placed in the appropriate swimlane and/or colour to indicate this information as well as the team responsible for it and the time frame:
So what does this look like in Easy Agile Programs at this point?
Milestones are highly visual
- Milestones can be customised to indicate start/end date and colour. They run across all team swimlanes so teams can easily see how their work relates to an upcoming deliverable or event.
- Milestones still have a dedicated place at the top of the program board but this can be collapsed if desired
Features are native Jira issues
- Features in Easy Agile Programs are native Jira issues, commonly epics. You can easily click on the issue key from the program board to see more information via the issue view.
- Features can be easily scheduled from the backlog into a swimlane through drag and drop, or created via the program board. To indicate when a feature is intended to start and be completed, simply drag and drop the edge of the issue:
Join a product tour to walk through Easy Agile Programs
Want to bring your Program Board into Jira?
3. Identify dependencies
With the features done, the next thing that teams should look for is dependencies. Remember the strings we mentioned before?
Dependencies between features and teams are represented with string on a program board when it’s on a wall or lines between those features in a digital tool.
Sticky notes in a different colour, like red, indicate a significant dependency. For example that feature may have more than one feature relying on it to go to schedule.
To explain this, let’s consider an example.
Imagine Team X realizes they cannot develop a feature until Team Y develops an API thanks to the program board. So, what both teams can do is talk to each other and come up with a solution that works for everybody, leading to better collaboration among the teams.
After an agreement is reached, a dependency will then be placed on the board so everyone has the same understanding about the dependency, and how it’ll be resolved. A piece of string will be attached to each card to demonstrate this:
The nature of dependencies mean that something is required to be completed in order for something else to be done.
To be able to more easily see when dependencies are scheduled, Easy Agile Programs has a traffic light system of red, orange and green dependencies to indicate dependency health.
Dependency health is represented as follows:
- A red line indicates the dependant issue is scheduled in a sprint after the dependency (conflict)
- An orange line indicates the dependant and dependency are scheduled in the same sprint (a risk)
- A green line indicates the dependant issue is scheduled in a sprint before its dependency (healthy)
- A black line indicates the dependency exists with issues outside of the current view. Whether this is the current Agile Release Train / Program, or with a future or past increment.
This easily indicates to a Release Train Engineer or a Program Manager where they ought to focus and to be able to address any scheduling issues during planning.
Easy Agile Programs also allows you to visualize dependencies between issues within and across teams from the Team Planning Board. This provides a really focussed view of the work for a particular team for the PI, and how that work relates to other teams:
Program boards are needed for better collaboration
The power of the program board lies in having a single view of what a collection of teams are committing to - together - and exactly how that work relates to each other. It helps organize planning sessions by summarizing future dependencies across all teams and sprints. As a result, scrum masters, release train engineers, product managers and business owners can easily identify and prioritize cross-team conversations that matter the most.
Running a scaled planning session or PI Planning ceremony, especially for the first time, can be daunting.
But if you’re successful in developing a solid program board as part of your PI planning process, you won't have to worry about chasing down your co-worker or team member to meet deadlines. The key here is to make sure you’ve scheduled the most important features to take into the PI, identified cross-team dependencies, and have visualised any milestones or deadlines to ensure they can be realistically achieved.
The program board can become more impactful though, when it is more than just a plan. Building a program board in an online tool with the added capability of it representing the actual work that’s planned to be done means that it has a life beyond PI Planning; it becomes the living document of the teams progress and a means to identify when there are any blockers to that progress.
In order for agile teams to be agile and continuously and iteratively deliver value, they need to be equipped with a program board that can help them respond to any changes so that they can plan for success but also progress towards it.