Scaling Agile - Master Planning Together

In the first article, Scaling Agile - a real story, I shared a true scaling agile story from a particular program.

In the second article Slicing and understanding together, I described the importance and the how-to’s of slicing your requirements into potential releasable epics. So now we’re ready to build on top of those slices and that common understanding; we’re ready to do the master planning together.

Before we dig deeper, let’s get the context in place. I am explaining this as a part of scaled planning (you can skip this part, if you have already read the first articles).

Scaled Planning

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:

1. Slicing
2. Master planning
3. Big room planning
4. Sprint 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.

Why master planning

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!!

Getting ready for the master planning

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”.

In short:

• Your epics printed on cards, big enough for everybody to read the headline from across a table
• A room with a table long enough for all the epics in a long line
• One set of estimation cards for each person with t-shirt sizes; S, M, L, XL, etc.

And the right people are:

• Key-stakeholders, including the teams Scrum masters and/or product owners
• Preferably the same people that participated in the slicing and understanding together
• Between 6 and 12 people is a good number

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.

Why have the product owners and Scrum masters participated?

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.

Why is it important to get all important stakeholders to agree?

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.

The how-to’s of master planning

Let’s get into the meat of the master planning. It includes these three steps:

1. Estimate
2. Prioritize
3. Decide epics per quarter

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.

1. Estimate

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).

1. Identify a Small Epic: driven by the delivery-role people – we agree on a fairly small epic – and set the estimate to Small.
2. Choose Next Epic: a business person chooses the next epic, reads it out loud – and adds what she is thinking about the epic at this point in time.
3. Discuss Epic and Solution: delivery people talk about how they will build this epic. They get comments and questions from the business people, they discuss and agree, and add notes – typically about what to demo – on the epic card. Also potential epic-specific risks are marked on the epic card. I prefer to use a red marker for this.
4. Estimate Individually: delivery people take their t-shirt estimation cards, and individually decide how big this epic is compared to the Small epic from step 1 – and when everyone has decided, they turn and show their cards.
5. Listen to Smallest and Largest: if there is disagreement, the person with the smallest estimate and the person with the largest estimate share why they think the job is so small or large – and then we do step 4 again.
6. Write Down Estimate: when there is good enough agreement, then the estimate is noted on the card.
7. Do It Again: go back to step 2 and continue until there are no more epic cards to estimate.

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.

2. 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:

1. Order business epics: the business people talk the epics through, and order the cards in the priority they want the epics delivered. This will probably mainly be based on business value, which we sometimes quantify, but more often not.
2. Consider risks, dependencies and enabler epics: the delivery people listen, ask clarifying questions, and usually suggest rearranging the order of some of the epics. These suggestions are often based on epic-specific risks and dependencies between epics. Typically, they also suggest where to place the enabler epics in order to build the foundation for the business epics in time. And often they identify extra enabler epics – triggered by the deeper understanding they’re getting from planning together with the business people.
3. Change the order – or not: the business people engage in this discussion with the delivery people, and then, the business people decide if they want to change the order based on the discussions and on the business priorities. This is where it is important to remember that the business people are in the driver’s seat, so while the delivery people might suggest some changes, the business has the final say.
4. Walk the plan: when things seem to settle, we “walk the plan” together. Everyone gathers close to the early end of the plan (the first prioritized epics), and then a business person tells the story about why those first epics are most important, and then the next epics, etc. – while everyone walks with her down to the end of what we have planned so far. The walking is quite often disrupted by some new insights, discussions and decisions, in which case, some of the earlier steps are repeated before we do the next “walk the plan.”

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!!

3. Timing with epics per yearly quarter

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:

1. Decide which epics go in the first quarter – and set a date and time for the first demo.
2. Discuss whether this is okay from a business perspective, and split up and consolidate epics until it is okay from a business perspective.
3. Decide which epics then go in the next quarter and so forth, until we have laid out all the epics we know according to a time perspective.
4. Do the sanity check of the plan, meaning check that no quarters have significantly more (or less) work in them than others. This is where the conversion between t-shirt sizes and estimation points come in handy for converting and summing up the estimates for all epics in each of the quarters. Usually, this leads to changes in the ambition levels of some of the quarters.

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.

Program governance with burn up diagrams

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:

• You can get a handle on your program progress very quickly, since it mainly involves information from the key stakeholders as opposed to every single team member in the entire program
• The teams can keep their planned and actual velocity for teamdiscussions about improving the way of planning and working on the team level

Summary

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:

Running the master planning:

Next article

Now that we have covered the slicing and the master planning, we are ready for the big room planning, which I will cover in my next and last article in this series about making scaling Agile work. I will share my experiences and do’s and don'ts, and I will share the tips and tricks that I have learned the hard way. Stay tuned.

About the Author

Ole Jepsen is an Agile transformation advisor working with organizations looking to lead change. Using his expertise in Agile methodologies, Intent-based Leadership™ and facilitation, Jepsen works with companies and leaders to create development organizations and workspaces where people thrive and deliver value.