What's Epic Board, and why is it so useful for all executives and employees?

Want to fix the communication issue between the business and development departments once and for all? Here's how you can do so by implementing the Epic Board concept!

What's Epic Board, and why is it so useful for all executives and employees?

One of the things I fix when I join any company is the communication channel between the business and development departments. It sounds like a difficult and large task but can be solved with a simple tool — the Epic Board. It has almost nothing to do with the Scrum "Epics", just a fancy term to call this approach.

I also don't claim that I'm the inventor of this technique — I'm pretty sure loads of people came up with this concept before me. I'm just one of them and I'm here to tell you about how I implement this concept. In our today's case I'll show how to use it in Asana, but feel free to use any tool of your choice.

Why do you need an Epic Board in your company? It solves all the communication issues efficiently by making the company transparent. It is a silver bullet solution. I repeat: if you don't use the Epic Board concept, you are missing out on productivity. No other approach works as well. And it is completely free. Seriously, try it out. You will not regret it, you will become an evangelist of this technique as well!

It focuses on the three main concepts:

  1. Top to bottom transparency
  2. Bottom to top transparency
  3. Laser-sharp focus of every element in the company

It means that executives will always know what's the status of the company by just looking at this board. It also means that every person when working on a task will see the direct connection between what they are doing and the main company goal. Moreover, every single piece of effort will be directed towards achieving the company goal. Would you like that for your company? Let me tell you what you need to do today.

The three layers

There are three layers (or levels) to the Epic Board: company, department and team. Each has its own rules and all the tasks are interconnected. After I show you a way to implement this structure, you will see all of its benefits.

Every layer is going to be a separate Asana project. I'll show you an example implementation of each layer. I assume that you are going to create a new project per each layer on your own.

I'm going to use a made-up IT company called "Unicorn Forever" (referred to as UF later) that sends out unicorn-themed postcards to whoever buys them. Let's assume it's an established business with a mobile app, website and machine learning algorithms that give customers suggestions on what postcards they may like the best.

So we'll have operations, development, machine learning, marketing, supply departments. Plenty of people to manage!

Company layer

We can also call this layer "Executive" or "Chief" because this is what the C-level executives are going to be looking at mostly. The idea behind this layer is to outline the strategic vision to the department heads, to plan the company efforts, to establish clear goals and to provide some sense of accountability.

This project on Asana is going to be used mostly as a timeline. There should be 1-3 main company goals that are usually figured out by the business department. Let's say we have outlined two goals for UF. We clearly state the goals using the SMART system. The timeline project forces us to set dates for each task.

These are our main company-wide goals. We will focus all of the company efforts towards these goals. We will not diverge our focus to any other goals. You can see that our goals are to increase sales and rollout in the UK. Let's figure out how we need to achieve this with the help of every department.

At this point, we've talked to all the department heads and figured out the priorities for every department separately. Green in our case is the marketing department, red — development, orange — machine learning, and yellow — supply. Notice, how we can connect each task on this board to the white company-wide tasks on top. In fact, you can add them as subtasks. The company layer is now complete.

This board contains all the data executives will need to meet weekly and discuss the status of each task separately to see if it is still on track. Feel free to modify this high-level approach! I.e. add metrics, more details, deadlines, whatever you want. The main goal of this layer is to clearly show what every department is up to and see if any issues have arisen.

Your CEO should throw a glance at this board and learn how the company is doing in less than 2 minutes.

At this stage, the only thing that's missing is the list of subtasks — connections to the next layer of the Epic Board.

Important Asana lifehack

A task can be both a subtask of another task and a part of a different project. You need to create a task, make it a subtask of another task and add it back to the project (because making a task a subtask automatically removes it from the project).

Notice how on the last screenshot we can see that one of the tasks has a subtask. Also, you can speed up this process by using the Tab+P shortcut to add the task to a project.

Department layer

Let's concentrate on the development department for the sake of keeping this article short. Everything from here down applies to all the other departments as well — and you'll see how.

Every department needs to have another board called "Longterm roadmap" which is also going to be a timeline. It is specific just for this particular department.

The goal of this board is to provide a layer between the personal team layer tasks and the company layer. It allows the department heads to plan their work to satisfy the requirements and the time constraints set on the company layer.

This board should contain all high-level steps required to achieve the goals outlined for the department on the company layer board. Because this is a timeline, we have to specify the timeframes for the tasks.

Every task on this board should be a subtask of a task from the company layer board.

Notice how we have outlined everything that needs to be done by the development department and added the department layer tasks as subtasks to the company layer tasks.

You can see how the connection is both top to bottom (whoever looks at the company layer can open a task and see all of it's subtasks) and bottom to top (whoever opens a task on the department layer can see why this task exists and what's the end-goal).

The longterm roadmap — or the department layer — is now complete. Now to the last but not the least part!

Team layer

This is where the work happens. Every department should have the team layer in addition to the longterm roadmap. This time you can choose whatever list style you prefer — or whatever your PMs prefer. In our case, we will use the usual kanban-like board. It has the backlog, sprint, working, and done columns. A pretty standard thing to anyone who has ever heard the word "Scrum".

Every task on the team layer should be a subtask of a department layer task.

I called it the "Sprintboard" but feel free to give your own names to any part of this technique

The backlog will contain all the tasks that come to your mind. If you have an idea or a bugfix to be done — first add a task to the backlog. Of course, this task should always be a subtask of a longterm roadmap task.

If you cannot make it a subtask (sometimes it just doesn't make sense) then either don't add this task or rethink the company and department layers. Everything in this methodology is flexible, modifiable and should be kept up-to-date.

Yes, to stay focused you have to abandon tasks. You need to complete fewer tasks, but these tasks should be the ones that matter the most. This is what you call "focus".

Every two weeks you are probably going to have a sprint planning meeting. At this meeting you should look at the longterm roadmap and pick the tasks that make the most sense to be completed in these 2 weeks, distribute them among the team members and move them from the backlog column to the working column.

Then every team member is responsible for their own tasks. But here's the trick: this part can also be viewed from top to bottom and from bottom to top. This time it's even better! PMs can look at the longterm roadmap and learn about the state of things with a glance whereas whoever owns a task can see why they are doing the things they were assigned!

See the beauty of this approach? It's all interconnected! I feel like the most important thing for people "in the field" is to realize why they are doing what they are doing. In case if they look at the chain of subtasks and say: "Hey, I don't think that moving this button 2px to the right will contribute to the goal of decreasing the bounce rate" — managers can understand the reasoning and either adjust the task or get rid of it altogether!

Conclusion

Thank you for reading till the end! I appreciate it. The "Epic Board" structure that I've outlined above consists of just 3 layers and doesn't require much maintenance. However, if you implement it in your process, you will see the improvement of the communication across the company from the day you finish building the board. It is this powerful!

Just imagine it: executives will almost never be out of the loop, developers will always have the sense of purpose no matter how small the task is, and the business vision will be translated directly to the people who implement it! Sounds like a paradise to me.

I hope I've expressed the idea of the Epic Board clearly enough. If you still have questions — feel free to ask them in the comments. Cheers!

A few clarifications

  • This structure works best for companies under 25 employees.
  • Even though you don't have to have a "scrum master", you should always assign each level to a specific person to keep it up-to-date. E.g. team leads update the team layer, their managers update the department layers, chief staff update the company layer.
  • As the very next step, you can build the company layer, then build the department layer, then the team layer.
  • This system works well in a flat hierarchy (i.e. each person has only one supervisor), but can also be applied to a more complex company structure with modifications (build it by keeping in mind the main goals why you do this).
  • You can meet once a week or so to check in with the senior management and audit the boards.
  • I take it for granted because I enforce this paradigm in every company I work with, but in your company you have to set up a "self-healing" rule for your systems and business processes. It basically means that when someone sees an outdated or broken part and it would take less than 30 minutes to fix it, this someone has to fix it. If someone sees anything wrong with the boards — that someone will fix it. Decentralizing the power of system support is the key.
  • How can you measure success with this board? Is there a metric? I'd say, you can derrive a metric for sure, but most of it is going to be subjective anyway. The best result you can get from the Epic Board approach is when you start the sprint planning — and you finish it in 10 minutes, because everybody already know what they need to be working on and why.
  • Feel free to connect all the tasks on the company layer to the main goal. I haven't done it in the example above for no apparent reason. You should definitely make the tasks there subtasks of the main 1-2 company goals.
  • Check out my other article about the SUP — simplified scrum that works well on the team layer of this board.