Background

So as well all know, we have a global Pandemic right now completely changing our world. We have conferences being canceled. The vast majority of office workers are now working from home. On my current project we practice Scaled Agile Framework (SAFe). I’ve been around since the first program increment (PI) of a greenfield global platform for a major corporation.

I started as a service developer on a core services team and have moved into the development lead role of that same team. Our team is globally distributed with onshore and offshore members. Most of the core of our team leadership is located in the United States and typically attends a normal PI planning session. This time was different. We had the planning canceled a week ahead of time and we transitioned to a completely virtual PI planning. Overall, this planning session was my 9th program increment planning for a Scaled Agile Framework Project. This required adjustments to our individual team, as well as the rest of the Program overall.

Preparation

In preparation we refined all of the stories we had in place and identified all of our features that we had a part in. This is normally done remotely for our team anyways since we are all remote. I think we did a lot better on prep work this time since we had clearly defined out the scope of our work and knew what items we were responsible for. We also knew what other teams needed from us - or which teams we would need to support during this PI.

We were also setting up a demo of our current accomplishments from the just completed PI that we were participating in. My Product Owner set it up for me to drive the operation of the screens while he talked to our accomplishments and we both demonstrated our current features.

The day before planning I ensured our demos were set up and running properly. I also started working through Azure DevOps and creating queries for our user stories - as well as tracking queries for our individual sprints for the next program increment. I then created quick charts for total story points within each of those sprints. If I would’ve thought about it at the time I could’ve created an entire dashboard to run off of. Sadly, this wasn’t done until the beginning of our team breakout when I asked my architect to create it on the fly.

So overall in Azure DevOps we created:

• Main query for stories within the PI (default 0 pointed for filtering purposes)
• Individual queries for each Sprints within the next PI to move stories into
• Built charts for each Sprint of total story points
• Dashboard with each individual chart and query short results on it

Something I also did was to split up my office wall into our different sprints like our typical PI planning that we do in person. I quickly printed out a quick synopsis of all of our stories for the PI. After a bit of arts and crafts, I had blue painters tape mapping out the individual sprints and individual stories all mapped out.

We grabbed our historical velocity from the previous 2 PIs and were ready to go at the beginning of our team breakout session. I set up a secondary camera to stream to our teams group breakout and confirmed with a couple of team members the view of the board the day before planning started.

Previous PI Demo on Teams Live Event

This was actually the first time being a part of a Teams live event and I really liked it. The Q&A was a little finicky but worked overall. Some users didn’t realize their questions went through moderation and would submit multiples. You end up having to have a member on the presenters side who has the knowledge to answer the questions (subject matter expert) and a moderator filtering out the question queue. Normally, presenters’ simply do not have the focus for the typical Q&A unless specifically called out. Individual audience members also seemed to not have a good way to follow up on their questions once they were answered - or if they needed clarification.

Individual Team Planning

Each of our sprints was clearly labeled on my wall and each story had a number. In our teams channel we had a thread for all new stories being added to ensure nothing was lost. As I moved stories around on my board, I would call out the number and which Sprint it was moving from and where it was moving to.

Typically, I make adjustments and split stories on the fly and confer with the team if they have objections. These initial estimates are simply that - rough estimates. When we commit to them in sprint planning, we will be held accountable for those story points but a single person being in charge of the board allows for better control I believe. In a normal planning session, I would end up having one of my developers run stories to other teams if we are pushing out a feature that needs implemented. Since we’ve been prepping for the move to AKS and containerization it has meant a lot of the groundwork we do rolls out to other teams.

This was a bit tricky since each team had their own breakout session and Teams channel for planning. Each team was also handling pulling in stories from other teams a different way. We had a queue and as visitors from other teams stepped into the room we would identify them in the chat then ask them what they needed as we came to breaks in our current run through of our individual team plan. When we came across something we didn’t have things accounted for, we would have the other team generate a new story and place it in our main PI bucket with 0 points. This would allow it to show up in our planning query of items that still need to be placed inside of a sprint. At this point we would give it a rough estimate on points after talking with the visiting team members. Then we would need to shift around items that we had in place. Do we consider this item as part of tech debt? Is it part of User support? Do we remove the points from those buckets or we need to fully adjust the scope of the items we have in place? Now this is a normal process that occurs at PI planning - the only difference is that this was completely virtual. I would make a card and place it on our main board where we thought it would be and we would adjust it in Azure DevOps accordingly.

One thing I found that worked well is having people in charge of specific jobs and ensure you document items out in your plan:

• Have runners to go to other teams to integrate dependencies into their plans.
• Have a board operator (Dev/Tech Lead) to maintain the board. The Product Owner can be walked through the plan but the Board Operator should be soliciting information from the Product Owner/Main Stakeholder on team priorities.
• Have someone who is maintaining Azure DevOps/Jira/tracking tool.
• Have a pipeline to track newly added stories.
• Have a pipeline to track story movement/story point changes
• Ensure that story point allocation is not dedicated to a single person. The Dev/tech lead may be the centralized point of decision but feedback should be coming from other developers/QA/architects.
• Mark out delivered Objectives at the top of each sprint
• Mark out Releases during your plan

At the end we would walk through the board with our Product Owner. He, at the end of the day, was responsible for presenting the team plan to the overall program. We also made sure that each story tracked to our individual objectives. The tagging of stories and direct entry into ADO meant that we were able to better understand our total time assigned to our objectives. We also ensure that we had specific percentages of our time allocated to tech debt/user support/new features - as was determined by the Program overall.

Lessons Learned

I was fearful going into this planning. After 8 in person program increment planning sessions and knowing about all of the side conversations, I was skeptical that this would work. Overall, I believe the extra work that went in beforehand and successful team-oriented role assignment meant that we came away with a successful plan. There was quite a bit of risks that we needed to call out - and there wasn’t a great way to identify overall risks or track inter-team dependencies across a program board. This may have come down to individual training/experience with the tools we were operating with rather than individual team interactions. Since this was the first major virtual PI planning that we had, and everything was thrown together in about a week and a half, I came across impressed by how my team and the program overall transitioned to the virtual planning session.

The physical board available to me allowed me to quickly and easily answer questions about our plan as well as adjust on the fly without having to scroll through multiple screens of data. I know that everyone may not have the space available for something like this - my office is 10 ft X 14 ft. I probably didn’t need to have a second laptop running - a second monitor would have probably been sufficient. The second laptop allowed users to pin my main video stream to the page and expand it to see the entire board view.

I feel like the presentation of our plan and walking through it with members of the team was easier since there was a physical representation of the plan as we walked through it. This may be based on my own preconceptions - I am a visual person. I like to feel and touch and draw out things.

Please feel free to reach out to me with details of your own Virtual planning sessions or other feedback that you may have. We have migrated into a new world of business continuity across the globe that has all kinds of uncharted waters. Hopefully this will help others effectively adjust to this new reality we are currently facing.