I got an excellent opportunity to train multiple teams on big room planning. Based on my learnings, I am hereby summarizing step by step process on how to conduct simulation for big room / PI planning. This simulation was done for around 45 people in the same room for the purpose of training and can be completed in 2 to 3 hours.
1. Decide on what kind of ‘scrum team’/squad selection process will be followed. If the Scrum team are already selected, they can sit together else the easiest way is to go table wise.
You can also run through different type of team selection process viz.. ‘self-selection’, ‘guided selection’, ‘directly appointed’.
a. Self-selection – Where members can decide to choose the scrum team depending on the Scrum team mission, their own skills and team dynamics
b. Guided Selection – Where members are already allocated a Scrum team to start with. The members still have an option to move between the Scrum teams based on their interest
c. Directly appointed – Where members will be allocated to a Scrum team and they will not have an option to move around
2. The participants can look at the Epics/features to come up with user stories or user stories can be given to them (Preferred to save time)
3. Epics should have priority called out and at least 2 to 3 epics needs to be given to each Scrum team
4. Call out volunteers who can run through biz context, vision, Architecture vision, development practices at a high level, so that the participants can understand the bigger picture
5. Each Scrum team should identify their product owner and scrum master
6. Explain the concept of cadence and agree on the sprint duration
7. Each Scrum team should prepare their own visual boards with headings such as Sprint 1, Sprint 2, sprint objective, Risk board.
8. Explain ROAM concept (resolved, owned, accepted, mitigated) for categorizing risks
9. Discuss on whether the product owner and scrum master will contribute to the actual creation of work products (Fully/Partially/not at all) which will help them to calculate capacity later
10. Explain how capacity is calculated. Ideally, it is the amount of time people are available for actual work which excludes leaves, public holidays etc. Additional parameters such as only 80% will be used for calculation or a Product owner and scrum master’s time will not be used for capacity calculation can also be called out.
11. Explain the concept of relative estimation. Ask them to download any of the free tools available like scrum time/ planning poker. Explain how
a. Skills, knowledge can be taken into consideration while doing estimation
b. How to come to consensus while estimating ( not by majority/ minority/SME decision etc but purely based on the discussions and it is ok to play poker 2 to 3 times till everybody is on the same page)
c. How this will increase the responsibility of each and every team member (taking bottom line responsibility for the estimates which the team has provided and how chances of they adhering to the plans are much higher)
12. Each squad should identify the ‘least story point’ story out of the list already provided. Once that is identified, they can do relative estimation for other stories
13. While discussing stories for estimation, the Scrum team members should also identify any Risks and dependencies
14. Discuss ’PO’s sync up’ and how it helps by deliberating on
a. How PO’s can understand the work done by other Scrum teams
b. Resolving dependencies
c. Adding New stories (if Required)
d. Prioritization of the newly added stories
e. Discussion on which Scrum team can take up the newly prioritized story
f. Risks if they are already identified
15. Discuss how PO’s should disseminate the new information in their own Scrum teams
16. In the meanwhile, depending on the capacity of the team, the priority of the stories and dependencies, the teams should plan on how many stories can be completed in each of the sprints
17. Call ‘scrum master sync’s’ (Also called scrum of scrums) and discuss on
a. how they can resolve the impediments
b. They can suggest teams to categorize risks (ROAM,)
c. Whether Scrum teams needs any help to plan their sprints
18. Scrum teams should also set up the Tribe/Program board (Tribe is nothing but a collection of Scrum teams) where the epics done by each Scrum team are listed, the dependencies are identified and connected through a physical wire/ thread so that it is clearly visible
19. Once the Scrum team boards and Program boards are filled up, each Scrum team should walkthrough the objective of the sprint, a high level sprint plan and risks identified at both Scrum team and Program level
20. As a facilitator, Check if the capacity and load (story points for each sprint) are almost the same. If not, suggest the following can be done to improve the load
a. Check if any high priority stories from any other Scrum team can be delivered by this Scrum team?
b. Can any sprint2 stories, be pulled into Sprint1 (which does not have any dependency/minimal dependency)?
c. Check if any story from the backlog can be pulled in ?
d. Can any technical stories such as refactoring be added to the backlog and completed in this sprint based on the priority?
e. Can we improve the knowledge of the team by conducting / attending trainings?
f. Can we improve the existing processes/ can we automate?
g. Discuss on stretch objectives
21. Discuss on the team’s view on the Program board with various dependencies (connected through the wire) and how these dependencies can be reduced. Take the opportunity to reiterate how visual boards help.
22. Introduce to the team, “management meet” where the PO’s, Program leads and other stakeholders will look at Program board to reduce the dependencies
a. Identify the epic where majority epics/ stories are dependent
b. Check if the epic can be further divided, so that dependency on the epics/stories can be reduced
c. Check if the epics needs to be re-prioritized
d. Check if new Epics need to be added ( Risk board can help in identifying this as well)
e. Discuss about WIP limit (work in progress) and explain how “Stop starting and start finishing” helps in achieving the overall objectives
23. Explain to the team that inputs from the “Management meet” needs to be incorporated by each and every Scrum team by adjusting their sprint plans
24. Explain confidence vote (fist of 5) and the importance of it. Assuming that 5 is the highest confidence and 1 is the lowest confidence, ask the Scrum teams to vote for their sprint plan
a. Tell them that generally Confidence vote within the Scrum team will be above 3 as they have come up with the estimates, identified dependencies etc
b. If the confidence vote is less than 3, it also means that the team members did not participate with the right intent in the planning sessions or there are risks/dependencies which are still not identified/not taken into account
c. Explain how other Scrum teams can participate during confidence vote and reasons on why the rating can vary.
25. Complete the big room planning simulation with a retrospective
26. Summarize the benefits and outcomes of big room planning
a. Face-to-face communication across all team members and stakeholders
b. Improves Transparency and aligns all team members to the vision
c. Understanding the big picture and how biz goals are converted to epics/stories (Traceability)
d. Faster collaboration, faster decision making to resolve any dependencies or risks identified
e. Team members taking up bottom line responsibilities
f. Most importantly, if the members were working in waterfall model, how a mindset change is required to adapt to agile , participate and contribute in these events
Before starting of each sprint, the sprint plan needs to re-validated as
a. New stories might have got added with higher priority
b. Existing stories might have got prioritized higher due to change in Market condition etc
c. The teams might have realized their velocity is either less or more
d. High priority defects might have to be addressed
e. Based on the previous sprint retrospective actions might have to be taken
f. Based on the definition of done and acceptance criterion (as more details are available)
Though the article mainly talks about from the simulation of big room planning, almost everything can be used for facilitating the actual big room planning for a Program/scaled agile teams
In real scenario, ensure that
1. All key stakeholders of the Program including Business, Leads, Architects, SME’s, Scrum team members are present during the planning event
2. The person facilitating the session needs to be really good else the outcomes cannot be achieved within the 2 days
3. Lot of preparation/logistics needs to be done in advance viz
a. Meeting invites sent to all participants to block their 2 days
b. Meeting rooms big enough to have all the participants
c. Break out rooms
e. Food, beverages, water etc
f. If distributed across geographies, plan it in such a way that there are facilitators in each geography , logistics arranged for steaming live conversations
4. Ground rules/ Agreements such as be on time, no ringing phones, respect others, ‘listening to others’ needs to be laid down at the beginning of the event and needs to be adhered by everyone
5. Each tribe/program should clearly have a vision which is accepted by the senior stakeholders
6. A well refined tribe/program backlog which is ordered/prioritized
7. Product owners from each Scrum team should have looked at the tribe/program back log, clearly understanding the business context , priorities and dependencies
8. Ensure that the teams are not new to the concept of agile, scaled agile by giving trainings etc before the big room planning
9. Scrum team selection is completed and the team members within the Scrum team (at the least) know each other
10. It will be wonderful, if the tribe/program back log can be shared with the team in advance so they understand the context completely and come prepared
Submitted by Anu Ravi