An effective content marketing team has a documented strategy, an editorial calendar, and a workflow process to execute. We have all three, except that the editorial calendar always seems to get left behind because once we get into execution mode, we spend all of our time in the workflow process just creating the content. When changes happen, the work in the workflow gets updated, but the editorial calendar does not. Therefore, the calendar becomes useless, and we wonder why we ever planned an editorial calendar in the first place.
Have you been there?
I thought so.
And once your editorial calendar is rendered useless, and you start letting your workflow guide your work, reaction-mode wins.
Then. This happens.
You come into the office and say to yourself, "Oh right. We have to get out a newsletter today." Going into a day in reaction mode like this is not a good place to be, especially for a content marketing team that drives its work with an editorial mindset. In fact, when we do operate like this, we are precisely not taking an editorial (or audience-first) approach to our work. We are just reacting like everyone else.
We wanted to fix this somehow, and in thinking about it, we went back to basics and asked ourselves, "What is an editorial calendar?"
At its foundation, an editorial calendar is a planning tool. It spells out what a team will work on, who on the team will work on it, who the audience is, and where the content will be published (among a few other details). According to Joe Pulizzi (https://www.copyblogger.com/content-marketing-world-2012/), author of numerous books on content marketing, an editorial calendar is more than a bunch of topics and dates in a calendar. Pulizzi says your editorial calendar should also contain the following:
Certainly there are many ways to create an editorial calendar. Most of us just put it on a Confluence page or a Google Doc or on a complex, scrolling, color-coded nightmare of a spreadsheet. This is fine. At least you went through the process of planning out your editorial process for year. There is huge value in this.
Here's the problem.
There are two other parts of the work that now need to start happening during execution: 1) tracking the work; and 2) producing the work. So now, we go to another tool (Jira, in this case) to create tasks that are mapped to items in the editorial calendar. Then, we create drafts of documents in Confluence and link those to the tasks.
So far so good.
Until we start working.
As happens in most working scenarios, things change. Topics we planned for March might have changed because of a new product release or a competitor announcement inspired us to change what we talk about on our blog. These may or may not be legitimate. But they happen. Over time, a gap grows between what we put in our editorial calendar and what we put in our project management tool. So now, we find ourselves keeping both the editorial calendar AND the project tasks in sync.
I hate doing this.
So I ignore the editorial calendar and just keep the tasks up-to-date.
This. Is a bad idea.
The snowball starts to happen because the more we do this, the more irrelevant the original editorial calendar is. That is just about the time, our VP of marketing would like to review the editorial calendar. And why not, that was our original planning tool. Since the editorial calendar now does not reflect current reality, it almost has to be re-created just to update the VP of marketing.
I wish we could just update the VP with our project management tool.
That's when it hit me.
We could use Jira and our kanban board to completely replace our editorial calendar. And we could do this while still keeping all of the important components of an effective editorial calendar.
In this case, I will discuss why you should plan your editorial calendar in Jira using kanban. I'll keep it at a conceptual level, so we don't get bogged down in features. It was easy for us to make the shift to planning our editorial calendar in Jira and kanban because we were already using Jira and kanban to track and manage all of our content work. We already use it to track content, from idea to published. To make our Jira kanban board also work for an editorial calendar planning process, we made some configuration changes to it, which I discuss in the "how" section below.
Let's start with the first why.
All work in one place: If we can plan our editorial calendar for the entire year in one place, we eliminate the need for keeping "two things" up-to-date. We plan in one place, and we track the work in that same place: Jira. This is more liberating than you might think. Whenever anyone has any question about what we planned or what we are working on, we only have to share the link to our board.
Everything is there.
We never have to keep two "things" up-to-date.
Visual display of work keeps us on our toes: By using a kanban board, everyone on the team has a visual of the work we have planned in each month, what the team is working on right now, what is stuck, and even what we should have started but have not started yet. In a glance, we can see that a newsletter is scheduled to go out this month and that we have not even started on it. Sound the fire alarm!
We can limit work in progress so we can stay focused: Jira let's us set a limit on the amount of work we can have in progress. This takes some discipline, but the better we get at this, the more focused we can be on finishing what we have in progress because starting on something else. It is a bad idea to start four blogs and finish none of them. It is much better to finish one blog before starting on the next. Or at least limiting the number we can have in progress. According to our director of engineering, YC Lian, if we are not limiting work in progress, we are not doing kanban.
So there.
Flow fits well with content marketing: With the exception of major content projects like video customer testimonials or programming for events or creating workshop content (projects with a beginning and an end), most content marketing work is continuous. Most content marketing teams publish blogs or podcasts or social media posts or webinars or newsletter in a continuous flow every day, week, month, etc. Kanban is the perfect work process for work like this. The team can see all of the work that is planned, and as work is getting published, can pull work through the content marketing "system" to keep things moving along.
These are the main reasons why we now do our editorial planning in Jira using a kanban methodology. If I had to pick just one reason, it would be to eliminate the need to create an editorial calendar on some document away from where we actually do the work.
Now let's talk about how we set up Jira to make this happen.
Workflow: We have on our kanban board a simple five step workflow:
Each step in the workflow is represented by a column on the kanban board, so that visually we know what work is happening and in which workflow step.
Swimlanes: One of the core functions of an editorial calendar is to show when you will create content for certain topics. Mostly by month. One of the most valuable reasons to create an editorial calendar (for me) is to know what we will be working on and in what month. It demystified the unknown because I can know, at least at the topic level, what we will cover this month, next month, and six-to-twelve months from now.
You can create a visual display of everything you will work on throughout the year using swimlanes on your kanban board.
Think of your swimlane as a row of work on your kanban board in which you can plan a certain collection of work. To make our kanban board take the most advantage of the purpose of an editorial calendar, we created a swimlane for each month of the year. Now, when we create Jira issues for each topic or content type, we set the due date for some time in that month (this month or 11 months from now) those issues will automatically show up in that swimlane (row) on the kanban board.
We create each of those swimlanes with a little JQL like this:
Issues due in October: duedate >= 2018-10-01 AND dueDate <= 2018-10-31
Issues due in November: duedate >= 2018-11-01 AND dueDate <= 2018-11-30
Issues due in December: duedate >= 2018-12-01 AND dueDate <= 2018-12-31
And so on.
To be honest, this liberated me. I can now look at our kanban board and see what we plan to work on in every month of the year. Now all we have to do is execute (you know, the actual hard part).
Color coding each issue: Another vital element of an editorial calendar is to account for the channels through which the content will be published. A channel could be a blog or a webinar or a newsletter. A good editorial calendar will communicate the topic covered as well as the primary channel through which that topic will be distributed. Also, the channel choice drives how the content will be created and also who will create it. We wanted to somehow show visually on our kanban board the target channel. We chose to color code our board by channel. We set up a Component in Jira for each channel. Then added a little JQL on the Card Colour page of the Boards configuration page that says, "If the component is 'blog' assign the color of orange to the issue on the board. For example, in the colour column, we selected and orange color, then used JQL like this:
component = Blog
Nothing really fancy there. We just wanted to easily show on our board, the content and the channels it is intended for.
There are many other things we could have done to represent important parts of our editorial calendar in Jira. We could have customized the issues types and create fields to capture all sorts of data points like, buyer persona, keywords to target, products to target, etc. But we decided to keep things simple and capture data like this in the issue description. The main thing two things we wanted to get out of planning our editorial calendar in Jira with a kanban board, is to 1) eliminate the extra work of keeping an editorial calendar document up-to-date; and 2) display our work visually, throughout the year, by month, so we always know what we are working on next.
We mostly accomplished this.
What do you think about this process? Do you think it would work for you? Why or why not? What questions do you have? What did I miss? Comment below with your questions.
.jpeg)
No. These were not the only mistakes we made. We made many more, but you get the idea. One of the best things about using Jira to track all of your work is that you can configure it to suit how you want to work. The problem is that we don't always know how we want to work until we start working. So let this be a lesson to you...that it is OK to make mistakes. Mistake are inevitable. It is better to start, knowing you will make mistakes, than we wait until you get it right the first time. Changes are, you won't.
You can learn from even more mistakes we made in the book, The Art of Agile Marketing: A Practical Roadmap for Implementing Kanban and Scrum in Jira and Confluence. It will help you get started and also avoid some of the mistakes we made.
The Art of Agile Marketing: A Practical Roadmap for Implementing Kanban and Scrum in Jira and Confluence.
