April 30, 2020
Developed by Kodi Terry
Sr. Director, Global Technical PMO at Imagine Communications
Certified SAFe® 4 Agilist, Certified SAFe® 4 Practitioner, Certified SAFe® 4 Scrum Master, Certified SAFe® 4 Product Owner/Product Manager
Remote PI Planning Preface
As a full-time employee of Imagine Communications for a little over two years now, my experience in the company’s SAFe® journey has been full of surprises ― the latest of them, of course, COVID-19. As we just successfully executed our first fully remote PI Planning session, I hope that sharing our experience can help you flatten your learning curve, reduce your anxiety, and give you a head start on making your own SAFe journey a success.
We began our Global SAFe transformation at Imagine about a year and a half ago, at which time I was moved from my position in engineering management to my current role as Sr. Director of the Global Technical PMO, and perhaps more importantly (depending who you ask) Release Train Engineer (RTE).
In 2018, we engaged with TecVeris, a member of the Scaled Agile Partner Network, and underwent an assessment of predictability, delivery, and overall employee satisfaction. Before our full assessment was even complete, our CEO Tom Cotney was convinced SAFe was the way to go and was all-in. With vision and constant leadership from our SVP of Engineering, Dave Hogan, and VP of Product Ronnie Bell, and full investment from our C-suite and Board of Directors, our transformation began. First in the U.S., then to the U.K., then back to the U.S. to wrap up — all employees for the first Agile Release Train (ART) were fully trained and offered company-paid SAFe certifications (I’ve gained four of them myself so far). So with certifications in hand, it was time for our team to hit the ground running with PI-1.
Now, before I go too far, let’s get it out of the way that “we are different.” I know, I know ― everyone, everywhere, in every business is “different.” And yet, when it comes to SAFe, it’s what makes us all the same (so really, we aren’t different at all, but stick with me here … I’ll give you a jaw dropper in just a bit). We utilize the SAFe framework as just that ― a framework ― one that guides us AND offers us the flexibility to inspect and adapt that framework to the specifics of our business. Luckily, none of us must agree on what is perfect; we are simply aiming for progress, predictability, and positivity.
On this ART currently, we are 1 company, 6 products, 17 teams, multiple locations, 2 planning sessions (U.K. and U.S.), 1 ART. Go ahead and judge, I already know ― we are breaking the rules. Or as I see it, we are simply adapting the framework. It actually works well (for us) this way, and we are always improving. So, we have one three-week IP iteration: Week 1 we do PI planning in the U.S., week 2 we do planning in the U.K. (or vice versa), and then we sync everything up with the normal ceremonies and some tools to give everyone as much visibility as possible.
After a couple of PI Planning sessions, we learned a few things:
- There is no replacement for face-to-face planning, but that doesn’t mean we always need to be face-to-face.
- It’s ok to save a little money and split up the travel. We can send delegates as needed if dependencies on other product lines are expected.
- Pre-planning, extra planning, and a whole lot of patience are key.
So, I’ll fast-forward to our 5th PI. U.K. planning week is up first ― flights and hotels are booked (and sometimes that is harder than PI Planning, am I right?!), and BAM! Travel is shutdown to the U.K. The writing is on the wall (and in a few emails) that our second week planned in the U.S. is also about to be compromised. Our ACE group meets (we dropped the “L”; no one questions an ACE meeting, but they think twice about attending a Lace meeting ― we didn’t want any confusion), and concerns seem to be generally akin. We think it’s time to plan for this thing being all remote. We’ve trained our dev teams to pivot without mercy, and now it’s our turn.
Below is a detailed description of how we executed on the plan, including tips and tricks we learned along the way. It is my sincere message to you that you plan and plan and then plan a little more. Then test the plan you are planning. Communicate the plan far and wide, ask for and assess the feedback, and then plan some more. Recommunicate the plan, and then invoke the most patience you can muster and execute this PI Planning like you know exactly what you are doing ― even though you are just hoping you planned enough! No matter how much you plan, communicate, or test, something will go wrong ― and some process won’t be followed. Be ready to have locations to point people to, convey the message that you’ve “given them everything they need to get the answers themselves,” and then answer them anyway. Be ready for someone to not like what you’ve done and not appreciate the time you put into planning. Shoot, we even built in a couple things for people to complain about, just so I would know it was coming. So we even planned for complaints!
Ok, let’s get to it…
Assess the Agenda
Step 1: Figure out the agenda
Get out the PI Planning deck and start formulating the agenda. Now keep in mind, we will have people in both the U.S. and U.K. potentially needing to join multiple sessions, so listing all timings in as many time zones as we can fit on the page becomes our first hurdle.
It quickly becomes obvious that we need to figure out our overlap times first, and our number ONE priority is to ensure that our teams have as much planning time as possible. With that in mind, we go to work.
The PO manager and I quickly agree that the system demo can be done early, so first on the books, SYSTEM DEMO: All teams, 1 Zoom, 2.5 hours, day of its own. Next up, INSPECT AND ADAPT workshop: PI Planning context, logistics, mindset, ½ day all on its own. Let’s call it “Day 0.” (You’ll thank me for that one later when you don’t have to change all of your decks!) Then PI PLANNING Day 1 and Day 2: full team planning days.
Step 2: Use the agenda to figure out your tools
Based on your plan, what do you need to have ready? For example, I knew that I needed a way to capture, collaborate, and communicate. Use your agenda as a self Q&A to assess your tooling needs. (And check out the grid under “Resources” at the end for an at-a-glance layout for all use cases.)
Tips, Tricks, and Tools
Easy: Zoom share.
- Pro Tip: Set up a password. No one needs a bored quarantine hacker hijacking their meeting
Again, Zoom. But we made sure that a template went to everyone ahead of time, and expectations were set that each new sharer knew their turn.
- Be sure to change the “Share” setting to “anyone can share when someone else is sharing.” You don’t want the constant back and forth of “can you stop sharing so I can share?” We are on a schedule!
For all demos, whether completely live or prerecorded, we asked for everyone to practice on Zoom ahead of time to ensure all the bits were working.
Set the system demo aside. Do it on a day all on its own if you are worried about time. (See the I&A Tip below)
- This ended up being a great idea, as we had a couple product lines that went longer than anticipated, and we ran over our timebox a bit (See “Problem Solving” for more). We gave our POPM crew a template PowerPoint to fill in with their objectives, business values (BV), actual values (AV), and AV explanations. The idea was to minimize Zoom sharing changes and keep everyone flowing.
(I&A Tip: We asked for estimated timings in advance, but we now know that questions push us a bit longer. Add 30 minutes and publicize that workstreams can only exceed their estimations by X minutes. Some people are very passionate about their products ― give them time, but not too much. And keep it the same for everyone. You don’t want to be accused of playing favorites!)
Facilitating problem solving is admittedly a bit tricky, and you really have to Gemba to be involved (more on Gemba further down).
Remote Problem-Solving Prep:
- Get it all set up ahead of time:
- Confluence pages
- Zoom (main meeting room and links for the breakout rooms)
- Predetermine who will be in each breakout
- …whatever else
- Ask your scrum masters (or similar designees) to determine the topics in advance, with team input. This may be done with discussion or survey.
- Review with the ACE and scrum masters at least a few days ahead to ensure they understand the process and can ask questions in advance.
Remote Problem-Solving Tips & Agenda:
- Bring the full ART together in the main meeting room
- Set expectations
- Share pre-created Confluence pages with everyone. In our case, each page was complete with pre-filled participants, NoteApp links for brainstorming, and sections for Outcomes and Actions. A picture is worth a thousand words, right? (See below)
- Split up into smaller, problem-solving teams using Zoom breakout rooms
- After 60 minutes, come back together in the main Zoom to have the teams present their Kaizen (improvement prioritized for the next PI)
- In an attempt to make things look and feel like they do in person, we purchased a Team-level Miro license for each scrum master.
- We are on a budget (after all, #Covid-19), so there are some limitations to this. Everyone on our ART can comment on any created board, but only scrum masters have edit rights. I created a template for use, but encouraged everyone to make it their own.
- Because we purchased the Team level miro license, we hooked it up to our Jira instance.
- Seriously the simplest thing ever. Set up the connector, and boom! You are copying, pasting, dragging, and dropping Jira Cards full of all the information you need right onto boards. So, also doing our part for the environment ― man, did we save some paper!
- Some people prefer Trello and we had a mix of use ― they both worked great.
- SHARE the Team Boards.
- We use Microsoft Teams internally, so we have a whole Teams Channel dedicated to PI Planning. We set up a Wiki page with links to EVERYTHING. Links to Confluence, links to all Miro Boards, links to Zoom breakouts ― link, link, link.
- We also use a great little tool called “NoteApp” to create public boards that everyone can use to post stickies if need be (more on that later).
- We again went with Miro. Their template is perfect enough to get anyone started.
- I told you our ART is huge, and so is our board. But it works and has all the information you could ever need.
- Again, everyone can comment. So instead of putting a sticky on the Big Board, you copy and paste a comment with the URL, and your administrator drops it on the board.
I’m certain at this point that you are dying to see this board, so here is the finished product after all our planning. Don’t forget, we covered this earlier, mouths closed ― no jaw dropping allowed. So, check it out: we’ve adapted. Our board goes 90 degrees different than what you expect, and let me just add, this has worked brilliantly (as my U.K. friends would say). In person, we had walls that were way longer than they were high, so to make it fit…voilà. And then we made it digital.
And for what it’s worth, we went digital before digital was “cool” (we are a tech innovation company after all). In person, we like to have both versions. And while remotely your stock in adhesive paper products will decrease, the silver lining is the money you save in supplies.
I know you’ll be shocked, but again, we went with Miro on this. I thought it would be helpful to share with you my directions to the ART on the dependency workflow.
I pre-created the dependency board and had a template as well as an example card. I even have a visual for you!
- Scrum Masters, CTRL +D ― duplicate the template card.
- Double click to fill out the card (anyone can fill out the template).
- Place the card in the “For Review” column of the dependency board.
- Text the dependency contact for the TO: team to let them know it is there.
- Dependency team then decides if a call is needed and reaches out accordingly.
- Upon acceptance of a dependency, the accepting party must add the JIRA ID where the dependency is being tracked (story, task, etc.).
Anyone can copy and paste the template to the scrum master ― the SM just needs to paste it to the board.
Template to use for your dependency contact:
My Team
To:
My EPIC #:
My Story #:
Need Complete By? 5.x
What is your dependency:
*Accepted JIRA Dependency URL:
Risks are a tough one to deal with remotely, but our tool of choice is Jira, and we happen to use the cloud version. We did have one realization…Jira is enough for this, no need to duplicate also over to Miro. We have a Risk issue type and board in Jira and directed people as follows.
In terms of what should qualify as a risk, please consider:
A Risk is an event or condition that, if it occurs, may impact the program objectives and is considered serious and time sensitive.
Before raising a Risk, teams should work to resolve the Risk within their team or workstream. If a Risk cannot be mitigated within a team, it may need to be raised to the program level to promote awareness and to assist with risk mitigation.
Types of risks
- Strategic Risk
- Compliance Risk
- Operational Risk
- Financial Risk
- Reputational Risk
Risk status
- Resolved – The teams agree that the risk is no longer a concern.
- Owned – Someone on the train takes ownership of the risk since it cannot be resolved during PI planning.
- Accepted – Some risks are just facts or potential problems that must be understood and accepted.
- Mitigated – Teams identify a plan to reduce the impact of the risk.
For all risks in a status other than resolved, an update every iteration is required.
All Risks should be input into Jira ONLY
- Enter your Risk on the Risk Board in Jira
- Assignee remains blank
- Status remains OPEN
- use the template below for the description
- Inform your scrum master for RTE notice of the addition at SoS
Template for Jira Risk Description
From:
Suggested Owner:
Risk Summary:
Mitigation Plan:
SAFe Objective Reminder – https://www.scaledagileframework.com/pi-objectives/
So, we all know that at the end of Day 1, we have objective draft reviews, and then Day 2, time to lock in that commitment. Not only do you need to create objectives, but you also need to present them, revise them, and share them both inside and outside of presentations. So, here is our plan for objectives …
Jira has a Program-level Jira issue type of “PI objective” with a very simple workflow of adopted or closed (which I hope is self-explanatory). We also then created Confluence pages for each product line/team and preset the page using Jira JQL searches for a table of Objectives that auto-populate. Also, on that page is a section for “major dependencies,” where teams can input their cross-platform dependencies. Below that we have a JQL that searches our Risk Board (see Realization of Risks) that lists the risks for that group, and then below that, a full list of Epics listed for that product for the PI at hand.
Why is all of that needed? Well, it’s really more about what it prevents than what it provides. By pulling up one Confluence location ordered however I want it to be, as the RTE, I can do all the presenting for every person/group with their own inputs. This way, you minimize the time problem of changing presenters, and most importantly, prevent the “can you see my screen” question from becoming a drinking game (even though we are close to the end of the day at this point, and “sorry, I was talking on mute” might have already started the drinking game).
Jira JQL Search Example:
issuetype = “PI Objective” AND project = __________ AND fixVersion = ________ ORDER BY Business Value ASC
**Feel free to modify the query to search by only team and/or workstream.
- All summaries have 255-character limit
- Link objectives as “Objective of” to the Epic(s) they represent.
- Review to ensure they are SMART.
- Business Values = Set these on a scale from 1-10, you must have one 10.
**Leave blank if the value is uncommitted. - Actual Values = Please feel free to update when Actual Value is known/realized.
- Objectives are set to Adopted for the PI (Deleted if not) or Closed after Actual Value has been determined for the PI.
- Set Fix Version the same as you would an Epic
All Objectives will be shown on their corresponding sheet under Objectives and displayed in team meetings by the RTE, but presented by the team representative.
How do you get out where the work is happening when you can’t get out anywhere? It’s ok, technology to the rescue. Set up a central location: Teams, Slack, Confluence, Google Sheet, SharePoint ― you pick your poison and create a place for centralized communication (and then put it in multiple places so that even the most technologically challenged will find what they need no matter where they go). I used Teams Wiki, pointing to a Confluence page (that pointed back to the Wiki), which both contained sections for all Miro boards, links for every team breakout Zoom (and of course the main Zoom meeting), dependency contact information, scrum master information, and note App Links (see below).
What this provides is a central location to give to your leadership team. Remember the power of Gemba ― encourage them to drop in and see how things are going without being asked. Being present is difficult in this situation, and the temptation to multitask is something you will have to fight. The entire team benefits from those Gemba walks, so really push to make it similar to how things would be in person as you drop by. Be cognizant of conversations in progress and don’t screw up momentum with casual pleasantries like “How’s it going in here?” Listen, and find a suitable time to let your presence be known ― even if it’s just saying “Keep up the good work” on your way out. Gemba doesn’t mean “interrupt” after all.
Alternatively, encourage teams to reach out, send a message or jump over to the Main Zoom anytime. If leadership isn’t with a team, we are on the Main Zoom available for anyone who might need something. There is no question about where to find anyone, and everyone is a quick message away.
Oh, you know there is a love hate relationship with this one. Sometimes it’s praise, often its complaints. Sometimes you have control over it, and other times someone just had to nitpick something ― you know how it is. (And if you only ever get praise, I was going to say send me a message, but I’d never believe it anyway. And I’d suggest you need to push your boundaries a little more, ha!). The good, the bad, the annoying ― we still want to know.
I handled this simply by setting up a NoteApp board, a great virtual sticky board (literally) that I placed as a “website” in my PI Planning Teams Channel where anyone can go in and leave a sticky with their feedback. Put down your name, or don’t. Add a “+” if you want to up vote someone else’s sentiment (you know, a dot vote), or don’t. But either way, get your feedback, inspect it with care, and do what you can to improve for next time. There is always one little tweak that can be made, right?
This was an easy one for us: Set up a separate Zoom. If you don’t, inevitably you will have people lingering around, and no one wants to evict people from a Zoom. Just fire up a new one. Be prepared to share the risk board, use video to know who needs to talk, and be ready to invite others you may need to help with a problem. Cake walk ― if the problems aren’t too big.
We then come to the Finish Line of PI Planning (some would argue that is happy hour, but that is AFTER the vote, so that is the “Grand Prize”). This is a little tricky in the moment, but knowledge is power ― and so is planning.
Again, we use Zoom (I use one main Zoom meeting, and then have the teams set up their own breakout rooms), and I use the “Poll” feature of Zoom. Now this next part is important: Remember that patience thing. Pre-set your Poll with two questions ― one of them a fun question, and the second one your Confidence Vote. You’ll need that first question for all of those people that failed to listen or join those meetings where you communicated the plan, but still need to learn how to use the Poll.
Everything you need to know about Zoom Polling can be found here https://support.zoom.us/hc/en-us/articles/213756303-Polling-for-Meetings. I only used a meeting, NOT a webinar, and it worked great. Launch the Poll, watch for percentage of attendees to complete, End the Poll, Share the Poll results ― you got this!
*Pro Tip: Co-hosts cannot vote, so if you want a co-host to vote, be sure that you revoke privileges before you launch your poll. And if you screw up, or more likely need to vote again, just “Re-Launch Polling” ― easy peasy. If you need visuals …
Now for those folks that have low confidence levels (no judgment ― remember we are all actually the same, and we all have a few low-confidence ones), we request that they raise their hands and explain their stance. We listen and ask questions and see if there is anything we can do to raise their vote, or if the majority is within the range of acceptance, well, you know what time it is…management review! (I know you thought I was going to say happy hour, but that is Day 2. Stay with me here!)
- Turn OFF enter/exit chimes ― They are annoying and distracting. No chime ever made anyone on time, nor made them stay. Trust me, you’ll thank me later. Turn them OFF.
- Change the “Share” setting ― Ensure that you change the SHARE setting to “anyone can share when someone else is sharing.” There is nothing more annoying (other than chimes) than repeating over and over “let me stop sharing” or “can you stop sharing.” You have the power to make it stop. Use it wisely.
- Mute on Entry ― Asking people to mute over and over can quickly turn into another drinking game, and we need people to pay attention. Again, with great power comes great responsibility. Use your hosting privileges wisely.
- Enable “join before host” ― You never know what might happen. Losing your internet is one thing, but kicking everyone out of the meeting is another.
- Have co-hosts ― Get others to help you keep people on mute, start and stop recording if you forget, or generally keep things going if need be. Also, remember to revoke their co-host privileges prior to voting or they won’t have the option.
Communications and Questions
Step 3: Communicate your plans, ask for feedback, and finalize your plan.
Walking into PI Planning fully remote and expecting everyone to know what is about to happen and how is unrealistic. And as stewards of scrum leadership, we of course know better. I handled this by hosting two identical Town Hall meetings, offered at different times for folks to join live. And I shared the recording AFTER both meetings ended (remember your goal is active participation, not passive).
The Town Hall meetings were 30 minutes each and walked through the plan at 25,000 feet ― just enough of an overview that people felt like they knew what was going on and where to find what they needed if they were just totally confused. I spent 20 mins or so spelling things out and left 10 minutes open for comments and questions. Invoke that patience ― you’ll breeze by something while someone is multitasking, and you’ll have to repeat. Remember that repetition equals muscle memory; it’s one less thing you’ll have to handle when you are in execution mode.
Conclusion
In conclusion, it takes a considerable amount of work to get things ready to rock, but I hope this commentary helps you get it all in line. I learned from first-hand experience that it’s a lot, and now you know that too. But if you execute with a well-devised plan, no one else needs to know.
Like any good RTE, I held out until the end to virtually but literally, raise a glass. Don’t forget about that virtual happy hour ― you deserve it. Have a laugh and enjoy the fruits of your labor…. just remember to stop the recording!
Resources
No single platform or tool will meet the needs everyone thinks they have (you know, “but we are different”). Here is a table of all the tools we utilized and their purpose. Please read on for additional detail…
Use Case
Tools Used & Final Thoughts
Tracking PBIs (epics, stories, etc.) PI Objectives, draft & final plan review, WSJF, business value, actual value, story points, etc.
Tool / Platform Utilized: Jira set up with the TecVeris Jira template for Agile teams
If you are using Jira and don’t have Jira already set up to effectively support your ART, this is an important first step. Also know that you can add SAFe configurations, like those stated in the use case.
Problem-Solving Workshops and Presentations
Tool / Platform Utilized: Confluence
Pre-create and pre-organize your pages. Determine how much pre-work is required and ensure everyone has the appropriate rights to edit these pages as needed.
Objective Creation and Presentations
Tool / Platform Utilized: Confluence/Jira
Pre-create and pre-organize these based on presentation order. Use Jira JQLs to populate them in real time as they are entered. Remind your teams to check these pages to ensure all JQL field requirements were met and that what is expected to be shown is what’s there. It’s easy to forget one small detail. Provide workflow directions for your objectives so you aren’t answering questions regarding input in the middle of PI planning.
Digital Big Board & Dependency Management
Tool / Platform Utilized: Miro and Jira for “relates to” dependencies
Get these all made ahead of time. Once you are confident with your layout, group and lock the template. I suggest only 1-2 owners of the Big Board. Anyone can comment. I had people comment with URLs, which you can drop right on the board in a matter of a couple seconds.
Metrics
Tool / Platform Utilized: Google Sheets with Jira connector, Excel, nVeris
Metrics are tricky and determining what best to track will depend on your business. Leverage the tools at your disposal and seek out those that already have it figured out. Make the gathering of data easy and repeatable, and of course automated any chance you get.
Chat & Documentation Storage
Tool / Platform Utilized: Microsoft Teams, Google, Zoom Chat
This is really a personal preference. Keep it secure, but accessible, and if you have multiple contributors, keep it in a place where everyone is editing the same copy.
RTE Presentations, ART Presentations and ART Directives
Tool / Platform Utilized: Office 365
PowerPoint, Word docs, you know the ones. I like to leave my PP slides up as the day goes on so anyone dropping by can see what is coming up next.
Web Conferencing, Breakout Rooms, Confidence Voting Polls, Gemba Walking
Tool / Platform Utilized: Zoom
We were coached to do a confidence vote at each scrum of scrums, rather than waiting until the end of PI planning. A Zoom poll is a great tool for SoS and final confidence votes.
Tracking Risks
Tool / Platform Utilized: Jira
We tried both a Miro board and Jira, but ultimately, one location is all you need. We landed on Jira and ROAMed via a Jira board where all new risks remained in an “open” status until they were fully discussed.
Team Boards & PI Planning Feedback
Tool / Platform Utilized: Miro, supplemented with NoteApp, and some teams opted to use Trello
No matter what you use, ensure that you have shared links to everything, and they can be found by everyone to review as needed. Over-publicize the locations to find data.
Tracking Zoom Links & Capacity Planning
Tool / Platform Utilized: Excel Sheets posted in TEAMs, Google Sheets
Come to PI Planning with your capacity per team pre-calculated using Quick Start or historical velocity. For fully remote planning, a spreadsheet with all of the links is essential. Post in a place where changes are real time ― no need to have to update every time there is a change.
Sample Agendas
Confluence Layouts
Confluence Layouts
- Always be on time ― we agree we don’t want to keep anyone waiting.
- Risk Workflow
**We agree everyone’s time is valuable and we want to respect our time box. - We agree to mute ourselves when not talking to ensure minimal disruption.
- We agree to let others talk and finish their thoughts and to not interrupt each other.
- We agree when talking to keep our comments to 2 minutes or less at a time to allow for everyone to have a turn.
- We agree to be actively engaged at all times.
**We agree if we need to step away or are otherwise not engaged, we will let everyone know.
**We agree to minimize asks such as “can you repeat that?” and “sorry, I was multitasking”. - We agree to be prepared.
**If we have questions about processes or tools, we will ask prior to breakout time with the team. - We agree to use all of the resources at our disposal to answer our questions.
- We agree to be a member of PI Planning Resources team and keep ourselves up to date with information posted there.
- We agree to use Zoom for our meetings. We agree we will use TEAMS as a backup and make every attempt to keep our data secure.
**We agree if circumstances allow to be on video as much as possible to interact with our teams. - We agree to be positive, courteous, helpful, and productive.
Objective Workflow
xplanation. Use your descriptions to speak for you!
- All Workstream Objectives have the component set accordingly.
**The -Team- will be “unassigned” - All Team Objectives have the component AND the -Team- value set
- All summaries have a 255-character Limit
- Link objectives as “Objective of” to the Epic(s) they represent.
- Review to ensure they are SMART.
- Business Values = Set these on a scale from 1-10, you must have one 10. **Leave blank if the value is uncommitted.
- Actual Values = Please feel free to update when Actual Value is known/realized.
- Objectives are set to Adopted for the PI (Deleted if not) or Closed after Actual Value has been determined for the PI.
- Set Fix Version the same as you would an Epic – XGPT: PI-5
All Objectives will be shown on their corresponding sheet under Objectives and displayed in team meetings by the RTE, but presented by the team representative.
**Objectives will populate in Confluence automatically; however, major dependencies should be entered manually.
PI Planning Scrum of Scrums
SOS #1
Day 1 Time 11:00 a.m.
- Capacity = All Good?
- Jira Issues / Access?
- Iteration Planning Started?
- Any known risks/dependencies?
- Milestones or Epics to add to the Program Board?
- Other Issues / Comments
- Meet After:
SOS #2
Day 1 Time 1:00 p.m.
- Breaking Epics into Stories?
- Iterations being planned?
- Any known risks/dependencies?
- Milestones or Epics to add to the Program Board?
- Confidence Check?
- Meet After:
SOS #3
Day 1 Time 3:00 p.m.
- Dependencies, Epics, Milestones?
- New risks?
- Team Draft Plans? Time to get started
- Confidence Check?
- Meet After:
SOS #4
Day 2 Time 11:00 a.m.
- Dependencies, Epics, Milestones?
- New risks?
- Draft Plans and Objective Refinement
- Confidence Check?
- Meet After:
SOS #5
Day 2 Time 1:30 p.m.
- Final Dependencies
- Other Big Board additions?
- Work-stream Plans Underway
- Confidence Check?
- Meet After:
Footnotes
iMain Tools : Zoom, Jira, Confluence, Miro, NoteApp, Microsoft TEAMs, Google Sheets