Here at Miro, we set out on a mission to build a universal tool for visual collaboration that helps companies embrace digital transformation, manage remote teams and think visually in order to speed up internal processes and delight their customers.
That’s why we are always curious about the ways leading companies from around the world approach product development and the challenges they face while organizing their work in distributed teams. This use case about PI planning is based on the experience of our client, Bonial. We are grateful to Torben Voßgröne, the company’s Head of Product Engineering, for helping us create this post.
What is PI Planning?
Program Increment (PI) planning is a cadence-based, face-to-face event that helps align all the teams on the Agile Release Train (ART) to a shared mission and vision.
Why do you need PI Planning?
PI planning helps establish face-to-face communication among all team members and stakeholders; aligns development with business goals regarding the business context, vision, and team and program PI objectives; identifies dependencies; fosters cross-team and cross-ART collaboration; and, overall, helps companies be more productive.
“We started doing PI planning because we wanted everybody within the team to understand what all of the others were doing. At the moment, we’re doing it mainly on the product development level, but we’re planning to make it company-wide at some point, so the OKR system exists for the whole value stream,” says Torben.
How to run PI planning with your team
Usually, PI planning works best for bigger teams (more than 100 people). At Bonial, each PI usually lasts for six Sprints (or 12 weeks). The first five Sprints are Roadmap/Feature Sprints, and the sixth Sprint is for hardening/innovation/planning. To plan the next increment, the whole team usually gathers in the same room for several days or a week to go through the main steps of planning. “With PI Planning, we went from two days to a week, so we can discuss/plan every initiative in detail and there are fewer surprises during the PI. During the week everyone has a direct interest in initiating conversations and aligning everything together (dev/product/marketing/sales),” says Torben.
Bonial has 125 people across more than 15 teams, so physical boards and walls are simply too small. “When we still used stickies, we spent about 30 minutes getting all of them on the wall. It’s a waste of resources and time when about 30 people are in the room waiting for others to hang up their stickies,” explains Torben.
Bonial has around 25 remote team members, so it’s challenging to keep everyone on the same page. That’s why the company uses Miro – so they can do the planning in their office and be fully connected.
Here is how you can do PI planning in Miro, an online whiteboard for seamless collaboration within customer-centric companies.
Kicking off
As mentioned before, Bonial’s Program Increments are six Sprints long; the company plans five Sprints and leaves extra time for the developers to innovate.
Two weeks before the planning event, the business owners determine the objectives and key results (they can be outlined in Miro) for the whole business for the next Program Increment so the team leads can start adapting these objectives for their departments. Then Bonial schedules a planning week where things are split into time-granular tasks like Sprint items.
We typically stick to goals/objectives and not a planned feature or capability
After the OKRs for the different value streams are set, initiatives are prioritized by business owners, product and tech leads and architects. With this prioritized list of initiatives, it’s clear which team will need to work on which initiative and where the team needs to support a dependency.
During the planning week, there are sessions for each initiative, involving everyone with an interest in that initiative, so everyone can understand the mission/goal of the initiative and all needs are addressed. This leads to fewer questions and a better common understanding of the goal. “We typically stick to goals/objectives and not a planned feature or capability,” adds Torben.
At the end of the planning week, each initiative is broken down into major milestones (e.g. releases, learning milestones and deadlines) and estimated tasks/stories. On Thursday evening of the planning week, all initiatives have been groomed/estimated and understood by the Bonial teams. The teams use Friday to build a roadmap and outline dependencies, ending with a confidence vote about reaching the quarter’s goals.
“2018/Q1 was by far our most productive quarter since we started doing PI planning (3.5 times higher per-person productivity compared to 2015). This was a result of radical focus, clear expectations and teams being able to execute autonomously,” says Torben.
Outlining milestones
When the team is going into the Planning Ceremony, the priorities and initiatives are clear. “We ask the teams to break down the initiatives into milestones first, ordered by priority,” explains Torben.
Milestones can be:
deliverables/releases
learning milestones (e.g. analysis of a POC or MVP)
Hard deadlines (e.g. due to external events)
These milestones have scopes that make it easier to go into the story breakdown.
Using Miro, mark these milestones with a specific color to distinguish this type of content on the board (for the template above, Bonial uses blue post-its).
To further track milestones, you can also create a milestone chart.
Story breakdown
After the engineering and product team has defined the milestones and added the relevant scope, the team breaks down the tasks into stories. These are not the stories that would end up in the Sprints; these stories are much broader. However, they should at least fit into a Sprint and have a size that Bonial’s team can roughly estimate.
In Miro, the Bonial’s team uses yellow post-its for this story. Employees can now fill Sprint by Sprint by putting the stories into them. At this point, the Sprints don’t have to be packed to 100%.
Also the whole quarter is less a pipeline and more a forecast. “It’s important to remember that it’s not Waterfall. In the end, we stick to our initial goals rather than to the roadmap,” says Torben.
Bonial’s team also works with Spikes, a type of exploration that usually represents activities such as research, design, investigation, exploration, and prototyping. In Miro, the Bonial’s team uses green post-its for Spikes. “Sometimes we keep potential routes open at the end of the quarter,” adds Torben.
Outlining dependencies
When prioritizing the initiatives for each team, it becomes clear which initiatives teams need to work together on and where teams will have dependencies with other teams.
When we review the roadmap, we double-check that all dependencies are resolved/covered
During the PI planning event, when the roadmap is being compiled, dependencies are handed to other teams’ roadmaps so that the other team can make sure to plan accordingly to deliver the dependency in time. In Miro, the Bonial’s team uses pink post-its for dependencies.
“When we review the roadmap, we double-check that all dependencies are resolved/covered,” adds Torben.
He says that Bonial’s team found different solutions to resolve dependencies effectively, depending on the use case.
1. Embedded teams (e.g. DevOps, data) lend out their team members to join another team for a single quarter or constantly to resolve the dependency.
2. Task forces — a temporary team which can develop new features, so that all dependencies between systems are handled within this team (e.g. Mobile, Web, API, Data Science, and Engineering team can join forces to create a personalization algorithm).
3. Normal dependencies that are resolved by the teams individually. In this case, we like to resolve the integration point between depending systems in the very beginning of the quarter. For example, if a mobile client needs a new API endpoint, our teams agree on the request details, and then the API team hosts that endpoint early in the quarter.
4. When things are unclear, the team simply books enough time (Spike) to support the dependency.
Evaluating risks and confidences
During the planning process, the team collects risks and visualizes them with stickies on a canvas divided into four areas. At the end of the planning, all risks should be assessed. Risks can be accepted, solved, mitigated or owned.
Confidence votes happen on two levels during the planning process. “The initiatives we push to the roadmap have an OKR-like format. The key results are those that have at least a confidence of 5 out of 10,” says Torben.
At the end of the planning, the team votes about the confidence of the roadmap. “We do not commit to a roadmap. The confidence is the equivalent of that. If the vote is too low, we’d rather reduce the scope or accept it and do our best,” explains Torben.
Final review
“We used to call this step a ‘draft review’ when we had two-day planning sessions because we had the second day to make a final plan, but we got rid of it,” explains Torben. A one-week event is much more productive for Bonial, because at the end of the planning week, there is more time to get answers to the questions that arose when the team thought about the technical solution. It helps avoid having these questions arise later on and having to adjust.
After each team is done with the planning, they go to Miro to put the major stories into their Sprints and outline dependencies from other teams. “Usually, each Team Lead or Scrum Master presents the plan for five Sprints and dependencies in front of the whole company,” says Torben.
At the final review, all Team Leads or Scrum Masters are present, as well as business owners, product managers and the executive staff. Teams present their roadmap to the whole group, usually emphasizing the milestones and dependencies to be resolved. During that presentation, the Team Lead/SM outlines the team’s confidence in the plan. The business owners and executive staff accept the roadmap of each team or reject it. “This addresses the cases where the team had to decide if an initiative is not feasible for the quarter. Potentially the business owners want to see another prioritization of the resolution,” adds Torben.
Miro is perfect for this because the remote team can also participate in the Retro, and we don’t waste paper
PI retrospective (optional)
Using the Miro Retrospective template, the team sets up three things that they like about the current plan, three things that they dislike and three things that they would change in the future. “Miro is perfect for this because the remote team can also participate in the Retro, and we don’t waste paper,” remarks Torben. After the Retrospective, the team gathers the suggestions for improvement and votes for the ones they want to address.
Conclusion
When Bonial did their very first PI planning, the product team had around 70 potential initiatives for the roadmap and just four teams. “At that time, we were lucky if each team did one initiative per quarter due to various reasons; technical debt, trying to do too much at the same time, poor resolution of dependencies,” recounts Torben.
Now Bonial has about 12 teams planning their quarters in parallel. They can typically take on and finish three major initiatives per quarter. “Over the last three years, we increased our per-person productivity (measured by delivered business value and the total team size) by 3.5 times while doubling our team size. This resulted in a seven-times-higher velocity than what we had three years ago. Introducing PI planning was one piece of that puzzle. Miro helps a lot scaling that process while scaling the team,” concludes Torben.
About the authors
Bonial Labs is a company revolutionizing the way the world shops, from pushing the limits of location-based technologies to building the prototypes of tomorrow’s products.
Headquarters: Berlin, Germany
Founded: 2008
Team: Around 300 people
FOUNDERS: Christian Gaiser, Max Biller
