If you are creating content today, you probably have experienced some fatigue while trying to get the final product out the door. Maybe you adopted a tool like an editorial calendar and after several months, you are tired of seeing red from missing your deadlines.
Whatever the case, Content Marketing can be a very exhausting process and over time it will start to wear significantly on your team without taking some steps to lean toward long term success.
Agile Marketing has several tools that can help address fatigue with teams and can also take your pulse as you prepare for the long haul. One of the worst places you can be is in the middle of your efforts and throwing money or resources at the problem and without digging into the symptoms and correcting the root issue.
In this article I focus on one tool you can use with your team to build up momentum and give them some skin in the game when it comes to deadlines. The tool is called a Sprint, and it is part of the Scrum Methodology. Let’s see what it is.
What is a Sprint?
A Sprint is a block of time, determined before you begin work, to commit to a set of work items. Pretty simple in concept, but it will take some fine tuning to get the performance you need.
The duration of the Sprint is based on the team and their needs. If you need to perform frequent releases or content that is small in size, a shorter 2-week Sprint may be perfect for you. If your team is larger or your content typically takes more than a week to develop, you might look at a 3-week Sprint.
Before the Sprint begins, the Agile Marketing team will estimate the current top priority Content Items on the backlog to show their level of effort. To learn more about this process, check out the section on estimating work for marketing teams. Estimates are used to drive what will fit within the time box so it is important to do this before planning your Sprints.
Once the estimates are complete and the priority has been determined by the Content Owner, you are ready to begin planning your Sprint. The ScrumMaster, the one who oversees the process, will review the availability of the team based on factors like holidays, vacation time, committed work to other projects, and ability to focus on content assignments. A number of days will be assigned to each person on the Content Development Team to show the time they will be able to spend on creating content in the Sprint.
Next, the total number of available days will be tallied up and a percentage will be applied to take into account the meetings and distractions that come with humans working. If we are doing Agile correctly, our meetings are not considered distractions, but I cannot guarantee others in the company are concerned with time as much as the agile team. The percentage that is applied is called the Efficiency Factor. Typically started at 70%, this will help bring the reality of the time box back into the process, where during the estimating we tried to remove it in isolation.
Why do we do this? Have you ever noticed a dip in your team’s performance during different parts of the year? Black Friday, Christmas, spring break, an industry conference, or the entire summer? These dates along with other performance impacting events can be determined before the sprint begins. Now we have the ability to apply the current reality to the estimates we conducted in our isolated place.
So as your team performs better or needs a little cool down, you can adjust the efficiency across the board. If only one member of the team needs the fix, drop or raise the amount of time they can commit to the Sprint.
No team will ever perform at 100% (or even 90%). If they are, you might check your estimates for padding or you have found the magic beans and you should be writing this content instead of me. All kidding aside, try not to set your team up for failure.
Failure and How the Team Commits
While we are on the subject of failure, we should look at the constraints of the Sprint and what they mean to the team. With the amount of available time calculated, the team will pull in Content Items from the backlog to work on. These items should be as close to the total amount of work available after the factor has been applied.
Example: 25 Total Resource Days * 70% Efficiency = 17 Available Days
The team at this point commits to creating the content in the timeframe allotted for the Sprint. Come hell or high water, if you are on this team, you will get this work done. If that means nights, mornings, or weekends, the team will be there so they can. In the famous words of Tim Gunn of Project Runway, “Make it work!”
This is the commitment I expect from my Content Developers and I believe it should be the norm. I am by no means a penny pincher or micro manager but I do believe in ownership of what you say you will do and the need for the team to sharpen each other’s swords to make sure they are battle ready. If one member is not pulling their weight, it is the team that will help bring them up or make the suggestion they should “be given to opportunity to excel somewhere else.”
Some other factors will creep into to the Sprint causing failure that are out of the team’s control. Items like changes in business priority and members of the team leaving happen and we do not want to punish the team for these actions.
If a member of the team is removed during the process, depending on what side of the Sprint you are on, a meeting should be held to determine if it is better to halt the work, re-estimate and plan a new Sprint or to go on as planned. Sometimes this can be as easy as removing one item that no one has started or just a few hours of extra work that the team is ok with because they want to finish strong. Whatever the case, the team should decide.
Breaking Content Items into Tasks
The team has committed to the work and we are ready to begin, right? Not quite. One final step we need to do is break the larger Content Items we have pulled in to the Sprint into smaller tasks. These tasks should be estimated by those who are eligible to work on them in hours rather than days.
As the members of the team grow in their ability to create different types of content, you will really start to see the benefits of these estimates only being blocked by the need to construct in a particular order rather than skillset availability.
Some argue against the idea of promoting an individual to be proficient at developing more than one type of content, but they would be wrong. Well maybe not that harsh, but their idea will be disrupted as people change the way they determine who they will do business with and companies look for new ways to reach them.
The tasks we create and estimate should embody the “entirety” of the Content Item (thanks for the word Robert Rose). Do not leave any known work off this list of tasks. If you think of something after the Sprint gets started, do not attempt to hide it. Make sure you create a task, estimate it, and place it on the board.
Putting a star or sticker on the task can help identify the forgotten work. You can discuss it during the Retrospective Meeting for consideration of inaccurate estimate of other Content Items.
Keeping Track of the Sprint
We won’t get into much detail in this piece about the task board, but for those of you new to the process, I should at least describe it. After the Content Items are determined and the tasks are created, it is time to place them on a board. These Scrum boards can be digital or physical boards and I have outlined the pros and cons in another section.
The Content Items and tasks should be grouped together and placed in a column with the header, Open Items. Next to that column, place another column named In Process, for…you guessed it, the tasks that are currently being worked on. Finally, place a third column on the far right called the Completed column for everything that is “Done.”
You Are Ready To Begin!
The very next step is to hold your first Standup Meeting to determine what you will work on first. Everyone who is a member of the Content Development Team for that day will assign work to themselves and mention any issues they currently have that will hinder their performance. The ScrumMaster will get to work on those issues and the team will start developing content.
I can’t wait to hear about your success (or challenges faced) with Agile Marketing. I monitor the LinkedIn Group for Agile Marketing and Content Developer, so if you have any questions or want to share your success, open a thread and tell your story. You can also join our Content Update newsletter for more posts like this one.