Agile marketing may not be a phrase you hear often, but it’s becoming increasingly popular and important.
Traditionally associated with development and product management, agile is a lightweight and, well, agile framework for software development and bringing features and products to market.
It stands in opposition to “waterfall” production methods that treat analysis, design, coding, and testing as discrete phases – where in agile they are treated as continuous.
As marketing becomes more data-driven, quantitative, and iterative, we can use many of these same management practices to hone our marketing campaigns, mitigate risk, and ultimately ship more effective marketing campaigns.
Before we dive into the marketing applications, however, let’s briefly cover what scrum is and how it came to be.
An Introduction to Scrum and Agile Development
“Scrum is a framework for developing and sustaining complex products.” sourced from the Scrum Guide.
- Simple to understand
- Difficult to master
While the Scrum framework was originally developed for tackling software development, it’s a flexible and functional framework that can be adapted to the problems a digital marketing team faces as well.
Many of these learnings are based on an experiment we ran on the HubSpot Academy with the goal of moving away from waterfall project planning to a more Agile Marketing Scrum strategy.
Don’t Reinvent the Wheel: Stick to the Framework
The Scrum framework is made up of Scrum Teams and their associated roles, events, artifacts, and rules. While it can be tempting to pick and choose parts of this framework, you’re best served to stick as closely as you can as this framework has withstood the test of time in many applications.
Successful use of the framework does depend on a certain level of maturity and alignment around a few core values:
- People personally commit to achieving the goals of the Scrum team.
- Team members have the courage to do the right thing and work on tough problems.
- Everyone focuses on the work of the Sprint and the goals of the Scrum team.
- The Scrum team and its stakeholders agree to be open about all the work and the challenges with performing the work.
- Scrum team members respect each other to be capable, independent people.
If your team can commit to these principles, then it is worth the initial learning curve to try implementing this highly effective and collaborative framework.
Basics of Scrum Framework
The basics of the Scrum framework fall into 3 categories:
Team is about unique roles on your team that enable the rapid and high-quality output that Scrum is famous for. Scrum events are a set of 5 repeating events that form the backbone of the framework. Finally, artifacts are the organizational tools such as sprint backlogs that let the team move efficiently with maximal self-organization.
Roles on a Scrum Team
There are three key roles that need to be filled. On a smaller team, you may find it makes sense for a team member to be a Developer (Individual Contributor) in addition to holding either Scrum Master or Product Owner roles.
The Product Owner
According to the Scrum Guide, the Product Owner is the sole person responsible for managing the Product Backlog. This includes:
- Clearly expressing Product Backlog items
- Ordering and prioritizing items in the Product Backlog
- Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next
- Ensuring the Development Team understands items in the Product Backlog to the level needed
The Product Owner roles likely already map well to what a traditional Project Manager at an agency or a Program Manager might be doing. Basically, the Product Owner handles work requests, schedules deliverables and works with Clients and Stakeholders.
If you don’t already have someone filling this role, consider having an individual contributor step up, as it’s very important to have a singular person as the manager of the backlog and as a bottleneck to insulate the development team from distractions, requests and shifting priorities.
The Product Owner is a single person and is the only person who can modify the Product Backlog, change work priorities for the Development Team and accept or reject incoming work requests.
This is a lot of responsibility but already maps well to what a good Project Manager will be doing in an organization.
The Development Team
The Development Team consists of the professionals who do the work of delivering client/business ready work increments for the Scrum Team. In a digital marketing context, these people may already have job titles like Digital Marketing Manager, CRO Manager, PPC Specialist etc.
In a by-the-book Scrum framework, these people all lose job titles and become simply “Developers,” who contribute their strengths and weaknesses to the team to deliver the goals of the Sprint.
The Development team is tasked by the business to self-organize and manage their own work. This helps to de-silo marketing teams and get more work done.
Per the Scrum Guide, Development Teams have the following characteristics:
- They’re self-organizing
- They’re cross-functional
- Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person
- Scrum recognizes no sub-teams in the Development Team, regardless of particular domains that need to be addressed like testing or business analysis
- Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole
One important note to call out here is the expectation that the development team is cross-functional. While this is ideal, it’s not always doable in a marketing context.
For example, a small agency may only have one videographer, but enough clients to justify two separate Scrum Teams.
In this case, just be flexible. The way we handled it on our team was to have the videographer budget several time slots per week to each team. This way, it’s known when we can reasonably tackle recordings so that the Sprint doesn’t get held up on that dependency.
The Scrum Master
The Scrum Master is a bit of a spiritual leader and coach to the Scrum Team. It’s a very meta role in that it exists to optimize and implement the Scrum framework.
The Scrum Master is a servant-leader for the Team. They act as a resource for those outside the Scrum Team to understand the process and adapt to it. The Scrum Master helps the organization optimize their interactions with the Scrum Team to maximize value created by using Scrum.
Here are some specifics of how the Scrum Master services various stakeholders pulled from the Scrum Guide.
Scrum Master Service to the Product Owner
The Scrum Master serves the Product Owner in several ways, including:
- Finding techniques for effective Product Backlog management
- Helping the Scrum Team understand the need for clear and concise Product Backlog items
- Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value
- Facilitating Scrum events as requested or needed
Scrum Master Service to the Development Team
The Scrum Master serves the Development Team in several ways, including:
- Coaching the Development Team in self-organization and cross-functionality
- Helping the Development Team to create high-value products
- Removing impediments to the Development Team’s progress
- Facilitating Scrum events as requested or needed
Scrum Master Service to the Organization
The Scrum Master serves the organization in several ways, including:
- Leading and coaching the organization in its Scrum adoption
- Planning Scrum implementations within the organization
- Helping employees and stakeholders understand and enact Scrum and empirical product development
- Causing change that increases the productivity of the Scrum Team
- Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization
Scrum Events for Conversion Rate Optimization
In traditional Scrum, there are 5 key events that every Scrum team participates in. The power of the events structure is that it’s a repeatable, iterative and straightforward to optimize process that a team of marketers can use to produce more work, better, in less time. The image below is a simple summary, we’ll dig into each event individually.
You’ve probably heard of a “Sprint” before. It’s definitely the most well-known Scrum Event.
The Scrum guide describes the sprint as “a time-box of one month or less during which a “Done,” useable, and potentially releasable product Increment is created.”
This concept has already made its way outside of the software world, with aptly titled books being written about it.
So you only need to modify the concept slightly to use it for your marketing team. We may need to alter the time a bit from the strict one month prescription the original Scrum framework allows, or at least get creative in chunking tasks to fit that timeframe.
We’ve seen success with relaxing the requirement that each sprint needs to have a releasable product at the end. Instead, each sprint must cross a milestone.
For example, if you’re running a two-week long sprint in which your team is doing an analytics deep dive to prepare for a round of experiments for a client’s site, you can set “Send audit findings to Client” as your sprint goal. Your next sprint after that might be to “Send test variation wireframes to Client”.
One more defining feature of a Sprint is that it’s typically set in stone what the goal will be, and any extra requests for work that will derail that goal will be put in the backlog and considered for inclusion in the next sprint. This can be tricky if you’re handling clients, as you know the process can be derailed by emergencies and urgent needs.
Take this into account and consider scheduling time into the week that’s not considered part of the sprint to handle “musts” from clients.
Before a Sprint goal can be established, a Scrum team needs to run a sprint planning session.
This planning session is where the whole team collaborates on defining the work to be done and the sprint goal for the upcoming sprint. Sprint planning time should be no more than 2 hours per week of the sprint. So a short two-week sprint should have a maximum of four hours of planning time before kickoff.
Sprint planning answers two key questions:
- What can be delivered in the upcoming Sprint?
- How will the work needed to achieve the Sprint goals be completed?
What can be delivered in the upcoming sprint?
This is where the Scrum team comes together to decide on what backlog items to focus on for the next sprint. Once the team has decided what to prioritize, they then work together to establish the overriding goal for the sprint.
Deciding on a singular Sprint goal may not always be practical for an agile marketing team with a variety of projects or clients ongoing. You can address this by establishing several goals for your sprint.
If you’ve been in CRO for a while, you undoubtedly know how to compile a test idea backlog. And if you’re using PXL, it should be relatively easy to decide what to focus on based on your prioritization score.
Once the team has decided on backlog items to work on this Sprint, and the overall goals for the Sprint, they can then focus on how to achieve the goals and complete the items slated for the upcoming Sprint.
How will the upcoming work be done?
When you decide what to focus on and how to conquer those items, you place them on a Spring Backlog.
This Sprint Backlog is what the team will reference during the Sprint as their source of to-dos during the Sprint. This planning is done collaboratively as the team self-organizes. The Product Owner can set some minimal guard rails for must-haves in the work.
The Daily Scrum (Standup)
Many marketing teams already do daily standups, so the daily Scrum (standup) shouldn’t be a novel idea.
According to the Scrum Guide, “The Daily Scrum is a 15-minute time-boxed event for the Team to synchronize activities and create a plan for the next 24 hours. This is done by inspecting the work since the last Daily Scrum and forecasting the work that could be done before the next one. The Daily Scrum is held at the same time and place each day to reduce complexity.”
During this meeting each team member answers three key questions:
- What did I do yesterday to help the team reach the Sprint Goal?
- What will I do today to help the team reach the Sprint Goal?
- Do I see any roadblocks ahead that will interfere with my ability to meet the Sprint Goal?
One of th biggest benefits of the daily Scrum is that it eliminates wasteful meetings that plague many companies. Rather than 5 different ad-hoc “touch bases” meetings every week, the team can tackle things up front, on a daily basis, in the daily Scrum stand-up.
Debrief & Share with the Sprint Review
Take a deep breath, your Sprint is over!
Hopefully, the team was able to work efficiently and flexibly and hit the Sprint Goals. With the Sprint over, it’s now time for the Sprint Review. This is the team’s chance to show off a little to the stakeholders in the work.
This meeting should take no longer than one hour per week of the sprint.
According to the Scrum Guide, the Sprint Review includes the following elements:
- The Scrum Team and key stakeholders attend the meeting
- The Product Owner explains what Product Backlog items have been finished
- The Development Team discusses what went well and what problems occurred
- The Development Team demonstrates the work that has been done
- The entire group collaborates on what to do next in order to improve subsequent Sprints
- Review of how the marketplace or potential use of the product might have changed
- Review of the timeline, budget, potential capabilities, and marketplace for the next anticipated release of the product
Coming out of the Sprint Review the team will have crossed items out of the Product Backlog as completed and Done. This will help set the course and objectives in the next Sprint.
Use the Sprint Retrospective to Iteratively Improve
The Sprint Retrospective (Retro) is where the team takes a critical look at itself and it’s wins and losses over the last Sprint. The objective here is to nail down improvements for the next Sprint.
Much like iterative optimization and testing, this is a time and space for the agile marketing teams to make themselves better with each and every Sprint by identifying inefficiencies and deciding on optimizations to correct them.
The Retro is after the Sprint Review but before the next round of Sprint Planning. This meeting should be no longer than roughly one hour per two weeks of Sprint time. This meeting is hosted and facilitated by the Scrum Master as they are the primary person responsible for making the Scrum team maximize efficiency and increase velocity.
Per the Scrum Guide, the Retros purpose is to:
- Inspect how the last Sprint went with regards to people, relationships, process, and tools
- Identify and order the major items that went well and potential improvements
- Create a plan for implementing improvements to the way the Scrum Team does its work
While improvements to the team’s processes can be made at any time, having a formalized and iterative process in place with the Retro can bring focus and ownership to how the team works and how to improve it.
Scrum “Artifacts” for Agile Marketing
In Scrum, there are three structures designed to provide transparency and accountability into the team’s work:
- Product Backlog
- Sprint Backlog
These things are key to creating the infrastructure that enables the iterative work processes that give Scrum its reputation for supercharging teams. They’re necessary for facilitating agile marketing in organizations.
Product Backlog (Client Backlog)
According to the Scrum Guide, “The Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.”
One distinction worth making here is that the term “Product Backlog” comes from software and product design, and can be changed to “Client Backlog” when looked at in the context of agency, or “Test Backlog” for a CRO team in any context.
The Product Backlog lists all “features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. Product Backlog items have the attributes of a description, order, estimate, and value.”
For a CRO-focused agency team, the “Client Backlog” might list all “Studies, tests, reports, and design work” that a client needs.
Product Backlog refinement is how the team builds and maintains the Backlog. This step is done by the Product Owner (Client Owner) and the Team.
This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items.
Items at the top of the Backlog will usually be clearer and more detailed than lower items as they get closer to being moved into the Sprint Backlog. Product Backlog items that are ready to be worked on and can reasonably be finished in the next Sprint are considered “Ready.”
According to the Scrum Guide,“The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal. The Sprint Backlog is a forecast by the Team about what functionality will be in the next Increment and the work needed to deliver that functionality into a “Done” Increment.”
The Sprint Backlog is the one place where the team tracks and monitors progress on items through the Sprint as they work toward the goals of the Sprint.
It’s important that the Sprint Backlog have enough detail that changes in progress can easily be understood in the Daily Scrum (Standup).
The Team modifies and moves items during the Sprint from Sprint Backlog to In Progress to Done. Kanban boards are a common way to visualize and track this flow. See the example below for how this might look:
One restriction that is key to maintaining the integrity of the Sprint is the concept of an “Increment.”
In software, this means a working new version of whatever is being worked on, but for a CRO or agile marketing team, this is a little different.
Basically at the end of a Sprint, whatever has been queued up as a Sprint Backlog item must be DONE. Not almost there – DONE.
This way as a Sprint wraps up, the tasks are finished as well, allowing the team to proceed to the next round of Sprint Planning with a clean slate and finished work.
Any task not finished is considered waste at the end of the Sprint and should be re-planned.
Customizing Scrum to Work for Agile Marketing and CRO Teams
Throughout this article, I’ve tried to include considerations for where the software roots of Scrum not mesh with the way digital marketers work. However, if you’re creative, you can apply almost all of this pretty directly.
The key challenge we faced implementing this on our content marketing team at HubSpot was that we tried to run Scrum half-time instead of fully committing. The downside to this strategy is that it actually ended up creating more work and stress for the team as we had both our personal backlogs as well as the Scrum backlog to manage and work on.
If I can recommend one thing to anyone who has read this and is going to test implementing Scrum, go all in. If it doesn’t work for your organization that’s okay, but commit to the test.
Scrum is a framework for agile product development, but the principles can just as easily be applied to create an agile marketing organization.
The benefits to this are many: faster iteration, more work throughput, better campaigns. An agile marketing organization is the perfect context for an experimentation or optimization team to thrive. It breeds a culture of experimentation – a data-driven and iterative culture.
In addition to this article, here’s some further reading to really master agile marketing:
How do you operate your marketing department? Is it more like the traditional waterfall marketing, or do you operate an innovative and agile marketing team?