Scrum Step by Step for Implementing Agile Marketing

Agile marketing might not be a phrase you hear every day, but it becomes more popular and important with each passing day. Traditionally associated with software development and management, agile is a lightweight and very agile framework for software/product development and for launching features and products to market.

It stands in opposition to "waterfall" production methods that treat analysis, design, coding and testing as discrete phases, whereas 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 improve our marketing campaigns, mitigate risks and, ultimately, ship more effective marketing campaigns.

Before we dive into marketing applications, however, let's briefly cover what scrum is and how it came to be.

What Is Scrum?

Scrum is a framework that helps teams work together. Like a rugby team (where the name comes from) training for the big game, Scrum encourages teams to learn through experience, to organize themselves while working on a problem, and to reflect on their wins and losses in order to continuously improve.

While the Scrum I'm talking about is most often used by software development teams, its principles and lessons can be applied to all kinds of teamwork. That is one of the reasons Scrum is so popular.

Generally considered an agile project management framework, Scrum describes a set of meetings, tools and roles that work together to help teams structure and manage their work.

An Introduction to Scrum and Agile Development

Developed in the 1990s by Jeff Sutherland and Ken Schwaber, Scrum is:

• Lightweight
• Easy to understand
• Difficult to master

Although the Scrum framework was originally developed to handle software development, it is a flexible and functional framework that can be adapted to the problems that the digital marketing team also faces, since they too develop software and other types of products.

For the most part, this guide will run parallel to the original Scrum guide, with a few differences and changes to better align with the somewhat more ad-hoc nature of marketing and optimization work.

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 may be tempting to cherry-pick parts of this framework, it's best to stay as close to it as possible, since this framework has stood the test of time across many applications.

Successful use of the framework depends on a certain level of maturity and alignment around a few core values:

• People personally commit to hitting their Scrum team's goals/objectives.
• Team members have the courage needed to do what needs to be done and to work on hard problems.
• Everyone stays focused on the sprint activities and the Scrum team's goals.
• Scrum members and their stakeholders agree to be open about the work and the challenges involved in getting it done.
• The Scrum team respects each other as independent and capable people.

If your team can commit to these principles, the initial learning curve is worth it in order to try to implement this highly effective and collaborative framework.

Scrum Framework Basics

The basic principles of the Scrum framework fall into 3 categories:

• Team
• Events
• Artifacts

The members have unique roles on their team, which enable the fast, high-quality results Scrum is known for. Scrum events are a set of 5 repeated events that form the backbone of the framework. Finally, artifacts are the organizational tools, such as sprint backlogs, that allow the team to move efficiently with maximum self-organization.

Roles on a Scrum Team

There are three main roles that need to be filled. On a smaller team, you may find it makes sense for one team member to be a Developer (individual contributor) while also filling the Scrum Master or Product Owner roles.

Image source

The Product Owner

According to the Official Guide, the Product Owner is the only one within the project who has the responsibility of managing the Product Backlog. This includes:

• Clearly expressing Backlog items
• Requesting and prioritizing items in the Backlog
• Ensuring that the Product Backlog is always visible and clear to everyone, and shows what the Scrum team will work on next
• Ensuring that the Scrum (development) Team fully understands the items in the Product Backlog to the level needed

The Product Owner's role is likely already well mapped to what a traditional project manager at an agency or a program manager might be doing. Basically, the Product Owner handles work requests, schedules deliveries and works with Clients and Stakeholders.

If you don't yet have someone filling this role, consider having an individual contributor step up, since it is very important to have a single person as backlog manager and as a bottleneck to shield the development team from distractions, requests and changes.

The Product Owner is a single person and is the only person who can modify the Product Backlog, change the Development Team's work priorities, and accept or reject incoming work requests.

That's a lot of responsibility, but it already maps well to what a good project manager will do in an organization.

The Development Team

The development team is made up of the professionals who do the work of delivering finished increments to the client/company for the Scrum team. In a digital marketing context, these people may already have titles like Marketing Manager, and so on.

In a standardized Scrum framework, all these people drop their titles and simply become "Developers," who contribute their strengths and weaknesses to the team in order to achieve the Sprint's goals.

The development team is entrusted by the company to self-organize and manage its own work. This helps free up marketing teams and get more work done.

According to the Scrum Guide, development teams have the following characteristics:

• They are self-organizing
• They are cross-functional
• Scrum does not recognize titles for development team members other than Developer, regardless of the work being carried out by the person
• It is not part of the Scrum methodology to recognize smaller teams (sub-teams) as part of the development team, whether they are focused on something specific or on testing and analysis
• Each member among the developers may have specialized knowledge or skill, but accountability for the project belongs to the whole team and not to a specific member

An important note to highlight here is the expectation that the development team be cross-functional. While this is ideal, it isn't always possible in a marketing context.

For example, a small digital marketing agency may have only one video editor, but enough clients to justify two separate Scrum teams.

In that case, just be flexible. The way we handled this on our team was to have the video editor be available across several time slots per week for each team. This way, we know when we can reasonably handle the recordings so the sprint doesn't depend entirely on that one dependency.

The Scrum Master

The Scrum Master is something of a leader and coach for the Scrum team. It's a very important role, since 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 its interactions with the Scrum team to maximize the value created through the use of Scrum.

Here are some specifics on how the Scrum Master serves various stakeholders, drawn from the Scrum Guide.

Scrum Master Service | Product Owner

The Scrum Master supports the Product Owner in multiple ways, including:

• Applying the best techniques for efficient management of the Product Backlog
• Helping the Scrum team understand all items in the Product Backlog clearly and concisely
• Ensuring the Product Owner can manage the Product Backlog in a way that finds maximum value
• Facilitating Scrum events as requested or needed

Scrum Master Service | Development Team

The Scrum Master supports the development team in multiple ways, including:

• Coaching team members in cross-functionality and self-organization
• Supporting the development team in creating new products in an agile manner
• Removing impediments to the Development Team's progress
• Facilitating Scrum events as requested or needed

Scrum Master Service | Organization

The Scrum Master supports the organization in multiple ways, including:

• Leading and coaching the organization in Scrum adoption
• Planning new Scrum implementations within the company
• Helping employees and stakeholders understand and implement Scrum and empirical product development
• Causing changes that increase the Scrum team's productivity
• Working together with other Scrum Masters to improve the effectiveness of Scrum's application within the company

Scrum Events for Conversion Rate Optimization

In traditional Scrum, there are 5 main events in which every Scrum team participates. The power of the event structure is that it is repetitive, iterative and a straightforward way to optimize the process a team of marketers can use to produce more work, better, in less time. The image below is a simple summary; we'll cover each event individually.

Image source

The Sprint

If you have any familiarity with agile development methodology, you've probably already heard of the Sprint. It is without a doubt the best-known Scrum event.

The Scrum Guide describes the sprint as "a period of one month or less during which a 'Done', usable, and potentially releasable product increment is created."

This concept has already moved beyond the software world, with entire books appropriately written about it.

So you only need to modify the concept a little to use it with your marketing team. You may need to adjust the timing away from the strict one-month prescription allowed by the original Scrum framework, or at least be creative about splitting tasks to fit that timeframe.

We've seen success by loosening the requirement that each sprint needs to have a releasable product at the end. Instead, each sprint should cross a milestone.

For example, if you're running a two-week sprint in which your team will do a deep dive into analysis to prepare for a round of experiments on a client's website, you could set "Send audit findings to the client" as your sprint goal. Your next sprint after that could be "Send test variation wireframes to the client."

A more defining characteristic of a sprint is that its goal is usually clearly set, and any extra work requests that would derail that goal get placed in the backlog and considered for inclusion in the next sprint. This can be tricky if you're dealing with clients, since you know the process can be disrupted by emergencies and urgent needs.

Take that into account and consider scheduling a time during the week that isn't counted as part of the sprint to handle clients' "chores."

Sprint Planning

Before a sprint goal can be established, a Scrum team needs to run a sprint planning session.

In this planning session, the whole team collaborates on defining the work to be done and the sprint goal for the upcoming sprint. Sprint planning time should not exceed 2 hours per week of the sprint. So a two-week sprint should have at most four hours of planning before it starts.

Sprint planning answers two main questions:

• What can be delivered in the upcoming Sprint?
• How will the work required to achieve the sprint goals be completed?

What Can Be Delivered in the Next Sprint?

This is where the Scrum team gets together to decide which backlog items to focus on in the next sprint. After the team decides what to prioritize, they work together to establish the sprint's main goal.

Deciding on a single sprint goal may not always be practical for an agile marketing team with several projects or clients in progress. You can address this by setting multiple objectives for your sprint.

Once the team has decided on the backlog items to work on during this Sprint and the overall Sprint objectives, they can focus on how to achieve the objectives and complete the items planned for the upcoming Sprint.

How Will the Upcoming Work Be Accomplished?

Once you decide what to focus on and how to achieve those items, you place them in a Sprint Backlog.

Image source

This sprint backlog is what the team will reference during the sprint as its source of tasks throughout the sprint. This planning is done collaboratively as the team self-organizes. The Product Owner can set some minimal guardrails for essential items in the work.

The Daily Scrum

Many marketing teams already hold daily meetings, so the Daily Scrum shouldn't be a novelty.

Referencing the Scrum Guide, "The Daily Scrum is a 15-minute meeting for the team to adjust activities and plan activities for the next day of work. This task is carried out by inspecting the work done since the last Daily Scrum and forecasting the work that could be done before the next one. This meeting is held the same way each time, including time and place, in order to reduce complexity."

During this meeting, each team member answers three main questions:

• What activities did I do yesterday that help hit the sprint goal?
• What activities will I do today to help hit the sprint goal?
• Are there any obstacles ahead that will interfere with my ability to meet the sprint goal?

One of the biggest benefits of the Daily Scrum is that it eliminates the unnecessary meetings that plague many companies. Instead of five different ad-hoc "touch base" meetings each week, the team can handle things ahead of time, daily, in the Scrum's daily stand-up.

Review and Share the Sprint Review

Take a deep breath, your sprint is over!

Fortunately, the team was able to work efficiently and flexibly and hit the sprint's objectives. With the sprint finished, it's now time for the sprint review. This is the team's chance to show a bit of the work to the stakeholders.

This meeting shouldn't take more than one hour per week of the sprint.

According to the Scrum Guide, to review a sprint you should:

• Have the Scrum team and all stakeholders attend the meeting
• Have the Product Owner explain which Backlog items were successfully completed
• Have the development team assess what flowed well and what didn't work
• Have the development team show the work that was completed
• Have the whole group collaborate with ideas about what to do next to improve future Sprints
• Take a moment to review how the market may have changed during this period and how the product is being used
• Take a moment to review the timeline, budget, potential resources and market needs for the next product release

Coming out of the sprint review, the team will have crossed off Product Backlog items as completed and Done. This will help set the course and objectives for the next Sprint.

Use the Sprint Retrospective to Improve Iteratively

The sprint retrospective (retro) is where the team takes a critical look at itself and its wins and losses over the last sprint. The goal here is to define improvements for the next Sprint.

Just like iterative optimization and testing, this is a time and space for agile marketing teams to improve with every run, identifying inefficiencies and deciding on optimizations to fix them.

The Retro comes after the sprint review, but before the next round of sprint planning. This meeting shouldn't last more than one hour for every two weeks of run time. This meeting is organized and facilitated by the Scrum Master, since they are the main person responsible for getting the Scrum team to maximize efficiency and increase velocity.

According to the Scrum Guide, the purpose of the Retro is to:

• Inspect how the last sprint went with regard to people, relationships, processes and tools
• Identify and order the main items that went well and possible improvements
• Create a plan to implement improvements in the way the Scrum team does its work

While process improvements for the team can be made at any time, having a formalized, iterative process 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 for the team's work:

• Product Backlog
• Sprint Backlog
• Increment

These are the keys to building the infrastructure that enables the iterative work processes that give Scrum its reputation for keeping teams on track. They are necessary to facilitate agile marketing within organizations.

Product Backlog (Client Backlog)

Following the official Scrum Guide, "The Product Backlog is fundamentally composed of a list, ordered logically, of everything that will be required in the product, and it is the single place where the requirements for all pending changes to the product are gathered. The Product Owner is the person who is responsible for this Backlog, from its content to its availability."

One distinction we need to make here is that the term "Product Backlog" comes from software and product design, and it may also be used as "Client Backlog" when analyzed in the context of an agency, or "Test Backlog" for a CRO team in different contexts.

Image source

The Backlog lists the "features, functions, requirements, enhancements and fixes that make up the modifications to be made to the product/software in future releases. Product Backlog items have attributes of description, order, estimate and value."

For agency teams focused on CRO, the "Client Backlog" can list all the "studies, tests, reports and design work" that the client needs.

A process of improvement and refinement of the Product Backlog is how the team creates and maintains the Backlog. This step is carried out by the Product Owner (Client Owner) and the Team.

This should be an ongoing procedure, in which the Product Owner and developers offer their input on all the details of the items listed in the Backlog.

Items at the top of the Backlog will most often be clearer and more detailed than items further down, 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 completed within the next sprint are considered "Ready."

Sprint Backlog

According to the official Guide, "The Sprint Backlog is made up of items from the Product/software Backlog selected for the Sprint, plus a plan for delivering the product increment and hitting the goal set for the Sprint. It is the team's forecast of what the functionality will be in the next increment and the work needed to deliver that functionality in an increment with 'Done' status."

The sprint backlog is the single place where the team tracks and monitors progress on items during the sprint, while working toward the sprint goals.

It is important that the sprint backlog have enough detail so that ongoing changes can be easily understood in the Daily Scrum.

The team modifies and moves items during the sprint from the sprint backlog to In Progress to Done. Kanban boards are a common way of visualizing and tracking this flow.

Increment

An essential constraint for maintaining the integrity of the sprint is the concept of an "increment."

In software, this means a new functional version of whatever is being worked on, but for an agile marketing or CRO team, this is a bit different.

Basically, at the end of a Sprint, everything that was queued up as a sprint backlog item must be DONE. Not almost there, DONE.

This way, as the sprint ends, tasks are also completed, allowing the team to move on to the next round of sprint planning with a clean slate and completed work.

Any task not completed is considered waste at the end of the sprint, so it will need to be planned again.

Customizing Scrum for Use with Agile Marketing and CRO Teams

In this article, I tried to include considerations for where Scrum's software roots don't quite fit the way digital marketers work. However, if you get creative, you can apply almost all of it directly.

The main challenge some companies face when implementing it on their content marketing teams is trying to run Scrum part-time instead of fully committing to it. The downside of this strategy is that it ends up creating more work and stress for the team, since in this case there are personal backlogs as well as Scrum to manage and work through.

If I can recommend one thing to anyone who has read this and is going to test out implementing Scrum, it's to go all in. If it doesn't work for your organization, that's fine, but commit to the trial.

Conclusion

Agile development (Scrum) is a framework for the agile development of software, but this framework can easily be applied to marketing teams at agencies or even to departments of companies in other sectors.

The benefits from this are many: faster iteration, more productivity, better campaigns. An agile marketing organization is the perfect context for an experimentation or optimization team to thrive. It creates a culture of experimentation, an iterative, data-driven culture.

How do you run your marketing department? Is it more like traditional waterfall marketing, or do you run an innovative, agile marketing team?