To meet business goals, a software team’s daily work needs to align with an organization’s strategy. Eric Hilfer, VP of Software Engineering at Rosetta Stone®, believes that “one of the myths about agile is that you deal with what you have right on your plate and you don’t make a plan, and that’s not actually true”.

Agile software development supports a release plan, but it’s challenging to coordinate that on a multi-team level when you’ve got a lot of dependencies between teams.

Rosetta Stone®, a language learning technology company, found a solution to this challenge by bringing their entire development organization together about once per quarter to map out 10 to 12 weeks of work. And last week, I was lucky enough to watch how they do this at their 5th program increment planning (dubbed “PI5”). Read on to see how it went.

But first, what’s a program increment? A program increment (PI) is a quarterly plan that aggregates multiple teams and their work for a 10-12 week period. Program increment planning is the face-to-face event that plans out the next increment. It has a standardized agenda that includes a presentation of business context and vision, followed by team planning breakouts wherein the teams create the plans for the upcoming program increment. Facilitated by the release train engineer, attendees include all members of the agile release train – a group of agile teams that plans, commits and executes together. The end result is a commitment to an agreed set of program increment objectives.

Day 1: set context for the roadmap

Day 1 started with vision presentations, where organizational goals and milestones are shared with the entire group (80 people across 15 teams from 6 offices), to ensure everyone starts off on the same page. These presentations included the current state of the business, overall program vision, strategic themes and goals, and the top 10 milestones to be accomplished in the coming quarter.

Eric said the “primary challenge in working with multiple teams is to make sure that they’re working on the right work, at the right time, and that they understand how the work fits together” so the first day is used to set that context. While day one was heavy in presentations, it was important for all of the teams to really understand what their work would be contributing towards and is crucial for any type of agile planning meeting.

Alignment between development goals and business strategy is extremely important. –Eric Hilfer, VP of Software Engineering at Rosetta Stone

How to decide on the top 10 milestones for the next quarter:  Rosetta Stone® has an ‘epic kanban board’ with all the epics that can be done across the agile release train. This kanban board has the following workflow: Funnel > Review > Analysis > Backlog > Implementing > Done. About 1 month prior to PI Planning, the product owners move all their epics that might be done in the next PI from “Review” to “Analysis” and the teams estimate them. After that, Chris (Head of Product Management) and Peter (the CPO) use this information to craft a set of objectives that they take to the executive steering committee as a proposed set of work and outcomes. After discussion, priorities might shift and epics moved around, but a set of “milestones” is established and brought to the PI planning meeting.

Day 2: teams make their plans

On day two, everyone broke out into their teams to tackle day two’s agenda: elaborate, prioritize, sequence and estimate 5 sprints and then to identify, discuss, and document dependencies and risks. Eric said “these quarterly meetings are a fantastic time where the teams come together and interact directly.” The teams identify their dependencies and map those out, and they do a lot of anticipation. A good start for any team (and how the Rosetta Stone® teams start off day 2) is estimating velocity for the coming quarter – will anyone be on vacation? Are there any new hires to the team that will change velocity?

Use Portfolio for Jira to calculate future team velocity: Teams can pull this information from Portfolio for Jira, which pulls velocity straight from the teams’ agile boards and takes into account any absences or new hires in the team.

Next, the teams created draft plans, sprint by sprint and then sequenced the backlog items in the sprints until their capacity was full. This was done on the big program board (made from cardboard boxes, duct tape and A LOT of post-it notes) which Eric described as the “central artifact that has all of the teams represented on a line‑by‑line basis.” On this board, teams physically add post-it notes with features and epics, and map out dependencies using a red string.



The program board: A program board highlights new feature delivery dates, dependencies between teams and relevant milestones. There is a row for each team and a column for each sprint, and teams sequence the backlog items in the sprints and then string dependencies together.

At this stage, teams also started to draft their initial team program increment objectives (what the team wants to achieve in the upcoming quarter) and then the aggregation of all of the teams’ objectives eventually become the company PI objectives to be approved by the key stakeholders. Rosetta Stone® also encourages teams to include stretch objectives which might not be finished in the next PI. After teams have a draft plan on the program board and draft objectives, they present these WIP plans to key stakeholders, separate from the rest of the group. Because the stakeholders are reviewing the draft plans from all the teams, they have a holistic view and can see if there are any challenges such as scope, resource constraints and dependencies across the teams in the next program increment.

Day 3: present plans and gauge confidence

The final day is when everything comes together. The teams break out once more to make any changes based on the feedback they received the day before, they update the program board and finalize their presentation. One member from each team (usually the Product Owner) presents highlights from their team’s plan to all the other teams in attendance. This includes final program increment objectives, stretch goals, the sequence of stories in each sprint, potential risks and dependencies.

During this presentation, the rest of the group, outside of the team, is encouraged to provide feedback and ask questions. Once all of the teams have presented, a ‘confidence vote’ takes place where teams vote on their confidence in their ability to meet program objectives using the”fist of five” approach.

Fist of five voting: Fist of five voting is used by agile software development teams as a quick way to poll team members and help achieve consensus. First, the team facilitator states the question e.g. Is everyone confident with the plan we have presented? And then counts 1,2,3, vote! Each team member votes at the same time by holding up 0 to 5 fingers depending on their level of confidence (where 0 is “not confident at all and 5 is “Absolutely, we are going to smash it!”). If a team member holds up fewer than three fingers, they are given the opportunity to state their concerns and the team may respond. At Rosetta Stone®, the team facilitator looks for a mean average. If there are a lot of 1s and 2s, they will consider re-planning and revoting, but it isn’t required that every person is holding 3 fingers or more.

Day 4 and beyond: Jira Software and Portfolio for Jira

The week after the PI planning, Todd, the head of PMO at Rosetta Stone® and the release train engineer, leads a brief retrospective to capture what went well, what didn’t and what can be done better next time. By this stage, the teams have also entered in all of their sprint plans from the program board into Jira Software, so Todd and Eric use Portfolio for Jira to create a Rosetta Stone® portfolio plan.

Portfolio for Jira uses the team’s scrum boards in Jira Software as a data source to roll up into a multi‑team plan, so that they get a portfolio view without any extra effort, since each team was doing their planning already. “Prior to having Portfolio for Jira a lot of that information on the board, although it could persist and be available, it was hard to update it or revise it to reflect reality” Eric said.

Portfolio for Jira live plans: Rosetta Stone® are a Portfolio Pioneer and are using Portfolio for Jira live plans (currently a labs release) which loads data dynamically from Jira Software and let’s them plan in real-time. With this new seamless integration experience, they can instantly create a plan from their existing data in Jira Software and it’ll be up to date – always. By following the quick set-up wizard, Rosetta Stone® can have a portfolio plan ready to go in under a minute – just connect to the boards and projects from Jira Software, select the relevant releases, add teams, and confirm the scope. Voila! A live portfolio plan.

As I was leaving, Todd mentioned that “getting multiple teams to move forward in the same direction at the same velocity is an incredibly hard problem. Scaled agile helps us solve that problem as it gives us absolute visibility across all teams and helps us move forward at the same pace. Using Jira Software, Portfolio for Jira and the scaled agile framework (SAFe) within Rosetta Stone®, allows us to see what all teams are doing at the same time. This is extremely important when you have as many dependencies as we have between teams.”

Rosetta Stone® calls this PI planning and at Atlassian, we call it quarterly planning, regardless the point and importance of these meetings it to get everyone aligned at a micro and macro level. This is important for any size team or organization, and will lay the foundation for strong agile software development that can scale.

Happy planning! 🙂

Try Portfolio for Jira free


Did you find this post useful? Share it on your social network of choice so your fellow agilists can learn more about roadmapping, too!

Agile roadmap planning done right with Jira Software and Portfolio for Jira