Scaled planning, including slicing and master planning, is a pragmatic approach to help you with your scaled planning challenges. Scaled planning uses the organization’s overall Strategic objectives (the target in the middle of the illustration) as the starting point, and from there involves four levels of planning:
Big room planning
While the various scaled frameworks provide a useful framework for the quarterly big room planning, where all teams and stakeholders get together for a couple of days, and while most organizations know how to do sprint planning, many struggle with getting 100% ready for the big room planning. This is where scaled planning with 1. slicing and 2. master planning comes in.
Let me start by sharing a story.
I was consulting with a program in a ministry working on an important new system for the Danish government. When I got there, they were organized in “offices” after competencies, so we had the lawyers in one office, business process in one office, IT in one office, and so on. There was some collaboration across the offices, but not enough to reach an agreement on epics and what to build first.
We managed to reorganize most of the people into cross-functional teams. Then we ran a “use case camp” (described in article 2 “Slicing and understanding together”), which gave us the epics – the platform for our big room planning.
At first, everything seemed really great. We gathered all members from the new cross functional teams for big room plannings every three months. They coordinated work and dependencies, and the development started to take shape. It felt great…
Until one day, when during a big room planning the program director presented his updated view on the minimum viable product (MVP) to be delivered at the end of the next quarter. There were so many questions and not many clear answers. Then, to make matters worse, the head of business processes took the stage to make some clarifications, and she told a totally different story. It did not match the program director- who by that time, had left for a different meeting-’s MVP vision.
Having no luck with talking the program management into getting the teams to deliver something to the end users within a few months to get a victory and to get the feedback loops going, I decided to leave. Having followed the program on the side ever since, I know that these 4-6 teams have spent more than a year battling these unclear goals. Without a single delivery to the end users. Without any feedback loops to help them navigate towards delighting their future users.
And there are so many stories like this. Stories about talented people getting together to build great products, and then ending up with very low productivity due to lack of clarity, due to the absence of a common direction, due to the absence of a master plan.
So why do we do master planning? We use master planning as a driver for getting key stakeholders to agree on one common direction, which help the individual teams to align and work better together.
And by the way – last time I talked to my friends at the government program, they had decided to make an actual delivery within a month. Finally!!
I will let you in on a secret. Running a master planning can be really easy, once everyone has a common understanding of the rightly sliced epics and once you get the right people in the room.
Before getting started, I strongly recommend having each epic on one card (A4/letter size). With the name of the epic in large and bold writing so everyone can read it from the other side of the room. And I recommend having a limited number of details on each card to keep the overview and the discussions at a high level (saving the more detailed discussions for the teams later in the Big Room Planning). See “Withdraw Cash – USD” example.
Next, set up the room with one long table: long enough for all the epic-cards to be placed next to each other – and no chairs, because we want people to be able to walk “up and down the plan” at the table.
On a side note, some might suggest that withdraw cash is too small to be an epic. That all depends on the size of the entire program – and in this example withdraw cash is one of around 25 user scenarios, and then it works fine as an epic. If withdraw cash was one of eg 100 or 200 user scenarios, then you would have it as a feature in an epic, maybe with the name “handle cash”.
And the right people are:
When you have the above in place, you’re ready for your master planning. And then you should go for it. Rather than waiting and trying to become even more ready, which I’ve seen a lot. The thing is, that while there will always be more you can analyze and prepare, chances are that there will still be things you’ve missed, and you will never know exactly what those things are until you go ahead and run your first master planning.
It is important to have the product owners and the Scrum masters participate in the master planning. Both because they have a lot of information that should be included in the planning, and because they will have more ownership of the master plan when they have been involved and engaged in creating it. In addition, they will get a deeper understanding of the entire program during the master planning. An understanding that is not just important to bring into play during the Big Room Planning and Sprint Planning, but certainly also in their day-to-day work in the individual teams.
We also take advantage of different opinions about what is most important when we have representation of all the roles as part of the master planning. These differences can, if not dealt with and agreed upon in this forum, create a lot of harm when it comes to how efficient teams can work and the subsequent value that is created. If the stakeholders send mixed signals – if they try to work their own non-matching agendas – the teams will end up spending a substantial amount of time trying to figure out who to please internally, rather than focusing on developing products or services that make the customers happy.
Let’s get into the meat of the master planning. It includes these three steps:
Sometimes I switch the order of Estimate and Prioritize around, particularly when we have too many epics to cover in the time set aside for the master planning. In that case, it makes more sense to mainly/only estimate the most important epics according to the prioritization.
In this first step, we want the participants representing the people actually developing the services to be in the driver’s seat. We will call them the “delivery people”. They are the ones who will be doing the work, so they know best how much work each epic will take to develop (typically, they are Scrum masters, architects, test managers. etc.).
In this step, we want to have a substantial discussion about each epic . That is one of the reasons why I recommend relative estimation. Relative estimation seems to guide the discussions away from comments like “Really? How can it take you that long to…?”, and more towards substantial discussions about the essentials of the requirements and how to build the solution.
At the master planning, we typically do not have enough details for people to feel comfortable about estimating in numbers. Therefore, I suggest using t-shirt sizes (S, M, L, etc.) which seems to work better. We can always agree on a conversion from t-shirt sizes to estimation points toward the end of the master planning to be able to calculate the planned and actual velocity of the entire program, as a part of the program governance.
Apart from my comments above, we estimate by using this commonly known Scrum estimation process (you can skip this part if you know the planning game already).
The above seven steps can take forever, unless it is facilitated in a fairly strict manner. Timeboxing works great. My favorite way of timeboxing is to just time the first two to three epics, do the math and share it with the participants. A typical question from me could be: “We have now estimated the first two epics. It took 1½ hours – and if we continue at that pace, it will take us three days to estimate all the epics. Do you want me to help you timebox?”. The answer has always been, “yes,” and then I typically set a timer to 10 minutes, which speeds things up.
Remember, this is the overall planning. We do not want to go in much detail, because we want to get the overview and because we want to save the more detailed planning for when all the people, who will actually do the work, are present in the Big Room Planning and the Sprint Planning.
In this estimation process, it is very normal that some epics are split up – and that other epics are clustered into one epic. It is also very likely that some foundation/enabler epics (also referred to as plumbing or architecture epics) are identified and described. I suggest using different colored cards for enabler epics to make it easy to distinguish between business epics and enabler epics. That comes in handy in the next step: prioritize.
In this step, we want the business to be in the driver’s seat. They are the people knowing the customers and the market best, and therefore the best at deciding what to build and release first.
This is quite simple from a process perspective:
While prioritizing is simple from a process perspective, it can be very difficult to get to an agreement between business and delivery people, and especially to get agreement between different business stakeholders. One of the pitfalls we sometimes see is that these fundamentally different priorities are not sorted out, and thus they get to exist, confuse and delay (sometimes even destroy) the entire program.
This is where the facilitator needs to be strong, and get the parties to discuss and negotiate until they compromise and find common ground – so that the master plan serves as a clear direction from the key stakeholders to everyone else in the program.
I remember a situation in a master planning in a bank where the head of retail banking complained to me: “I know how to prioritize my own epics, but how can I prioritize them up against the corporate banking services?” I did not say a thing. I just looked over his shoulder towards Peter, the head of corporate banking, who was in the other end of the room. After a lot more complaining he stopped, then he was quiet for a bit while his wheels were turning. Then he suddenly said: “Ahh, I can just go and talk to Peter. We need to agree on what’s most important for the whole bank.” Bingo!!
In this last step, we’re back to having the delivery people in the driver’s seat since they’re the ones actually building the products or services. The big question here is: “How far do we think we will be after the next three months? And then after the next three months?”
We ask people to base their answers on everything we’ve talked about so far, on their prior experience, on what they know about the program capacity and on their gut feeling.
This step is usually less structured than the first two steps, but if there is a structure, it might look like this:
A little warning: when assessing and estimating how far we believe we can get quarter by quarter, it is essential that the people who will be doing the work drive these decisions. They are the ones who know, and therefore, they should be the ones pulling work into the upcoming quarters, based on how far they believe they can get. This way they get a substantial amount of influence, and therefore also ownership for the plan.
Pushing work into their plans by management or other stakeholders usually has the opposite effect: less ownership and also less realistic plans.
I am often asked about how far out in the future a master plan should cover. In my opinion and experience, it is beneficial to put everything we presently know about in the plan, and let that guide the timeframe of your master plan. In this way, we use the master plan in our discussions and coordination with the organization around us, including governance/PMO, who need to know to be able to plan ahead in the bigger picture. I do, however, suggest to be less and less detailed in the plan, the further out in time we go. We will be revisiting the master plan once every quarter, so when we get closer to future epics, we will have time to go deep enough to provide clarity for the program.
You now have your master plan that will give the rest of the program clarity about what to dig deeper into in the upcoming Big Room Planning and the Sprint Planning sessions, as well as all the day-to-day work.
If you convert the T-shirt estimates to numbers as shown on the illustration “Program burn up”, then you can easily make a visual overview of your program progress. I prefer to call these points “program points” to distinguish them from the planning poker points that the teams are using in their estimations in the big room planning and the sprint planning.
In this example, we had identified 7 epics from the beginning of the program, 3 blue, 2 red and 2 green epics. With the converted estimates, they total up to 150 program points, and we expected to finish the work in 3 quarters. On average we should do 50 points per quarter, but in Q1 we only did 30 program points. During Q2 we got back on track – and something else happened. We discovered two new yellow epics, both estimated to be large. So at the end of Q2 we believe that the total size is 190 program points.
Some prefer to add up all the detailed planning poker points from all the teams to get the overview of the program progress, which is possible; at least in theory, it is possible.
If you have a hard time collecting and adding all the planning poker estimate numbers up, I suggest that you try this T-shirt and conversion method, with these advantages:
When you have been through the slicing and understanding together, you are ready for the master planning.
Getting ready for the master planning – the practicalities:
Pragmatic Agile support aligning purpose and ways of working to anchor change.