SAFe Program Board 101: Everything You Need To Know
“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.
This is where a digitised PI Planning tool can really benefit remote or hybrid teams doing PI Planning - the same information is planned in the same place.
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.
Ready to take your Program Board off the wall and into Jira?
You can with Easy Agile Programs
Related Articles
Agile Best PracticeA straightforward guide to building smart PI objectives
Do your teams have a clear understanding of what needs to be done – and why?
One of the keys to being agile is to focus on the work that matters. This means working on projects that add value to the business and contribute to performance. But for many organizations, teams can get caught up on the latest feature or development, without understanding how that relates to the bigger picture of what the business cares about.
To keep your team focused on what they have set out to achieve in order to deliver value and achieve business outcomes, setting smart PI Objectives is essential. We look at why they’re so important, what makes a good PI objective, and how you can use them in your organization.
At a glance:
- PI objectives help teams understand how what they’re doing matters to the business.
- Good PI objectives are SMART – specific, measurable, achievable, relevant and timebound.
- Linking features to PI objectives within the same tool makes it easier for teams and stakeholders to see how work is achieving business objectives.
What are PI objectives?
When an agile team gets together for a PI planning session, there are two key outputs:
- The Program Board (ART Planning Board in SAFe 6.0) covers big picture information such as features, dependencies between teams, and milestones. A feature is an agreed upon piece of work identified as being important to meeting business needs. For software development teams, this might be a new product feature. For marketing teams, it might be a website refresh or an advertising campaign.
- PI objectives link the scheduled features to broader business objectives and value. This helps align work that needs to be done with broader business goals. They are then broken down into committed and uncommitted objectives.
- Committed objectives are those the team is confident they can deliver within the Program Increment. These objectives have been committed by the team through a confidence vote.
- Uncommitted objectives are those the team have low confidence in delivering but can help to build a buffer into the PI. This is because while the outcome of these objectives may not be certain, they are included in the teams capacity and plan for the PI should capacity remain after delivering on committed objectives.
The benefits of having smart PI objectives
PI objectives link what teams are working on to what the business cares about. They create alignment with business objectives by clearly connecting features to business value. As a result, teams know how their work is adding value.
Smart PI objectives provide a framework for this. They help build trust, create a shared language, and provide a clear direction. Everyone in the team can then understand what they’re doing, why they’re doing it, and why it’s important.
Without smart PI objectives in place, teams can spend time on tasks that aren’t adding value to the business and impact agility.
PI objectives are essential to your ability to measure success. Completing features alone isn't enough - they must drive a business outcome. They help get teams clear on why the work they do matters and define what success looks like.
What makes a good PI objective?
We’ve talked about why PI objectives are so critical, and now we’ll explain what makes a good PI objective.
Good PI objectives:
- Allow the business to see deliverables in a set timeframe
- Provide clarity on how scheduled work fits into the big picture
- Enhance communication between teams and stakeholders
- Include no more than 7 to 10 objectives in total
- Aligns with what the business cares about
- Are clear on why it’s important and what it will deliver
- Are understood by anyone who picks them up
Are SMART – that is, specific, measurable, achievable, relevant and timebound
PI objectives need to be SMART
Using the SMART goal-setting framework to write your PI objectives helps keep your objectives clear and concise. Under this framework, your PI objective needs to be:
- Specific – Clearly and explicitly state the intended outcome of your objective.
- Measurable – Describe what your team needs to do to achieve the objective and how they will quantify success. Stakeholder feedback should form part of this.
- Achievable – Ensure the objective is realistic and within your team’s control and influence.
- Relevant – Align the objective with overall business objectives.
- Timebound – Set an appropriate timeframe to achieve the objective within the PI.
Team PI objectiveEnsure Easy Agile server customers have a seamless option to migrate to cloud by implementing JCMA and site import/export by the end of Q3.
Tips for writing SMART (and smart) PI objectives
Typically, many teams will run PI planning sessions in one tool, and then use another tool (like Confluence) to record PI objectives.
But separating PI objectives from the planning sessions makes it hard for the team and stakeholders to see how the work is shifting the dial for the business.
With the Easy Agile Programs, you can directly link your features to your objectives within the same tool. You're also able to describe the objective within Easy Agile Programs and assign business value:
By connecting features to PI objectives within the same tool, teams and business stakeholders gain clear visibility of work. They can see how their work is helping to achieve business objectives.
Learn more
Using the SMART framework to define PI objectives helps your teams focus on the right work. They align projects with broader business goals while providing a shared understanding across teams. By working towards the same purpose, they help keep your teams and organization productive and agile.
You can with Easy Agile Programs
Ready to bring your PI Objectives into Jira?
WorkflowThe Ultimate Agile Sprint Planning Guide [2023]
How do you feel when someone mentions “planning”? Do you look forward to the opportunity or does the thought of making a plan send you running for the hills?
Sprint planning is a crucial part of the agile sprint cycle. It helps you and your team align around common goals, and sets you up for a successful sprint. Even if planning isn’t one of your strengths, the good news is that you can practice and get better over time with the help of some good advice.
We’ve combined our best sprint planning tips into an ultimate guide to agile sprint planning, with everything you need to run efficient and effective planning meetings.
What is agile sprint planning?
Agile sprint planning is a key ceremony in the agile sprint cycle. It signifies and prepares the team for the start of the sprint. Without this planning, there is a very real risk that the team would lack focus and fail to align on what is most important.
Effective agile sprint planning has three key parts; a sprint goal, an understanding of team capacity, and a prioritized set of backlog items. Each element depends on the other for success.
The idea is to align your team around a goal for the next sprint by agreeing on a set of backlog items that are achievable within the sprint and contribute to reaching the sprint goal. Gaining focus and clarity on what you plan to achieve will help your team to work better together and to deliver on objectives.
It is best to start with an agreed sprint goal. You can then prioritize work on the specific set of backlog items that your team has the capacity to complete, and that will contribute to making your sprint goal a reality.
How sprint planning fits within the Scrum process
We’re big fans of the Scrum process, and it’s hugely popular with many software development teams. While agile sprint planning can take many forms within the different agile methodologies, for the purposes of this guide, we’ll focus on agile sprint planning within the Scrum framework.
If your team doesn’t follow Scrum don’t worry — you’ll still find value in our preparation tips, meeting guide, mistakes to avoid, and sprint planning resources.
💡 Learn more: What's the Difference Between Kanban vs. Scrum?
Scrum roles: The people
There are three main roles within a Scrum team.
- Product Owner
- Scrum Master
- Development team
The Product Owner puts in the work upfront. They help prioritize the product backlog items and decide which should move to the sprint backlog. These important decisions guide the goals of the sprint and determine the tasks the team will tackle over the next sprint.
The Scrum Master acts as a guide, they lead meetings that help ensure that the Scrum framework is followed throughout the sprint to keep the team on track. The Scrum Master helps the team get the most out of the entire Scrum process and each individual Scrum ceremony.
The development team is made up of the various people who will complete the work agreed upon during sprint planning.
There are others that you might refer to during sprint planning, such as stakeholders, users, and customers. While these aren’t technically Scrum roles, they play a critical role in product development. Stakeholders should be brought into the process early and often, and customers should always be top-of-mind when making any development decisions. Some teams find User Personas to be a valuable way of keeping user value in focus.
Artifacts: What gets done
Artifacts are the things to get done — different breakdowns of what the team hopes to accomplish:
- Product backlog
- Sprint backlog
- Increments
Product backlog items are the tasks the team believes they need to accomplish in order to complete a product or specific improvement of a product. It is the big master list of everything that the team thinks they need to accomplish. The product backlog is flexible and iterative, and it will evolve as the team learns more about the product, stakeholder feedback, and customer needs.
The sprint backlog is more focused than the product backlog. The product owner moves the most important backlog items from the product backlog to the sprint backlog at the beginning of each sprint based on current issues, priorities, and customer needs. The team aims to complete all of the sprint backlog items over the course of the sprint.
An increment is a concrete stepping stone toward reaching the Product Goal. An increment must be verified as usable in order to provide value, which means that any work completed cannot be considered part of an increment unless it meets the Definition of Done (an agreement among the team of what “done” means). This is a formal description of the state of the increment when it meets the quality standards required of a product. Once the work completed satisfies the agreed Definition of Done, you gain an increment.
Scrum ceremonies: Where Sprint Planning fits
There are a number of ceremonies in Scrum that occur each sprint. This is where sprint planning fits within the Scrum process.
- Sprint planning
- Daily scrum (or standup)
- Sprint review
- Sprint retrospective
💡 Learn more: Agile Ceremonies: Your Guide to the Four Stages
Sprint planning is the first Scrum ceremony — it prepares the team for the sprint. The planning session sets everything into motion, aligning the team on what’s most important for this sprint. This is when decisions are made and key backlog items are moved from the product backlog to the sprint backlog.
The second ceremony repeats every day of the sprint. Daily standups bring the team together to discuss progress and blockers that might be getting in the way. By getting the concerns out in the open early, the team can avoid the frustration of delays and ensure work continues to flow.
The final two ceremonies happen at the end of the sprint. For the sprint review, the team comes together to determine the success of the sprint based on the “Done” work completed. It’s also a chance to bring in stakeholders to gather feedback on what's been accomplished so far. The sprint review ensures customer insights are always top-of-mind, stakeholders continually see progress, and guarantees the product never strays too far from what the stakeholders are looking for.
The sprint retrospective gathers critical insights from team members about how the sprint went. What went well, what didn’t go so well, and what could be improved upon for next time? These valuable insights are what makes Scrum agile — the team is always thinking critically about the process and looking for ways to improve the work and how they work together.
We’ll talk about these ceremonies in more detail below when we discuss what happens after the sprint planning meeting.
The benefits of agile sprint planning
Agile sprint planning is a powerful meeting that should not be overlooked or underestimated. It is an opportunity to:
- Bring the whole team together and align around common goals
- Set context by starting the sprint with clear priorities
- Identify potential roadblocks before they occur
- Bring stakeholder feedback into the planning process
- Learn from previous sprints by considering sprint review and retrospective insights
- Consider team capacity and adjust accordingly to ensure that goals are achievable and that the team isn’t overcommitted in the upcoming sprint
- Account and plan for dependencies that may impact the flow of work.
How to prepare for a sprint planning meeting
We know we said that a sprint begins with sprint planning, but there are actually a few important steps you must take in order to prepare for the planning session. Unfortunately, you do need to do a little planning for the planning meeting.
Backlog refinement
Backlog grooming or refinement keeps your backlog healthy, up-to-date, and ready for sprint planning. A refined backlog will help ensure your team’s planning time is used efficiently and effectively since you won't have to waste time adding details to the backlog that could have been completed in advance before everyone came together.
The product manager should groom the backlog a few days before the sprint planning meeting to make sure it’s ready.
Tips for maintaining a healthy backlog:
- Ensure stories are in order of priority
- Prioritize items that bring the customer the most value
- Add detail to the highest-priority backlog items
- Split any user stories that are too big
- Delete any user stories that aren’t relevant anymore
- Create new user stories based on new or clearer needs
- Add items based on new stakeholder feedback
- Make adjustments based on bug fixes
- Assign more accurate estimates
💡 Learn more: Essential Checklist for Effective Backlog Refinement (and What To Avoid)
Be consistent
A consistent meeting time that’s scheduled well in advance will ensure that the entire Scrum team keeps the time slot open. Book your sprint planning meeting on the same day and at the same time every sprint so that no one forgets or double books.
Sprint planning is not a meeting to be shuffled around, delayed, or ignored — sprint planning meetings are essential to the success of every sprint. Ask your team about a specific, recurring time to meet, and ensure it works for everyone.
How to run a sprint planning meeting
While the agile method is flexible and collaborative, it isn’t chaotic; everything needs to begin with a plan.
1. Stick to a set sprint planning meeting duration
As with any kind of meeting, the team can be easily sidetracked without a timebox. After all, talking about the work that needs to be completed is often easier than actually completing it. It’s the Scrum Master’s job to keep the team on track and make sure the time limit isn’t exceeded.
Go into the sprint planning meeting well-prepared; a clear agenda and a well-refined backlog mean your team can get straight to planning.
Set a realistic timebox for the meeting and stick to it. We recommend that you avoid scheduling more than 2-3 hours for a sprint planning meeting, but as you become more skilled in sprint planning, you’ll better understand the length of time that works for you and your team.
2. Use estimates to make realistic decisions
You want your team to be as productive as possible, but overloading them can actually hinder productivity and focus. Unreasonable expectations are demotivating and overcommitted team members are more likely to make mistakes.
You need to understand the effort and time it will take to complete the goals you set out to accomplish for each sprint. Agile estimation techniques and story points provide a better understanding of team capacity, individual capacity, and what a reasonable workload looks like. Reasonable and realistic goals will help your team stay motivated and support a consistent flow of work.
3. Define clear goals and outcomes
What does the team aim to accomplish between now and the end of the sprint? Set clearly defined goals and outcomes that everyone understands. Do your goals align with what you learned from past sprints? Do they align with customer needs? Does everyone agree on what the next sprint will (roughly) look like?
Don’t assume that everyone is on the same page. Ask questions and encourage your team to speak up if anything is unclear. It’s better to clear up discrepancies or misunderstandings now rather than once the work begins.
Post your sprint goal somewhere that is easily accessible so that the team can refer back to it throughout the sprint.
💡 Learn more: How to Make the Most of Your Sprint Goals
4. Decide what it means to be ‘done’
What does “done” mean for any given backlog item, increment, product issue, or product as a whole? The team and your stakeholders need to agree on what done looks like in order to set realistic goals that meet the expectations of everyone involved.
As you set goals and choose which backlog items to complete for the next sprint, be clear about what it means to meet and complete the goals you want to accomplish.
5. Align sprint goals with product goals
Sprint goals should always align with your broader product goals. Your sprint may take a specific direction depending on current product issues, bug fixes, or customer concerns, but it’s important to keep an eye on the big picture.
Choose backlog items with care — make sure they relate to the larger product goal and that each works in sync to move development forward. Overlooking product goals in sprint planning could mean that each sprint looks more like a random selection of to-do lists that don’t connect back to customer needs, relate to product goals, or help you reach important increments. The result will feel like a lack of progress, which risks disengaging the team and other important stakeholders, like your users.
What happens next?
Now that the planning is done, you’re ready to implement your plan and complete the work. But that doesn’t mean that team members go off and work in isolation.
Daily scrum (or stand-up)
The daily scrum or stand-up is an opportunity for a collaborative agile team to maintain progress. It should be a quick check-in at the start of each day.
The team will discuss what has been done in the past 24 hours, any roadblocks they might have hit, and what the team hopes to accomplish the next day.
This critical check-in helps the team stay on the same page, helps to ensure the continued flow of work, and keeps the team on track to achieve sprint goals.
Sprint review
A sprint review meeting takes place at the end of a sprint. It's a chance for the team to review all of the “Done” issues for that period. The sprint review determines whether or not the goal for the sprint was achieved.
It’s a chance to demonstrate shippable working product increments to the team, and also an opportunity to bring in stakeholder feedback. This feedback gives you valuable insights to assess if you’re on the right track, or need to make changes in the next sprint. The sprint review is also excellent preparation for the next backlog grooming and sprint planning session.
💡 Learn more: Introduction to Sprint Reviews
Sprint retrospective
While the sprint review looks at what was accomplished and how to move forward, the retrospective examines your processes and how the team is working together.
What did you learn during the previous sprint? While retrospectives can take many forms, the goal is to discover what worked well, what didn't go so well, and what could be improved upon next time. Your team will use the insights gathered in the retrospective to improve how you work together and deliver value to customers in the future.
💡 Learn more: 5 Steps to Holding Effective Sprint Retrospectives
Agile sprint planning mistakes
It’s easy to fall into bad habits, especially as deadlines and product launch dates approach. Avoid these common agile planning mistakes to ensure your team is always making the most of the agile methodology and the Scrum process.
Unrealistic expectations
Choosing unattainable goals sets your whole team up for failure. Failing to meet your sprint goals sprint after sprint is damaging for team motivation and morale.
Use estimates to set reasonable goals as best you can. Consider team capacity, factoring in your past knowledge of how long tasks take to complete, how the team works, and potential roadblocks that could arise along the way.
Lack of context
Your team will benefit from an understanding of how the issues they’re working on fit into the bigger picture.
Depending on the tool you’re using to plan and manage your work, it can be difficult to see the contextual detail needed to plan and work with clarity. The more items you have, the more difficult and overwhelming it will be to organize and prioritize. Use tools that allow you to add context, depth, and customer insights with clean functionality to adapt your plan to the needs of your team and stakeholders.
Neglecting your backlog
We mentioned this point when we talked about what you need to do to prepare for sprint planning. It’s worth mentioning again because it’s a common mistake.
When you go into a sprint planning meeting without a well-managed backlog, you lack the clarity you need to plan effectively. Your time is valuable, and so is the time of your team, so it should be treated with care and used effectively.
A well-managed backlog is DEEP:
- Detailed appropriately
- Estimated
- Emergent
- Prioritized
💡 Learn more: The 4 Characteristics of a Good Product Backlog
Not allowing the plan to adapt
When you plan your sprint, you’ll do everything you can to prioritize the most important tasks for the length of the sprint. It’s important to try to stick to the plan as best you can, but you also need to adapt as you acquire new information.
Be ready to make changes on the fly should you hit roadblocks or acquire new information about customer needs, concerns, or product issues.
Failing to understand stakeholders
You need to understand the goals and priorities of stakeholders to be successful. Just because you’re happy with what you’ve accomplished doesn't mean your stakeholders will too.
Ensure your stakeholders are brought into your process early and often and help them understand how you work to provide them value. Gather feedback from stakeholders regularly to ensure your goals are aligned. A good time for this is during the sprint review. Just make sure those insights are transferred over to your next planning meeting.
Not choosing tools with a customer-centric approach
Successful product development delivers what the customer needs and wants. To build for your customers, it helps to use tools for planning and work management that makes it easy to keep them top-of-mind. Incorporating user story maps and customer personas into your planning helps you and your team prioritize the work that will deliver the most value first.
💡 Learn more: 10 tips for more effective user personas
Failing to incorporate retrospective insights into planning
Retrospectives are the best thing you can do to help your team work better together. During a retrospective, you're asking your team to be open and honest about how things went over the course of the sprint so that you can learn from each other.
Failing to learn from those insights means that the collective time spent in the retrospective has been wasted, and the feedback that your team has shared is devalued.
Incorporating the learnings you gain from a retrospective into your next planning session and into the next sprint, will support your team to improve every time, helping them gain work satisfaction and deliver better outcomes.
Virtual vs. in-person sprint planning
The advantages of remote work also bring challenges for collaborative planning. No matter the way your team chooses to meet, whether virtually, in person, or a combination of both, it’s important that you choose tools that meet the needs of your team.
Tips for virtual sprint planning:
- Be really prepared - communicate plans clearly ahead of time, so that everyone has clear expectations.
- Use a video conferencing tool that allows for breakout sessions
- Set up the interactive online resources you plan to use and include links in the meeting request.
- Online discussions don’t start as naturally as they would in person, so share discussion topics ahead of time, and consider preparing some ice-breakers.
- Ensure that you’ve accounted for time differences for teams that span time zones.
- Tech issues arise no matter how much advanced planning and testing you do. Always expect the unexpected.
Tips for in-person sprint planning:
- Book a meeting room with plenty of space for your team, and consider separate spaces for breakout sessions.
- Ensure that your meeting room will accommodate a shared view of your sprint plan - do you need a wall for sticky notes, or a screen to share a digital tool?
- If some of your team members work remotely, it’s difficult to involve them in the same way, so consider how this might work for your team. They won’t be able to read a whiteboard or sticky notes as easily, so a digital solution may be best.
- If you choose to plan your sprint ‘on the wall’, be sure to nominate someone to transcribe your plan into your work management tool at the end of the planning meeting.
No matter where your planning takes place, always remember to prepare your backlog ahead of time so that you can have focused and informed discussions during sprint planning.
Additional agile resources
We’re continually adding to our content library, which is filled with resources, how-to guides, product updates, and more.
📚 Add these to your list:
- Easy Agile Podcast Ep.20: The importance of the Team Retrospective
- Easy Agile Podcast Ep.18 Top qualities of an agile leader and team
- Easy Agile Podcast Ep.16 Enabling high performing agile teams with Adaptavist
- Being agile vs doing agile
- The Ultimate Guide to User Story Mapping
- The Ultimate Guide to Buyer Personas
- The Ultimate Guide to PI Planning [2022 SAFe Edition]
Using Easy Agile to improve sprint planning
Make your sprint planning smooth and effective with Easy Agile TeamRhythm. Transform your flat product backlog into a dynamic, flexible, and visual representation of the work to be done. Seamlessly integrated with Jira, with TeamRhythm you can:
- View your Jira stories, tasks, and bugs in context, aligned beneath their epics on the story map
- Drag and drop Jira issues from the backlog into a sprint
- Create new issues right on the story map
- Estimate issues on the story map, and gauge capacity with story point totals in each sprint swimlane
- Publish the sprint goal on each sprint swimlane, so it’s always top of mind
- Use filters to focus on the stories and issues that are most important now
- Group epics by a third level of hierarchy, to easily see how the work in focus contributes to the bigger picture
Easy Agile TeamRhythm also supports team retrospectives, with flexible and intuitive retrospectives boards created for every sprint. You can add retrospective items right from the sprint swimlane, so you don’t forget any important points. And you can turn retrospective action items into Jira issues that can be scheduled for future sprints, so you’re always getting better at what you do, and delivering for your customers.
Thanks for reading our ultimate agile sprint planning guide! If you have any questions about this guide, our other content, or our products, reach out to our team at any time. We love hearing from you.
We’ll continue to update this guide as we gain more agile planning insights, techniques, tools, and best practices.
WorkflowFrom surviving to thriving: remote PI Planning with Easy Agile Programs
The most efficient and effective method of conveying information to and within a development team is face-to-face conversations.
Agile Manifesto, 2001
As true as this statement was when it was written, the Covid-19 pandemic irrevocably changed the way we work, live and communicate.
As organisations and individuals we found ourselves quickly needing to adapt to an ever-changing environment. Now that we have survived, we have to lean into this new way of doing things in the workplace so that we can thrive.
But what about our agile ceremonies?
One of the main reasons companies transition to agile is to make business processes and outcomes more efficient. So how do we take those principles and practices and preserve their integrity in a remote environment?
If you’re familiar with the Scaled Agile Framework, you’ll know that PI Planning is an agile ceremony that is at the heart of implementing SAFe.
Traditionally a face-to-face event, PI Planning is a scaled cross-team planning ceremony that aims to bring together multiple teams to plan - aligning them around a shared mission and vision for the upcoming quarter or increment.
SAFe still advises that PI Planning is still collocated where possible, and it does have its benefits.
However many teams, even before the pandemic, used PI Planning software to run their planning process and to make it more efficient and accessible to distributed PI Planning. But as with most things we have taken online since Covid, we are at the mercy of the tools we use to determine how effective we can be.
The truth is, unless you can get all members within an Agile Release Train - Business Owners, stakeholders, product management, Release Train Engineers, Scrum Masters, and teams - physically in the one room at the one time, considering alternatives is necessary.
It’s important that everyone is present during PI Planning, but that doesn’t mean they have to be physically present to make PI Planning a success
Remote PI Planning with Easy Agile Programs
We are now beyond the period where we needed to adapt to remote work. Our own business agility has been tested and we have needed to evolve.
Since we first launched Easy Agile Programs, we have continued to build on the capabilities it has to help teams and organizations around the world thrive in a remote environment.
With a simple but powerful tool seamlessly integrated with Jira, the latest version of Easy Agile Programs has a range of features aimed at helping distributed teams through the PI Planning ceremony and to build out a long-lived but flexible digital Program board in Jira.
Moving to remote or hybrid PI Planning doesn’t need to jeopardize yours or your customer’s success. In fact with the right tool, it can enhance it by saving time on context switching, complex configurations and double-handling.
The PI Planning Agenda
Regardless of whether you are following a more traditional 2-day PI Planning agenda, or need to accommodate a split agenda in a distributed environment, the core agenda items are the same. We’ll walk you through each of those and how Easy Agile Programs supports these key features.
Source: Scaled Agile
Setting the business context
PI Planning kicks off with the Business Owner(s) or senior executives giving a presentation where they describe “the current state of the business, share the Portfolio Vision, and present perspective on how effectively existing solutions are addressing customer needs” (Scaled Agile - PI Planning).
In the Program details section of Easy Agile Programs, Business Owners can share a recorded video presentation with all members of the ART, or a Zoom or video conferencing link.
As a result, the presentation isn’t restricted to team members being physically present for this agenda item, and can be referred to throughout the PI Planning session and beyond.
Setting the Product/Solution Vision
Next in the agenda, Product Management will present the current vision, typically in the form of the top 10 upcoming features.
Rather than presenting the top 10 features in a list on a slide or document, Program Managers can access Jira Features (Epics) right within Easy Agile Programs and can schedule them onto a visual timeline for the duration of the Program Increment (PI).
The Program Roadmap ensures all teams are aligned on the committed features for a PI and provides visibility into the direction of the Program for all stakeholders.
It’s at this point in the PI Planning ceremony that Product Managers may also call out any upcoming milestones.According to Scaled Agile, ‘Milestones mark specific points on the development timeline, and they can be invaluable in measuring and monitoring the product evolution and risk.’
Easy Agile Programs enable you to create highly visible milestones on the Program Roadmap to highlight key delivery dates, external events, or business milestones. These can also be created on the Program Board, or at the team level on the Team Planning Board. They are represented by colored flags at the top of the Roadmap that spans the team swimlanes that make up the Program.
Team Breakout Sessions
In the team breakout, teams work individually to estimate the capacity for each Sprint in the PI. Teams create new or identify existing issues from their backlog that will help achieve the set features. The draft team plans are visible to all members of the ART.
To make this easier, Easy Agile Programs has dedicated Team Planning Boards accessible to all who have access to the Program. Simply clicking on a team’s name will take you to their team Planning Board where they are able to set capacity for each sprint within the PI:
Teams have the context of their committed features at the top of their Team Planning Board, both those that are shared by more than one team in the ART or are specific to their team.
To plan the work needed to achieve these features, teams are able to drag and drop existing issues from their backlog or quick create new issues right within the planning board.
During this session, teams also create draft PI Objectives. These are a critical part of linking what the team is working on to broader business objectives, and you don’t need to leave the Team Planning Board to create them.
In Easy Agile Programs you can indicate whether the objective is committed or uncommitted, provide a description, and directly link the Jira issues scheduled to achieve this objective with the objective itself:
During PI Planning, Business Owners will have a discussion with teams about their PI Objectives which provides an invaluable opportunity to align. The Team Planning provides the artefact to facilitate those conversations, and allows Business Owners or stakeholders to assign a business value directly within the tool.
An important part of the team breakout sessions is identifying any dependencies or potential risks to scheduling work. Through drag and drop or create dependencies mode, it is very easy to create and visualize dependencies across teams in the Team Planning Board.
Aside from highly visible dependency lines, our customers also appreciate being able to see the health of those dependencies. If a dependency line is green it means the dependency is healthy, if it’s orange it is at risk, and if it is red it means we are blocked i.e. the work needed to be done to achieve an earlier piece of work is scheduled after it.
And the best bit of all? This is visible to all in the ART in a digitized SAFe Program Board.
On the Program Board, we have the option to have a detailed view with team-level issues visible or to hide them so we can just see features.
Wondering whether Easy Agile Programs could support your organization's PI Planning? With a seamless Jira integration, it takes minutes to set up.
Free trial of Easy Agile Programs
Program Risks
During PI Planning, we need to be able to identify risks and dependencies to assess whether teams in the Agile Release Train are set up for success to reach their PI Objectives.
A digital Program Board provides transparency to all members of the ART during PI Planning and acts as a single source of truth during and beyond planning. A digital artefact enables the Program Board to become more than a plan, and lives longer than the strings and post-it notes on a physical wall.
We know that visualizing feature-level dependencies is crucial to not only understanding but also troubleshooting the health or status of a PI. Not just during PI Planning itself, but also throughout the PI during execution.
The Program Board in Easy Agile Programs is highly visual and also filterable. Colored lines that indicate the health of the dependency ensure we have an at-a-glance view of significant dependencies that pose a risk to our PI.
Additionally, our scheduling conflicts feature surfaces when there is work scheduled outside of its associated feature, to immediately and clearly indicate where there is a risk.
The ability to filter by dependency health and team in Easy Agile Programs helps to focus conversations around risks during PI Planning.
Plan rework
After presenting plans to the ART and discussing scope, cross-team dependencies, required resources, and risks, teams then proceed to a confidence vote.
If needed, a closing part of planning is to rework any plans so that all teams within the Agile Release Train are confident in what they are committing to.
This may involve rescheduling to address dependencies, breaking work down further, adjusting estimations, etc.
Reworking is simple and streamlined within Easy Agile Programs. The ability to inline edit issue estimates and summaries in real time makes any rework fast and simple. Dragging and dropping an issue easily reschedules it and any impact on associated dependencies can be seen all at once.
All changes made to issues in Easy Agile Programs are automatically reflected in Jira.
Find out how Easy Agile Programs can make PI Planning easy for your collocated, hybrid or remote teams.
Join a product tour to walk through Easy Agile Programs
What about beyond planning?
We’ve examined the merits of remote PI Planning using a digital tool like Easy Agile Programs but something that so often gets overlooked is - what happens after planning?
A plan remains just that if it’s not translated into action. A plan isn’t made not to be fulfilled, and this is where a distributed or hybrid environment can be challenging.
Your Program Board may set you up for success, but ask yourself - how will you know if you’re on track to achieve it?
This is where having a digital, user-friendly tool that uses native Jira issues helps. At the end of PI Planning, teams have created a plan in the form of a Program Board in Jira, but they are also ready for sprint one as soon as PI Planning is done.
From there, the Program Board is set up and capable of evolving, not rolled up and stored away. This is what Easy Agile Programs is designed to do - to provide transparency but also flexibility so that the plan can necessarily adapt and be agile while maintaining momentum towards progress.So what’s up next for Easy Agile Programs? Can you help us improve it? Check out our product roadmap and if there is something missing let us know.