Planning Agile Part I: The Calendar
As a Scrum Master I get a lot of questions from our customers and other Agilists about how the Agile Central team does planning. What is our planning process? How do you run Big Room Planning (BRP)? How do you prepare for BRP to go smoothly? What makes a BRP event successful?
In this two part series, I will tackle our planning schedule and the work we do leading up to a BRP event to make it successful. Part two will dive deeper into the BRP event itself, what those two days look like, and some of our learnings on how to have the best event possible.
How We Operate
The Agile Central team practices SAFe. As part of SAFe, we plan our work in planning increments (PIs) of one quarter at a time and work in two-week sprints. In addition, we plan as one release train made up of 15 teams across three locations. Work is organized based on our highest priority initiatives to tackle in each PI. We define an initiative as a mid-range (1-6 months) business objective (including architecture or experiments) that delivers value to customers. Initiatives are budget-constrained, not fixed scope, so that we are flexible on how we plan and deliver on the objective.
Each initiative has two to four teams coordinating on delivering that body of work. They do this by defining and executing on related features and stories. For more on how we organize and run our development teams, check out this post.
Since we work in two-week sprints, it is easiest to break down our planning process into the same time boxes. This helps us keep all of our work and our brains in sync.
Our planning calendar starts during the first sprint of the quarter while our teams are off executing on the plan we just committed to in Big Room Planning.
The first step is our product managers continue the product discovery process. The discovery process includes looking at customer feedback, data, and our product backlog. This process allows us to take a high level pass at top priority initiatives and key potential features for the coming quarter. It also sets us up to understand customer, market and design gaps that need to be addressed before the work can be planned. With that understanding, we have visibility into whether or not the work will be ready in time for the following quarter.
During the 2nd sprint, User Experience, Product Managers and Architects continue the discovery process. They prioritize initiatives and begin to break the priority initiatives into deliverable pieces. Here we don’t worry about what features fit into a PI, we just use them to guide the discovery process, better understand what is possible, and what a Minimum Viable Product (MVP) might look like.
By the third sprint, our initiative team is far enough along in discovery to create the first draft of our Roadmap for the next quarter. We review the top priority features and work with tech leads and Product Owners to get basic t-shirt sizing of the top features.
In sprint four, the train has an all hands meeting we call the “Why meeting”. In the Why meeting, Product Managers review the discovery process and how it lead to the priority Initiatives and features for the coming quarter. We review the roadmap together as a train, and receive feedback for the 2nd draft. Product Owners and Development Managers work with the initiative team owners to review the feature estimates again and discuss them with development teams.
In the fifth sprint of the PI the whole train kicks into planning mode. Teams are using some of their weekly planning session time to break features down into stories. User Experience works closely with the teams at this point to share mock-ups and information about customer interviews, and help with story creation and acceptance criteria. With stories emerging, refined estimates aid in the 3rd draft review of the roadmap. If teams find themselves moving quickly or with spare time, they may even start estimating and prioritizing stories.
The sixth sprint is really two one-week sprints. The first week is Hackathon. Hackathons deserve their own blog post, but the gist is that this week gives developers an opportunity to explore work they consider top priority. At the end, we demonstrate to the release train the value add and how it might fit into our roadmap. Hackathons are essential to our process and success. We have had new products, top customer requests, and award winning features come out of this time. Hackathons also add to the pride we have in our product and the energy needed to have a successful BRP.
During hackathon, the initiative team leads continue to refine and define work, answering questions and resolving any issues and gaps that were exposed during sprint five.
Big Room Planning
The second week of sprint six is dedicated to PI Planning, aka the BRP event. Monday and Tuesday teams continue the work started in sprint five to be as ready as possible for the event, which takes place Wednesday and Thursday. The outcome of the event will be a finalized product roadmap, committed features and prioritized stories for quarter starting the following week.
In part two of this series, I dive deeper into the details of what happens the week of BRP. Check it out too!
We want to know what your planning calendar looks like!
What do you find most helpful in your planning process? What are your biggest planning struggles?