Whenever I work together with clients in a scaled agile organization, prioritization across the borders of a team or even across large business units is perceived as most challenging by the participating Product Owners, Managers or Shareholders. One of the reasons for this perception is the fact that a common method for prioritization is often missing and thus urgently needed.
In this blog post I want to introduce to you the Magic Matrix Technique that my colleague Karl Bredemeyer and I designed for a large workshop a long time ago. With the Magic Matrix Technique you can prioritize cross-organizational projects and create a unique company backlog that lists all projects of a company in a discrete order. We have used this technique very often since then and it always proofed its value.
The technique is called Magic Matrix just because the client for whom we designed the workshop called it that way after the workshop was over.
It is basically a good combination of the Magic Estimation game invented by Boris Gloger, the Prioritization Matrix invented by Donald Reinertsen, and some facilitation. This technique is very generic and can be used for almost every prioritization approach. That’s why some Product Owners I worked with use it to prioritize their user stories in their product backlog as well.
Let me introduce you to the challenge this client faced that day. Based on a management consulting intervention that we had done before a group of shareholders, c-level executives and top managers from ‘business‘ (e.g. marketing, customer care), ‘technology‘ (e.g. directors of tech, lead architects) and ‘legal‘ for the first time in the history of that company aimed to establish a common company backlog to avoid prioritization conflicts in the development teams. These prioritization conflicts had led to avoidable context switches, multitasking within product development, and thus to poor output of their delivery flow.
All the people named above attended an offsite workshop to bring all the important projects into a discrete order and to consequently allow the different development teams to pull work from that list. As in every business context the total budget for the whole product development was limited – and so was the available time to realize certain projects and initiatives.
The atmosphere in this offsite workshop had been tense since minute one. We did a check-in and asked each participant about his or her intention for attending the meeting. Very often they answered: “I am here to fight for my projects.” After some time of community building and introduction to the topic, the participants wanted to start with prioritization. But how to do this in such a tense atmosphere and with so many strong managers in the room?
Let’s have a detailed look on how to perform the Magic Matrix Technique in order to achieve a (company-wide) portfolio prioritization.
Keep the number of attendees reasonably small. I know that everybody has an opinion on project priorities but only few have budgets to run projects. Try to have less than 20 participants.
The selection of attendees to this workshop depends on the specific situation you are facing. If you try to create a company backlog, make sure that each business unit that is requesting resources needed to develop a product has a representative in this workshop. When I say ‚resources needed to develop a product‘ I am not only talking about development resources. Think also of all the ‚shared resources‘ that are necessary to bring a product to life (e.g. purchasing, release management, lawyers and so on).
Overall time frame
Depending on the number of attendees and their experience in collaborating across the company, the time needed for this technique will range from two hours to a bit more than half a day.
The setting of a workshop always determines the behavior of the attendees. Karl and I chose to create a special setting: we printed out all project requests on A3-sheets and pinned them to the wall. We aimed at creating a feeling of being in a museum or a gallery. Very often those galleries trigger a certain sense of urgency because the attendees are overwhelmed by the sheer amount of projects they want to deliver. Sometimes they immediately understand that they need to say NO to certain projects for now.
On the floor, we had prepared a large square, simply made of white painter’s tape, and two long tape lines next to it. The square contained nine smaller squares. The y-axis was labeled ‘cost of delay‘ and was divided into three sections: low, medium, high. The x-axis was labeled duration of delivery and was divided into short, medium, long. This creates a 3 by 3 matrix that distinguishes 9-fields.
Right, this is the Matrix created by Donald Reinertsen which he derived from prioritization mathematics also known as weighted shortest job first (WSJF / 2).
The two long tape lines repeat the labels of the Magic Matrix (below I’ll explain why). The first taped line was divided into three sections labeled high, medium, low. The second line was also broken down into three sections labeled long, medium, short.
1. Gallery walk
Let the attendees walk along the gallery that shows every project (or user story) printout taped to the wall and let each project be introduced briefly by the attendee who raised the project.
2. Allow Questions
Allow short questions to improve understanding. This is not about arguing, just about a common knowledge base of each project.
3. Distribute the printouts
Now take the printouts off the wall. In order to run the next part of the session smoothly, only pick around 30 to 40 printouts. In case you have printed out far more projects or initiatives, ask the attendees to pick the one project that is most important to them. Do the same with the second most important project and so on until you have picked around 30 to 40 printouts. In the workshop described above more than 160 printouts were sticking to the walls.
Deciding what NOT to take off the wall was a first emotional moment for the participants.
Let every participant hold one or more printouts in his or her hands. It is not necessary that every participant holds a printout of a project that he or she raised initially.
4. Introduce the cost of delay scale
Introduce the first line of tape on the floor to the participants. This is the line symbolizing the cost of delay (2). The cost of delay is always defined with a specific point of time in mind. Make this point of time explicit to the participants.
In the situation described above, it was a date some months ahead. A highly important media event was going to take place and would have high economical relevance to the whole company. The question at this first line of tape is then: How high will the cost of delay be if we do not finish the selected project completely until that special date in the future? Consider the cost of delay in direct relation to the other projects. Make sure that everybody understands the meaning of the word ‘relation’. It means that you don’t try to calculate precise costs but rather estimate it in close relation to the other projects you are discussing. Don’t try to assume the cost of delay for one project in isolation.
Consider different categories for the cost of delay. The cost of delay is the area below the line.
5. Play the first round of Magic Estimation
With this question in mind let all the participants play one round of Magic Estimation. Magic Estimation is an Estimation game that was invented by Boris Gloger many years ago and has proven its value in countless user story prioritization sessions. I will not describe the game in detail. If you are not familiar with the game, feel free to follow the link.
Instead of using the modified Fibonacci scale as you might know it from the original Magic Estimation game (you can buy a Magic Estimation poster to facilitate estimation meetings on our website) or from planning poker, we only use these three sections of the scale: low, medium, high. It is essential that all the participants remain silent during the whole round. Talking will disrupt the flow and impact the outcome of the estimation negatively.
The facilitator, who might be you, looks for projects that jump from one section of the scale to another. Those printouts are marked with a dot in a specific color by the facilitator. This dot indicates that the participants disagree on the relative cost of delay of this project.
If you perceive that almost all projects tend to move towards the ‚high‘ section of the scale, interrupt the game for a moment. Remind the participants that they have limited resources as well as limited time. Point out that not all projects can be equally critical in terms of cost of delay regarding the specific date defined at the beginning of the session.
6. Agree on the cost of delay category for each project
After the first round Magic Estimation is over and all projects have been put to the floor, grab the first project from the ‚high‘ section that has been marked with a dot by the facilitator. Ask who disagrees with the cost of delay for this project being high.
The project should not be discussed separately but in relation to other projects, so chose some from the high and medium section that did not receive a dot mark. Keep the discussion short and always keep it in relation to other projects without a dot mark and in relation to the specific date in the future you agreed on before. Formulate something like this: “You silently agreed on a medium cost of delay for project A and on a high cost of delay for project B. Is the cost of delay of project C closer to project A or to project B?”
Agree on the relative cost of delay for the project at hand and write it on the printout in the same color as the dot mark.
7. Repeat brief discussions
Repeat these brief discussions for all projects with a dot mark. Keep the discussions short and decision-oriented.
8. Have a coffee break
When you’ve agreed on the relative cost of delay for all projects, have a coffee break and let lots of fresh air into the room. While the participants enjoy their coffee, write the relative cost of delay on the remaining project printouts according to the sections they were put into. It is important that every project printout has its own cost of delay note because you will need this later for sorting the projects.
9. Second round of Magic Estimation
Repeat the Magic Estimation game at the second taped line. Again, every participant receives some project printouts before the game starts.
The question for this round is: “In relation to the other projects: How long would it probably take to finish this project if we only did this single project at a time?” In order to avoid confusion, use a different color now for making the dot marks than you used in the cost of delay round.
10. Agree on the duration of delivery
Agree on the relative duration of delivery for those projects that received a color mark. This again needs some facilitation to avoid long discussions. Remind the participants that this is just a wild guess in relation to the other projects left and right along the taped scale. It is not necessary to be precise.
Write down the assumed duration on the project printout.
11. Sort the projects into the matrix
After this is done, ask all the participants to grab the project printouts on the floor and sort them into the taped matrix on the floor. This is straight forward. Every of the nine squares is described by a specific cost of delay and duration of delivery.
12. Do the elevator
We are almost done. You probably experience that some squares contain more than one project. This is not a problem at all. Do the ‘easy elevator’ next. Start with square 1 (cost of delay high and duration of delivery short) – grab two of the projects in that square and ask for the relative cost of delay again considering the special date in the future. Let the participants explain their opinion and come to a decision.
Now grab one more project out of the same square of the matrix. Ask: “Is the cost of delay of this project higher than of the project currently lowest or is it lower?” Quickly sort the projects until you have a discrete order in this particular square.
13. Create the sequenced company backlog
Take the ordered projects and lay them out in the room in this discrete order. Since you have started with the most critical square 1, you will now experience that discussing the other squares will go more smoothly.
Repeat the ‘elevator‘ and complete the discrete order of the projects until you’ve laid out all projects that you have chosen after the gallery walk.
If there are still projects on the wall
It might happen that there are still some projects left on the wall. Honestly, this is not surprising at all. This actually happened in the workshop described above as well. Reflect on this situation together with the participants: Are these projects really worth being discussed in this workshop? The participants already have a quite big backlog. Long backlogs harm delivery performance and should be avoided.
Make clear that the participants now have a technique at hand with which they can add backlog items smoothly whenever the backlog is almost delivered.
Why it works like magic
Usually cross-company projects or initiatives are discussed, handled and processed each at a time. One prepares a business case and tries to overcome some gates in an approval process.
Opposite to that the Magic Matrix prioritization technique makes all projects visible at once that are important to the company – so one can overview their overall importance and their general contribution to the company goals.
It is not uncommon at all that different businesses or requesting units don’t have to talk to each other when initiating a project. This inevitably leads to the perception that one’s own project belongs to the most important ones or is even the most important project in the company. This often causes conflicts between business units since multiple resource allocations are revealed far too late – that is, when conflicting projects have already started.
When using the Magic Matrix Technique, a lot of valuable discussions arise among the participants. If you repeat this format – let’s say quarterly – the participants get used to collaboration and aim for a shared goal together.
3. Movement instead of mathematics
I assume that Don Reinertsen, who I once met for some days in Essen, would consider this format to be a bit playful and not mathematical enough. And although I highly value Don and his contributions to the art of product development, I have experienced that only few understand his insights and recommendations to such an extent that they can use it practically.
If you don’t have enough time to introduce the principles and ideas behind Don’s ‚Second Generation Lean Product Development‘, this specific matrix suffices to benefit from its strong mathematical basis.
Instead of calculating the cost of delay, you relatively determine it using group knowledge. In his book mentioned above, Don states that humans are not very successful in estimating the cost of delay (COD) of a single item based on intuition. If different experts are questioned separately, the resulting COD values spread tremendously. Relative estimation in the Magic Estimation game and the communication here comes into play: Obviously, values like ‘high‘, ‘medium‘ or ‘low‘ are not precise. But that is not the intended result of this technique.
The goal of this technique is to be fairly accurate and to support decision making in a very short time. Just recap: You initially prioritize a whole company backlog in less than a day!
And because all the projects on the wall are important to the company, it doesn’t even matter if the cost of delay is precise as long as the priorities of the company backlog items are mostly right.
Prioritization means to sort and sequence. It is important to consider that – with all due respect to mathematics – this is a decision. I often experience ‘decisions by Excel‘ which means the decision to prioritize some project or feature is somehow ‘outsourced‘ to a spreadsheet to avoid clear decision making.
Don’t forget that there is a ‘No’ in every decision: prioritization also means not to do something else that has less or no priority. Saying ‘NO‘ is the ultimate tool to avoid system overload thus resulting in low performance.
Generally you ‘just‘ need to agree on resource allocation and on the method you use in order to achieve this allocation. Both will be reached with the Magic Matrix Technique – it is fast and, maybe surprisingly, it is also fun. Not to forget that the initiated discussions about business goals among all participants are as valuable as the prioritized company backlog itself.
Since this technique can be executed fast and with little effort, it can be repeated several times a year. This helps to constantly refine the company backlog which allows strategic adjustments more often without harming the currently running product development process.
In the end this makes the company more adaptive. It even allows to decrease the size of projects to a bare minimum because you can reduce the forecasting cycles. As soon as your management team is capable of constantly and effortlessly adjusting the company backlog, you can run prioritization sessions more frequently. This reduces the investment risk and allows quicker market feedback, which ultimately results in better products and more revenue.
What happened then
The client which first participated in the Magic Matrix workshop still uses this technique to prioritize the company backlog. Over time it evolved into a strategic product portfolio. The Magic Matrix is not only used for the company portfolio. It is also used to prioritize team backlogs which have a higher granularity.
Today, for this client prioritization conflicts belong to the past. The product development teams are more focused and are thus able to deliver faster and in higher quality.
In this workshop we created a shared view of the company’s priorities across the business domains. Over time a cross-domain top management Scrum team emerged which adjusts its shared strategic product roadmap once a month in an office workshop.
Additional information: Constraints to this technique
As far as ‘mathematical logic‘ behind the presented technique is concerned, we are talking about the division of cost of delay and the duration of development. This calculation is also called CD3 calculation. It fits with Scrum very well since it focuses on time dependencies and thus fosters delivery focus.
Nevertheless, there are some limitations to this technique. Using the Magic Matrix Technique will be beneficial if the compared backlog elements show distinguishable costs of delay. Sometimes backlog elements are so closely related to each other that you can hardly distinguish the delivery of one item from the other. In this case, it helps to find an overarching backlog item that integrates the smaller items.
Using the overall delivery duration as criteria for prioritization is only truly beneficial if the participants of this workshop don’t know the ‘organizational constraint‘ of their delivery flow. If the participants know the constraint, it is not recommended to consider the whole delivery duration. Use the processing duration of the delivery step that constraints the overall delivery flow instead. This calculation technique is called throughput octane (or product octane).
However, management teams performing the prioritization of a ‘company backlog‘ for the first time are hardly ever familiar with the ideas of the theory of constraints. Therefore, it is very unlikely that they are able to precisely name their constraints, which makes it impossible to calculate or estimate the throughput octane. Which leads back to the Magic Matrix Technique as being ‘good enough‘ for the described purpose of prioritization.