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:
There’s a lot of skepticism out there about big room planning. The questions I hear over and over again are “Really? Is it necessary and worth it to have everyone spend two days every quarter to plan? And how can it even function with up to 100 people or more to plan together?”
Once you have tried it, you know the answer to those questions: yes, it works. Very well actually. And yes, it is worth it. I’ve seen this way of planning save programs from big time failure. Several times.
Let me give you a couple of examples.
The first is about the Mifid program that was in deep trouble delivering anything. Then they started to organize themselves differently and they also started to plan in a far more involving way than before. And now they’re back on track. This is the story in the first article Scaling Agile – a real story.
A more recent story is about a program I was consulting with recently, who is developing an app for its customers. The program consists of three teams: Digital, IT and Retail. The program has been working on this for around two years, and have, up until a few weeks ago, only delivered a two-week pilot with 50 customers.
When I started with the program a few months ago, I heard a lot of “but we do not know what they’re even thinking in Retail” – and “are any of the Digital people actually doing anything – I have no idea” – and “how come things take forever in IT – it’s just an app?”
After a couple of months and several master planning sessions with people from each of the teams, people finally stopped talking about all the reasons why we would never make it. They started talking about what it would take, and managed to slice and prioritize some epics, some potential releases.
The teams were still reluctant to prioritize time to talk to each other. They were busy with their own stuff. IT, who is building the app, wanted to stick to their Scrum processes, their sprint goals and not jeopardize their planned velocity. They had no interest in the content of the app, that Retail struggled with, and no interest in the design and the look and feel, that they called “glitter.” They saw these things as someone else’s job. They were building a car without a motor and without a way to get gasoline.
I managed to get them all together for a big room planning. Each of the teams broke down the epics into maximum two main tasks per team, per week. They also created a program board, and discussed the dependencies between tasks and people. Towards the end, someone from IT suggested to meet every morning at 9:15 to hear what the others were working on and to coordinate. Many people were thankful after the big room planning – they had a good time and said how great it was to finally have some meaningful conversations with people on the other teams.
Just two weeks after the big room planning, we were ready. The app had been submitted to the App- and Play Stores and the customers were starting to download, use and benefit from the app.
So, back to the questions about big room planning: Is it worth it? Can it work?
One last argument: two days every quarter is 3.3% of people’s work time – no matter how many people you have in your program. So if big room planning gives you more than 3.3% more productivity in delivering value, then big room planning is a good investment.
Big room planning in short
Big room planning is two days of planning together with all program and team members every quarter.
Based on the master plan and the program goals, all teams are talking through how they each will contribute to reach the program goals during the next three months.
They do that by breaking down the epics from the master plan into features, discussing, estimating and prioritizing them and giving their best shot at how many features they can achieve each of the next four 2-week sprints.
Several times during the two days, teams gather by the program board and post and discuss their individual features. They discuss the overall picture, sort out the dependencies and move features around to build the best possible overall plan.
Towards the end of the two days, team and program objectives for the three months are agreed upon, and risks are discussed and mitigated.
As the “scaled planning” illustration shows, you need to get your slicing and your master planning right to get a successful big room planning.
Also – to get completely ready – you need a few more things:
Getting the right room and set it up
While this is a part of the above “Getting ready for the big room planning”, the room is getting its own paragraph. The reason is that this is both very important and yet often not getting enough attention from organizers of big room planning sessions.
The physical setup can make or break the big room planning, so please take it seriously:
Finally, the big day has come. This is the morning of day 1, and you’re in the room at least one hour before the program starts. Maybe two hours, if you did not setup the room the day before.
I suggest doing a final briefing with your fellow facilitators and key stakeholders, who include the program leader, a program architecture responsible person, and business stakeholders (those representing the employees and/or customers, who will benefit from the product developed by the program), to run through the program and the roles one final time.
I also suggest assigning named facilitators to the teams, so each team is only/mainly getting support from one facilitator, so that the support and advice will be more consistent than if they get it from different facilitators.
Make sure that you finish this last-minute prep in time for you and the other facilitators to greet people when they get there and show them to their tables.
We’re here to make a plan for the next three months, where the program wants to achieve XYZ.
If this is one of the first big room plannings in the program, then I recommend making it clear that most things will probably go well, and that there will most likely also be some hiccups during the 2 days. And that you hope that everyone will be forgiving and see those as learning opportunities – something to improve for next time.
The XYZ is the helicopter view on what’s in the master plan for the next three months, not just the individual epics, but also the purpose and a brief description, the essence, of what is planned. So this is reminding everyone of “the big why”, which is the purpose of the program as a whole). And equally important, sharing “the smaller why”, which is the goal for the next three months.
Present/remind people about the (updated?) program vision
Here we want to get a key business stakeholder to give a pep talk, to remind us about why we’re here. To explain why the program strategic objectives are (still) important for the business and for the company as a whole. Storytelling is better than Powerpoint for this, and even better if we can get the stakeholders to tell his own story about “why this is important to me personally.”
Remind everyone how far we are with the solution, by giving a brief live demo of the actual product, or by having a visual overview over what has been delivered, and what is still missing. Also repeat the architectural guidelines, and share the newest changes of the technical foundation.
Have everyone get up, and “walk the master plan” together while explaining it. Spend most of the time on the next three months. Also cover the following quarters, just to remind people about what we’re not working on now – but spend less time on that.
Which teams have stakes in which epics
The best way to explain this is by repeating a small part of the first article in this series “Scaling Agile – a real story.” We enter the story at the 2nd big room planning, where we’re trying a different approach than at the first big room planning, where each team chose the epics they thought belonged to them, with little or no discussion with the other teams about it.
“Then the teams gathered around the epic overview board, and this time we asked them to think about all the epics in which they played a role, even if it was a small role. We then got everyone to put a small colored sticky note representing their team on those epics (see illustration Epics & teams II). After one hour, we had an overview of which teams were primary drivers on which epics – and which other teams were also involved in each epic.
It surprised us how powerful this was. There were a lot of people standing by this board, coming and going throughout the two days, and it was usually people from different teams having a discussion about what they needed from each other. How they could help each other?
Explaining the specifics of the teams breaking down epics into features, and estimating and prioritizing them
Reminding people about the remaining agenda for the two days, and presenting all the details of the process. I usually include things like:
Simply let people follow the instructions from the Team breakout intro. Make sure, that the teams get the right amount of attention from the stakeholders and facilitators. Not too much to disturb them, and also enough to give them the guidance they need.
Teams post their initial plans on the program board and start coordinating with other teams
Give teams a 15 to 20-minute warning before the first gathering at the program board. Ask them to write a Post-it for each of their features, but for the program board without the description in order to create a cleaner and better overview.
When the time is up, get everyone up by the program board, and get one from each team (probably the Scrum master or the product owner) to place their features in the sprints where the team thinks it belongs.
You might need to encourage a discussion about dependencies between the teams and features, but chances are that the teams will start discussing this without your help, when they have it in front of them.
Help visualize the dependencies by connecting features that are dependent on each other with red string. Encourage teams to finish discussions about dependencies on the side once the dependencies have been identified, unless it is a dependency that involves all teams.
A tip: have the first gathering by the program board earlier rather than later- no later than a couple of hours after the first team breakout starts. You will probably get some resistance from the teams, because they do not feel ready yet. If you wait too long, you will not get the cross-team collaboration you get if you do it early. It is amazing to see how teams are cross-pollinating a lot more after the first program board gathering.
Team breakout and program board discussions are repeated – typically 1-2 times before the final program board gathering. Remember to gently force them to meet by the program board every 1-2 hours – even when they’re not feeling ready in the individual teams. It will nudge them to collaborate and coordinate more across teams.
Continued from day 1, while teams are encouraged to coordinate with other teams and stakeholders
After this team breakout, you should start to see the outline of plans for each team. If they have not put their features up on the team planning posters yet, now is a good time to get them to do that. It makes it easier for the teams to understand what the other teams are planning, when they visit each other.
Finalizing the program board with all teams’ features and dependencies. Remember that the plan just needs to be good enough. It will be revisited every day, and details will be sorted out later.
Teams are bringing up risks, and they are discussed and mitigated in the plenum. Some risks result in a mitigation activity, which we want to go on a team’s plan and/or on the program board, so we do not just talk about it, but actually do something about it. Other risks are just accepted. Spend most of the time on the top 3-5 risks, and just list the others for now.
Teams formulate their essential business objectives and then the program objectives for the 3 months are agreed upon.
In a program with many teams, opinions, epics and features, people often need help to navigate and remember what the overall purpose is.
To help with the navigation we get teams, guided by the product owner, to describe a few overall goals for the three months. Then we ask the product owners to get together with the business stakeholder(s) to discuss and agree on a few program objectives for the three months. The fewer and shorter the objectives are, the stronger they are in order to help the entire program navigate towards a common goal.
Here’s an example of a program objective from a program, that really struggled to go live:
“Run on live data”
On a scale from 1-5 – how much does each team believe in their plans
As a final test, we can get the Scrum masters for each team to ask the team members about how much they believe in their team’s plan, and possibly also how much they believe in the plan for the entire program, by a show of fingers up to 5.
I suggest that you only do this if you follow up with a discussion about why the numbers are not higher, and most importantly, how the plans or circumstances can be changed, so that people can believe more in the plans. A good question is: “What would it take to get you closer to a 5?”
Usually the next step is for the teams to make a sprint planning, and then get going on the work.. Also talk about which other things will happen in the near future, and remember to thank everyone for their time and corporation.
Reflecting over the two days of the big room planning
Remember the opening comment about potential hick-ups during the big room planning?
This is where you gather input for how to make it better next time. My personal favorite is asking people to write the following on a Post-it:
Get people to put them on the door on the way out. Take a picture when everyone has left – maybe read them, but wait until you prepare your next big room planning before you think much more about it. At this point in time, after two days of big room planning, your brain is probably fried, not able to reflect rationally anyway.
If you want to harvest the benefits of the big room planning and keep up the good cross-team collaboration, then I suggest that you have a Scrum-of-Scrums by the program boards every day after the teams’ standup meetings.
The agenda is the same as the standup meetings, except at the Scrum-of-Scrum the sharing is for each team rather than each team member.
As the facilitator or program leader, you might want to end each Scrum-of-Scrum meeting with one of my favorite questions:
What can I or others do to help you achieve our program objectives faster?
But only ask that question if you’re willing to gather those impediments and get them out of the way. I like to refer to this as impediment busting, because it sounds more cool and powerful than stakeholder management and risk mitigation.
Big room planning provides an overview of all the work to be done in the next quarter. It’s two days of planning together with all program and team members every three months.
Ensuring there is a common understanding of the overall direction using a master plan is a must in order to realize the goals of the big room planning.
Facilitation plays an extraordinary role in the success of the planning. Make sure you have skilled facilitators and a room that is large enough to hold people, tables, planning boards and all the materials needed to make the plans and dependencies visible.
Finally, as with any agile practice, pausing to reflect on what went well and what to improve in the next big room planning is invaluable.
Next time you find yourself in a program with more than 2-3 teams, try this out. Set a date for a master planning and a big room planning a few weeks ahead, and then invite people and start getting ready. Set it up as an experiment, if there’s too much resistance.
And if you have already tried a big room planning and been disappointed, give it one more chance. If you follow the tips of this and the other articles in the series, I am sure that you will have a better experience next time.
Maybe you will even end up like Martin, a program leader on a CRM program in a bank I am working with at the moment. After a master planning and a big room planning that we ran the last couple of weeks, he said “I am in love with scaled planning. Before we were wasting millions supporting processes that the business didn’t care about. And we didn’t even know. Now we are aligned and creating value for our customers again.”
And then he added “We should have done this sooner.”
This article concludes the series about Scaled Planning, consisting of the following articles:
I hope that you will share your thoughts about these articles, try out the tips and tricks – and finally, that you will let us know how it goes.
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:
The only right way to start a new development effort is to get slicing and a common understanding in place – and it is very difficult to do.
Perhaps you might think you have it in place, and then you start planning and developing, and find out that actually you did not have a deep enough common understanding. What I’ve learned over the years is that the only way to find out if you’re actually ready for planning and developing is by starting planning and developing. And chances are the first time(s), you’re not ready.
That’s okay, or at least it is very normal. Then you know that for next time. You have learned something. You’ve also created awareness for everyone that we need to spend more time and effort on this next time.
Let’s go deeper into what we mean by “slicing.”
After we have an overall idea of the value we want to deliver, it’s time to break up the work into smaller chunks that we call epics; it’s time to do the slicing.
And just like there are many wrong ways to cut a cake (horizontally, too big/small pieces) – and only one right way (vertically from the center out to the edge and down), there are also many wrong ways to organize the requirements, and only one right way.
There are (at least) three ways people break down a system into epics:
In summary, we want a breakdown of all the work in smaller pieces. We call the pieces epics, and we want each epic to be one slice of the system.
Waterfall is a step-by-step approach with handovers between parts of the project. Here’s an example, a waterfall way of looking at developing a new ATM:
This is not the way to go.
Don’t get me wrong. All of these things are relevant and important. And often we need to do some initial thinking and shaping the product before we start building it. Some refer to this initial work as ”sprint zero.”
However, the above is a list of activities, not a list of things to develop to create customer value. Experience (and Agile) has taught us that having ”pieces of things you want to develop to make the customer happy” serve as the best possible building blocks for our planning, the best possible drivers for our work. A focus on making our customers happy is the way to go. During our development efforts, we will then be able to do the necessary amount of analyzing, designing, testing, kickoffs, etc.
Here’s another way of looking at the planning. This is a more ”what-do-we-need-to-build” kind of plan.
This is also not the way to go.
Despite the fact that the above are all ”chunks we need to build/develop,” they are still not a good way of breaking down the work we need to get done. Why? Because none of the above chunks are, by themselves, making any customer happy. By following this strategy, we could build the most wonderful user interface, have the users check it out and maybe even love it, and then later find out that the bank-systems we’re hooking up to do not have the information we needed for the user interface. Or we could create a state-of-the art database structure and connect it to the bank backend systems with great interfaces, and then build the user interface and find out that some piece of information that the user really, really wanted to see (e.g., which ATM did I last use or which amount did I withdraw?) was not stored anywhere.
Again, don’t get me wrong, I know that all of the building blocks in the above list are necessary to develop, but they are not the best building blocks for your planning. They are ”layers” in the architecture – and a layer by itself does not make any customer happy.
Henrik Kniberg’s wonderful illustration is one more way to see why Layers (or building component-by-component) is not the way to make your customers happy.
Finally, here’s a third way to look at ”what to do.”
This is what we want!
A good way to get to this way of slicing is to have “Who will use the system, and what will they be using it for?” as driving questions throughout our slicing.
This is the kind of break down that makes a good plan. Each of the items on this list is something that can make a customer happy. And they are, to a large degree, independent so you could develop one of them and release it, and fulfill a customer need.
Organizing what you want this way enables you to have the best possible basis for making a plan that drive your development efforts towards ”making our customers happy”.
Again – Henrik Kniberg’s illustration provides one more way to understand why slices can help us find out what to do to make our customers happy.
Refer to Kniberg’s blog if you want the full story: making sense of mvp
Now that we have covered the importance of slicing right to deliver value to our customers, let’s focus on how to slice, and at the same time build a common understanding. Here’s the how-to’s that we will cover in the reminder of this article:
First of all, never have someone write the requirements on their own. In order for the slicing to produce a good starting point for the master planning, it is critical that there is a common understanding of the content of the epics.
As shown in illustration Two People at a Whiteboard, we know that the best possible way for humans to understand each other is when they’re face-to-face, for example by a whiteboard.
The illustration Understand Together shows two different ways to represent an understanding. To the left, the understanding is in people’s brains. To the right, the understanding is written in a document. It is infinitely more efficient to start by helping people create a common understanding in their brains by talking, discussing, illustration (Two People at a Whiteboard) – and then write down what they agreed (going from left to right).
In our experience, the right number of epics – where each epic is one slice of the system – seems to be 20-30 regardless of the size of the system. If you have fewer, you’re probably not deep enough in understanding the requirements.
If you have more, you likely have too many details at this point, which will make your master planning confusing, not creating the overview you want. In addition, it will not leave enough space for decision-making for all the people in the big room planning – thus jeopardizing the feeling of ownership from the people who will actually build the product.
Epics in a larger program will be bigger than epics in a smaller program – and that is completely okay. In both larger and smaller programs, having 20-30 epics has proven to work best.
So if you have too many and too small epics, you need to cluster some more detailed epics into one bigger epic. Story mapping, described in the first article in this series, is a good technique for that.
If you have too large epics, you need to slice them thinner. One example of a thin epic in a travel booking system is a limited early epic that only allows you to book travel if you want:
While there is always some groundwork before you can get the first actual release out to your customers, this way of thinking minimizes the amount of groundwork, and also minimizes the time until you can get your first actual feedback loops going, making it possible for you to know (not just think, but actually know) whether you’re on the right track to delight your customers.
In the above example, we would actually build and release the solution specified, with a very small amount of potential business, but with a potential goldmine of learning opportunities via feedback loops from the actual use of our system.
Agile and Scrum brought a different format for writing requirements: the user story. An example is:
Seen in isolation, this is a nice and brief way to write a requirement. It even keeps us from going in too much detail at this early/general level.
Now, consider this user story:
Suddenly we are very detailed, and now have two overlapping user stories on two very different levels. And while there are guidelines to prevent this – including INVEST (stories should be Independent, Negotiable, Valuable, Estimable, Small and Testable), I quite often see people end up with stories that are overlapping and very different in the level of detail, which leads to a sometimes serious lack of overview. This challenges the common understanding and often leads to programs with no predictability or transparency.
There’s a different way to structure your requirements. It will bring back the predictability and the overview, and it will help you slice right. It’s called use cases, and though many have learned and used this requirement modeling technique, it seems forgotten for the most part. Use cases sound very similar to user stories, and while they have similarities they also have big differences.
Use cases were introduced in the ‘90s and became very popular, and maybe somehow connected to waterfall development, and therefore got a bad reputation. Use cases do, however, offer a firmer structure and an overview, which is what many agile programs need.
Use cases have four easy-to-understand guidelines to help determine whether you have a real use case on the right level:
Over the years, I have seen several Agile programs re-create the overview and common understanding, and thereby the program’s transparency and predictability, by remodeling all their requirements into use cases.
There are three things in use cases to drive you toward epics that are actual slices, which are potentially releasable to your users:
A quick summary of the reasons to consider use cases instead of user stories:
So, what is a use case camp?
The very short answer is: a use case camp is a facilitated requirement workshops with participants from both business and IT.
A little longer answer: it is 10% use cases and 90% workshop/facilitation. Participants discuss how the user will be interacting with the system, and because both the user’s perspective and the system perspective is in play, it sparks substantial and passionate discussions, where all stakeholders are involved in creating the overview and the sliced epics together.
Interested in trying a use case camp? Here’s the how-to:
Depending on what has been discussed and decided on earlier in the project, someone needs to set the stage… An inspiring talk about the program, the scope and the benefits we’re about to create.
After the introduction, split the participants into groups of three to four people – with business and IT people in each group – and ask them to brainstorm use cases on sticky notes.
This step can be supported with documentation about scope, processes, and business goals that have been produced earlier in the project. Strange enough, we often see that the participants do not use or need these documents. They seem to have a better understanding and knowledge than the documents offer.
When the brainstorming is over, the groups post their notes on a poster on the wall. No grouping or ordering is needed. Actually, it is better if they do NOT order or group at this point because this can lead to discussions that fit much better in the next step.
This step is where we start getting to the meat. We are still at the overview level, but we always get deep discussions and new insights during this step. This step usually takes at least half of the use case camp. Between one and two days for this step is a minimum.
Explaining the illustration ”Use case camp”:
This order is important, because it creates an intense focus on one thing at a time.
We have found it essential that the room and the AV tools are exactly as shown on the illustration.
When you’re done with all the sticky notes and you have your use case diagram and a brief description for each use case, you have not only sliced your requirements right, you have also created a common understanding among all the participants in the use case camp, and thus you have a number of ambassadors, who can go out and cast light over the entire program with this overview and common understanding.
The difference between slicing right and wrong at the program level can have major consequences for the success of the program and even the business.
In this article, I’ve shared why and how to slice right – how important it is for the entire program – for common understanding, for predictability and transparancy, and for success.
You can create more structure in your requirements by working with use cases rather than with user stories. And you can create a common understanding at the same time if you decide to model your requirements together in a use case camp.
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:
After I joined the program in May, one of the first things we did was to set a date for the first big room planning for June 16-17. We invited everyone on all the involved teams plus other key stakeholders from the Business and a couple of the people responsible for the organizational implementation. There was a lot of discussion about the timing. The big question was, “Will we be ready?” … Pia, the Chief program points, Sally the Chief scrum master and I kept to the date, thinking that it would drive everyone to get ready. And it worked. Almost as great as we thought it would. More on that later.
Before the big day, Pia had managed to get the various parts of the Business to describe and deliver the epics that they needed, seen from their individual points of view.
And then, finally, June 16th came and everyone met in a big room. After Pia reminded us about the business benefits of Mifid (compliance to the EU regulation & better investment advice and service for the bank’s customers), in my role as the main facilitator, I presented the program for the two days. See illustration: Planning agenda – for each team.
Each team chose the epics they felt belonged to them (see illustration Epics & teams), and started to break them down into user stories.
And then the problems started …
The Online Banking Team did not see that they had any epics of their own. So why even stay at the big room planning?
Another team had 12 people sitting around a table. A couple of them were talking, and all the others were just sitting quietly looking frustrated.
Other teams – with better dynamics – simply did not understand the epics, and therefore had a really difficult time breaking them down into business features.
What a mess!
I asked the Online Banking Team to step outside with me so we could talk. I had a burning question about how they were organized. Their team seemed like a silo to me because they were “just” a channel for everyone else’s products – including the investment services. But I didn’t talk to them about that, since it was not this team’s idea to organize in this way. Instead, we agreed that they would split up and participate in the big room planning with the other teams. Which they did, sort of. It took a lot of nudging to keep them close to the other teams.
Pia, Sally and I agreed beforehand that we would split the teams between us, and facilitate two teams each.
Throughout the article, you will find highlights and tips – in boxes like this one. Here comes the first tip …Have enough facilitators for big room planning
Based on the level of Agile & team maturity, make sure that you have enough facilitators for your big room planning. One facilitator can typically handle between one and three teams.
The 12-person team was another nut to crack. It was simply too large a group to do any meaningful planning together. I approached them and told them. They all just looked at me, and right before I was about to just tell them to split up, Pia came up to me and whispered, “Shhh, Ole. Try to let them be, see what happens”. And then, after a few more minutes they all got up, and ended up in two groups, having two separate discussions. And soon, they were working on two separate team boards. They had self-organized into two teams. Awesome!
Create ownership by giving control
In a large program (and in all other situations for that matter), you want the individual people to take ownership. Otherwise, you will never succeed. With so many people, there is no way that you as a manager can plan and steer the program to reach the goals. And you can only get them to take ownership if you give them control, rather than you taking control.
Now, we only had the we-do-not-understand-the-epics problem left to solve. But no matter what we did during this big room planning, it did not solve the problem.
It became painfully clear to us that we introduced the problem ourselves by having the individual parts of the business describe and deliver the epics to the program. Had we pushed too hard by sticking to the June date? Would the teams have been more involved in describing, and thereby understanding, the epics if we had given them more time? Actually, we did not think so. We took this as a learning opportunity – promising ourselves to support the teams to better understand the epics before the next big room planning three months later.
Set a date – drive people to get ready
Setting a somewhat optimistic date for the first big room planning is a driver for everyone to get ready. If you wait until everyone is ready, you might wait forever.
After the teams somehow managed to get going on developing some of the business features (there was a lot of interaction with the business – finally!!), they wanted to get ready for the next big room planning. There was a pull from the business side, which I thought was wonderful. We had created a sense of ownership. It was no longer the program management’s plan – it was their plan.
One of the teams asked me to help them by giving them the answer to this question: what does a perfect epic look like?
I looked around at epics from my past programs. And other epics from other programs. And I thought about it, and I kept looking some more, becoming frustrated that I couldn’t find a single epic that I thought was perfect.
Then I started thinking about what had made the difference between successful programs and unsuccessful programs, and realized that it had nothing to do with the format of the epics – or any other templates or requirement specifications for that matter.
I met with the team and shared with them what matters when it comes to slicing and refining requirements:
Prioritized, and in that order, so the epic format is the least important of the three.
We did two things to start understanding together. First, we grouped the requirements they had brought with them. A good mix of epics, features and stories. Someone asked: “Is this Story Mapping”, and I said, “Yes”, and explained how I see Story Mapping as simple as: laying your requirements out on a table, and moving them around to create a structure that makes sense, preferably with potential releases as a part of the structure.
This led to a heated discussion about how to organize the requirements. Most of the requirements were about three new investment banking products from simple investment advice to full investment portfolio support. Most of the people argued that the slices (the potential releases) should be the products, so we would develop one product 100%, release it to the market, and then move on to the next product. A couple of other people argued that we should first get all the legal issues figured out for all three products while we had the lawyer involved anyway, then the marketing plan for all three products, and then everything else before launching all three products at the same time.
I recommended the product-by-product approach (see illustration Story mapping – which way?) as a better way of slicing, in order to get to actual smaller and potential releases earlier, to increase early feedback and learning. That was what the team agreed on.
Now it was time to go deeper in each of the requirements, and we did that by taking one requirement at a time, and refining in this way: 1. Brainstorming all questions that we could come up with and write them on red sticky notes and post them on the paper with this particular requirement. We kept going without answering any of the questions until we could not think of more questions. 2. Then we started trying to answer the questions one by one and wrote the answers on green sticky notes. Some questions we could not answer, so that became the program points’ responsibility to find the people who could answer those questions.
Understand by asking all the questions first
A good technique for getting people to create a deeper common understanding is to have them brainstorm all the questions they can think of before you start answering any of the questions. It helps cover more ground than the usual question -> answer -> question -> answer. This is very useful technique for backlog refining, including refining ahead.
Meanwhile, a different team on the program worked to figure out some of the epics from the big room planning that they still did not understand. The scrum master had printed them all out and organized a workshop and the program points was ready to try to explain.
For the first couple of hours, they sat around a table having a discussion around these epics. But they didn’t really get anywhere. There were no conclusions. And it felt confusing. We agreed to move to the other end of the room and lay out the eight epics, and started to write tasks on index cards, and place them by the epics. No matter how hard the scrum master tried to organize the cards, and no matter how hard the program points tried to explain what he thought was in each epic, the confusion didn’t go away.
Then someone said, “Why don’t we push all the old epics aside, and write our own new epics. That way we don’t need to guess what someone meant when they wrote those old epics.”
Then something happened!
After just a couple of more hours, the team was ready with their new epics, ready to run them by their stakeholders to make sure that they were still on the right track.
Understand by starting from scratch
It can often be more efficient to create a common understanding by starting from scratch and trusting the knowledge and memories of people, rather than trying to interpret someone else’s work.
While we were getting ready for the next big room planning in October, we talked about all the problems we had the first time, and realized that two more things had not been optimal:
We did have a master plan from last time, but it was only really robust for the next three months and shaky for the following many months. Therefore, people got confused about what to take into this big room planning and what to postpone for the future.
Also, some business areas were very keen on living up to the Mifid regulations in every detail, where others were more focused on the customer experience.
In other words, no clear direction. Leaving room for people to spend a lot of time discussing the direction, and to pull in different directions, during and after the big room planning.
We decided to get additional stakeholders involved in a master planning session in late September, before the next big room planning in October. We invited the program points from each team, the steering committee, three business heads and Pia, Sally and myself – a total of 12 people.
We started by getting a feel for how far we were after three months. Out of a total of 15 epics, two were finished and seven were at around 50% done. Not where we wanted to be.
Then, we estimated the epics using planning poker with t-shirt sizes. It was great to see the level of engagement from everyone.
We prioritized and I insisted that all epics were in one line to get the business heads to agree on what was most important for the entire company. One of them said to me, “I know what is most important for my area, but how can I know what is most important for the other business heads?” He said this while he was standing right next to one of the other business heads, and I just smiled, and looked around the room. “Ahhh”, he said. “I can just talk to them.” Bingo!!
After they had a really involved discussion about how much they thought we could get done in the upcoming three months, they reached a conclusion: the next 26 epics.
Meanwhile, I had done the math (see illustration Program points). I had calculated that the epics we had planned for the first three months were equivalent to 228 points using a conversation scale from t-shirt sizes to what I call program points. We only got 125 done (97 of the planned, plus 28 extra unplanned work).
Using the same method, I figured that they were about to aim for 606 program points in the upcoming months!
We adjusted the ambition significantly, and we were ready for the next big room planning.Gauge program progress by rough program points
Rather than only gauging program progress by summarizing all the detailed progress reports, which often is very time consuming, you can get a quicker and earlier picture by rough estimates on the high-level epics, and do the math on those.
October comes, and everyone got together again. We saw more people than last time. The Online Banking Team brought some of their colleagues. And a couple of the business heads showed up too. Apparently, people heard about it, and wanted to be a part of it.
We started by looking at what we had achieved the last three months, using the same overview as at the master planning. And then, we presented the result of the master planning, which was still somewhat ambitious, but not at the 606 Program Point level anymore.
Then the teams gathered around the epic overview board, and this time we asked them to think about all the epics in which they played a role, even if it was a small role. We then got everyone to put a small colored sticky note representing their team on those epics (see illustration Epics & teams II).
After about one hour, we had an overview of which teams were primary drivers on which epics – and which other teams were also involved in each epic.
It surprised us how powerful this was. There were a lot of people standing by this board, coming and going throughout the two days, and it was usually people from different teams having a discussion about what they needed from each other, how they could help each other.Increase cross-team collaboration by visualizing team-epic involvement
Making it visible that more than one team is involved in the various epics increases the cross-team collaboration during and after the big room planning.
The next thing that happened, with surprisingly little guidance, was that the teams started to break down and estimate. I noticed that both Sally and Pia hardly did anything to make it happen. And neither did I.
I was very happy, thinking that all our not-telling-people-what-to-do, but rather letting them drive their own understanding and making their own decisions, and also involving and engaging them in the first big room planning, was now clearly paying off. The new ways of working had been internalized in the teams and people. We were about to achieve lasting change!
While the teams worked on their planning and collaborating with other teams, Sally had time to improve the program board, getting it ready for the teams to post their features. She had brought some nice tape, and organized the board, including measuring out the space for a certain number and size of sticky notes per team per sprint. Meanwhile, she was thinking that the first program board had a lot of information on it, making it harder to get the overview. So, she decided to ask the teams to give their features a short name, and only write that name on the sticky notes that they put on the program board.
The result was a much better structured program board with fewer details, giving a far better overview, and therefore, a far better tool for the weekly Scrum-of-Scrums, where all scrum masters, program points and other stakeholders gather to coordinate and gauge actual progress and comparing it to the plan.
I was curious about the perception of the time spent on the big room planning, so I asked a few of the people who had been skeptical the first time. Here’s what a couple of them said:
Two days is a lot of time. Has is been worth the investment?
Of course, not everything was perfect. And we kept learning. One of the main things we should have done differently was this:
We experienced a need for extra attention on one of the epics. The deadline for this particular epic was harder than the others, and it was more complicated with more teams and stakeholders involved. We tried to fix it by nominating an epic owner, and it helped, but not enough. We did not meet the deadline, and therefore had to pay for one more year of a particular software license. Looking back, we should have insisted on moving the two most involved teams closer together.
This was my story, which I hope gave you some real-life-perspective on the key takeaways that I mentioned in the beginning of the article:
In the next articles in the series, I will dig deeper down into slicing, master planning and big room planning, sharing more experiences and giving more specific tips and tricks. Stay tuned …
Meet Ida, the head of ReDI School in Copenhagen, a non-profit technical school. ReDi School provides women with refugee and migrant backgrounds valuable digital skills, as well as a strong network of fellow students, volunteers and alumni to gain new social and professional opportunities.
Why is it that figuring out what to focus on in the PI/Big Room Planning sessions is always difficult? In this video, we explain what it takes to make SAFe work with Slicing and Master Planning.
This is how to make SAFe work – with Scaled Planning
Start by watching our short video