Streamline Health takes its scrum and Scaled Agile Framework ceremonies very seriously. Adherence to norms and best practices by everyone involved helps our development machine run smoothly from sprint to sprint, release to release. While we try hard to give our smart, dedicated engineers the freedom to problem solve, innovate, and enjoy their work, we expect them to participate and be committed to a specific set of ceremonies.
That’s right, ceremonies. Not meetings.
Meetings are boring affairs designed by someone to meet a need that’s important to them. Agile is all about collaboration and meeting team needs and goals. Meetings, to the agile team, are so five-minutes ago.
Ceremonies are about recognition, achievement, and a little bit of showmanship. Let’s take a moment to recognize our success and share it with our stakeholders. Let’s focus for a few minutes on how our collaboration is going and how we can improve it. Ceremonies are interactive, and they are essential.
In the next few posts we’ll describe the ceremonies that we rely on to move our work forward and out to our clients.
Planning Increment (PI) Planning
PI Planning is a Scaled Agile Framework ceremony designed to align all of your teams at regular intervals. The goal of a planning increment is always a software release.
The key word in this cycle is “planning.” We plan for the next four sprints, with the goal of a minor or major release at the end. As the planning increment proceeds, the teams for a given solution might identify a need to do a mid-cycle release. That’s okay. And sometimes you plan to do incremental small releases each sprint. What matters is that you made the plan and everyone was informed, so as you deviate, everyone knows you’re doing it, and why.
The deliverables from PI planning are refined features, refined and estimated stories for the first sprint for each product, and identified stories for the rest of the sprints in this PI. Included in this is determination whether a feature is too big to complete in one planning. Dependencies are identified and, if possible eliminated. Architectural needs are also found and added to the plan through the creation of user stories for them. Perhaps most importantly, we determine how much of our capacity to allocate to each product. If a product has six sprints of must-do work, then we need to put two and a half teams on it. This is where those corporate goals and initiatives come into play. We have four teams, but five products, so we can’t go full steam ahead on all five during every planning increment. Which products get the focus is based on corporate initiatives.
That’s an Expensive Ceremon!
Everyone in the development organization, plus SMEs, participate in PI Planning. At first blush, it looks too expensive – in fact, we did not immediately implement it when we adopted the Scaled Agile Framework. We could not justify spending that much time every fourth sprint when some of our product teams were struggling to close functionality gaps that clients were screaming for. As we improved our product quality and made our development plans more transparent, the need to regularly coordinate work across teams emerged. Our senior management embraced the opportunity to set the direction of development and have their goals enacted. Suddenly it was worth it to stop and look ahead for a few hours every fourth sprint.
Making the Plan
Prior to the PI Planning ceremony the requirements teams develop high level business requirements and refine them into features. These requirements represent where the organization wants the products to go in the next three months. Input from all stakeholders – from sales to support – is taken into account. By the time of the ceremony, we have five plus or minus two features for each active product, with one or more user stories, conditions of acceptance, and technical notes. The product managers have determined their priority, and also taken a stab at high level estimation (t-shirt sizes). We have no features for products that are not currently in corporate focus. We will continue to support those products by fixing troublesome bugs and even do small enhancements that will delight existing clients, but we won’t allocate much bandwidth to them.
Everyone in the Innovations organization is included – every coder, tester, intern, documentation specialist, business analyst — everyone. We have two offices and some remote people. We set up video sharing in a large conference room in each office. If a remote person wants to turn on a camera they’re welcome to as well. The ceremony is scheduled for half a day.
We kick off PI planning with a brief keynote from our VP of Innovations. This keynote recognizes successes from the previous (actually, current at that time) planning increment and includes any recently closed big deals and any that are imminent. The idea is to place our ultimate goal – selling software – at the forefront of everyone’s mind as we dive in.
Next each scrum master provides a short update on her team’s big wins in the last planning increment. He also introduces any new members and announces any other changes of that nature.
The product managers then each present their proposed roadmap for the coming increment. No matter what product a team usually works on, they hear about it all.
Once everyone has an idea of the plan, the teams break out by product to dig in on the features. One of our teams has, so far, only worked on its main product. The other three have all worked on a main product as well as our newest rising star. So two or all three of those teams will break out together to look at the features for that product. If there are features for their other product as well, then they’ll allocate some time to those during this first day as well.
As the first day winds down, the product managers start asking the teams whether the plan is feasible. We ask them to come up with sprint estimates (see Estimation) on the features. We ask them for a vote of confidence on the success of the planning increment. At this point it’s still a little early to know for sure, but a very low confidence now will send the product manager back to the drawing board to look for ways to reduce scope before day two.
We spread the two halves of PI planning out so that there’s time in between to fix issues with the roadmaps that the teams have raised and to hold the executive roadmap review. The product managers present the roadmap as revised from day to our executive stakeholders. We ask for approval to proceed with this plan. Sometimes an emergent client concern can disrupt the roadmap at this point. The product managers try very hard to be aware of the potential for this before getting to this stage, but it can still happen. We’re agile, right? We love change.
The video is back up and lunch is on the company as we gather to go deeper on the features and stories. The teams decompose features into stories and draft conditions of acceptance. They haggle over details of scope. They think about the “how” and argue over architecture and design. Product managers and other leaders continually moderate to pull them back out of the weeds when they start slashing and hacking with their .NET and C# and Machine Learning machetes.
Once again, as the half day winds down we ask for a vote of confidence on the planning increment. By now the teams should have a very good idea of how the work will be spread out over the next three sprints and whether it is achievable. But as before, if we don’t get fours and fives we discuss and adjust.
The final stage in this long ceremony is a retrospective on the event. Everyone is able to analyze any aspect of the event, from the duration to the food to the progress that was made. We look for items to do better next time. We’ll talk more later about retrospectives in the entry for that ceremony.
PI Planning occurs early in the last sprint of the previous planning increment. This gives us time, once the dust settles and the rooms are tidied up, to clean up those hastily written requirements. If a team used index cards or sticky notes, someone has to transcribe them into our system. There might have been requirements questions that couldn’t be answered during the ceremony, so our requirements folks get to work finding answers.
PI Planning doesn’t completely replace incremental backlog refinement. It kick starts the first sprint and informs the entire increment. More importantly, it instills a larger sense of purpose in every member of all the teams, and creates visibility across the portfolio.