Building Your Agile Marketing Engine

Episode Transcript

Welcome to the Agile Marketing Edge, the first podcast dedicated to turning Agile theory into real-world marketing breakthroughs. I'm Andrea Freireir, CEO of Agile Sherpas, and your guide on this climb to smarter, faster, outcome-driven marketing.

Every week, we unpack the what, who, and how behind Agile marketing. From building high-velocity workflows and slashing waste to measuring what really matters and scaling success across teams. You'll hear quick-hit strategies you can deploy today, plus candid stories from marketers who've traded chaos for clarity and never looked back. And because no Sherpa Summit's alone, I'll be joined by trailblazing guests, coaches, practitioners, CMOs, and other experts, sharing the sharp tactics and hard-won lessons that keep them on the leading edge.

So lace up those virtual hiking boots, limit your whip, and let's start ascending. This is your weekly shot of practical, no-fluff, agile insights so you can deliver more value with less busy work and love your marketing again. Hit follow wherever you listen and let's carve the next switchback together.

Hello and welcome to the Agile Marketing Edge. I'm your host, Andrea Fryrear and this week we are starting at the core, the center, the heartbeat of every great Agile team, the backlog. So we need to start with a definition because the backlog has kind of gotten a bad rap over time. People say, I'll just put it in the backlog and that has been.

Come to mean I will throw it in a pile of stuff that will never get touched or seen ever again, certainly it will never get worked on. But when we use this term in an agile marketing context, the backlog does not have this meaning at all. It is in fact, as I said at the start, an engine for driving everything that an agile marketing team does. In many ways,

You can think of it like a to-do list, except a to-do list on steroids, because it is ruthlessly prioritized and it's constantly evolving based on the realities of what's happening with the work and with the data and with the people doing the work. So it's always prioritized, and it is a list of all the work that the team

Has not started yet. As soon as the work begins, it leaves the backlog and goes through your visual work management system, which we will tackle in another episode. But the backlog is for non-started work. This is how we understand the work coming up. This is how we collaborate and negotiate with other teams, with internal stakeholders, with one another, people who are doing the work together.

So that we have shared understanding about what really needs to be done before the work begins. Because we've all experienced this, right? You start a project, or you start even a task, and you thought you knew what it was supposed to be, and you get about 30 % done with it, and then you realize you are completely confused. Or you get 80 % done with it, and you show it to the stakeholder, and they are totally baffled by what you've created because it wasn't what they wanted at all; both instances are a waste where you have done a lot of work and none of it is usable. And so the backlog is one of many agile tools that we use to avoid that rework and that waste. And as I said, it also allows us to collaborate and prioritize really, really effectively. So always prioritized, work at the top is the most important, and then we go down from there. The best-case scenario is you use some sort of project management tool that is set up for an agile view because these will force you into a ruthless prioritization mode.

Because you shouldn't have two number one priorities on a backlog. It should go one, two, three, four, five, all the way down to the bottom. And we'll get into more detail as the podcast episode goes along about exactly what priorities need to do over time and how do you make sure it's in the right order and things, but it does need to always be prioritized. So that's what a backlog is. Let's talk a little bit now about how we use it. What are some of its most common use cases?

First, let's talk about just an individual's backlog. Because even on a team, an individual will still have a backlog view of their own individual tasks. And even if you're not on an agile team, by the strictest definition, you, as an individual contributor, or as a leader, or a business owner, anyone, can use a backlog. And in my humble opinion, everyone...Should have a backlog.

This is the most common-sense, effective, brilliant way to manage knowledge work that I have ever seen. So everyone should have one of these. And it's pretty simple if it's just an individual's backlog, because this is what is the highest impact, most valuable activity that I as an individual could be doing right now, next. That goes at the top. And then, a ll the way down. And the beauty of the backlog is that it is blended, right? So I have an individual backlog that encompasses everything I have to do to run Agile Sherpas and be a contributor to things like this podcast and to our social profiles.

So that plus managing our finances and meeting with clients and talking to potential partners and meeting with attorneys, all of the fun things you get to do as the CEO of a company, all of that has to be blended together so that I can be sure that the most critical work is getting done at the right time. Same thing when I was a content strategist for a software company, every single activity that I needed to do to serve customer content, sales enablement content, all of that goes into one backlog.

It can be very tempting to split them up, but then instantly you lose the prioritization because now you're ping-ponging back and forth between the internal backlog and the sales and employment backlog and then this backlog, right? And so you haven't forced yourself to compare things to one another in order to determine what is actually most impactful. So the backlog needs to be blended for an individual.

And for every other category that we're going to talk about. So as an individual, beautiful entry point to agile practices, highly, highly, highly recommend. Get one right after this podcast. Go do it. your homework. Do it right after you listen to this episode. Next use case is to do this with a team. This is going to be sort of the next level up in difficulty and in time investment.

So you could probably build your first individual backlog in a couple of hours if you have a good strong understanding of your work already. It's gonna take you half a day to get your first backlog up and running with a team because now you've got a lot of humans running around who all have their work probably documented in different places and you're gonna have to blend it together because we want a shared understanding of how everyone's actually spending their time. And this is gonna be what we do for other people, what we do for the team, because unless it's all out in the open, we cannot effectively prioritize.

It will be very tempting for team members to hold things back. Well, this is just a thing I have to do every week. I have to run this report every week. It only takes me half an hour, so I'm not gonna put it on the board. No, put it on the board. In the initial phase, put everything on the board. What you'll find is how shockingly busy everyone around you is. This is such a good empathy builder when I work with teams. People are like, my goodness, I had no idea how busy my colleagues are. And...

You get a lot more sympathy and empathy for why it takes so long for things to get back to you from people. And also, your leaders cannot help you deprioritize or say no to things if they don't know that those are the things you're working on. So everything needs to go out into the backlog and then we have the power to pull things off, to deprioritize things, but for a team, it needs to go on there.

The real magic of scaled agility happens when multiple teams are doing this. And this is where the use cases get the most complicated but also the most powerful. Because in marketing especially, almost inevitably you have shared resources across teams, right? So I am a writer, I probably provide content for two, three, five, seven, a lot of teams. And so if I have my work now visualized in all of those teams backlogs, I and my supervisors can understand the full scope of my commitments. And without that, it's difficult to understand how overwhelmed and overburdened people actually are.
And then you can start to see patterns. we are really over committed on this particular project. We're spending way too much time on this product line or on this business unit or on this product segment, this persona, right?

So we're gonna talk more about how you tag and segment work within the backlog. But once you get to that point, as a leader, you have this beautiful bird's eye view of what's really happening in your teams and it's so powerful and allows for good air traffic control and protecting teams from interruptions. It makes leaders far more effective and it makes the people doing the work far more empowered and it helps them to enjoy what they're doing more as well because they can see how their work ladders up to bigger priorities.

All right, so those are the three use cases for a backlog, individual, team, and scaled across teams. All amazing, do them all. But if you need to just start with your own, that is completely valid and you should absolutely go and do that today. Once you have a backlog, it does not stay static. You build it today as your homework, and then you're going to be continuing to touch it and refine it and improve it all the time.
And so how you're gonna know that your backlog is healthy and that you are keeping it in a good state to be a well-oiled engine to drive your work, there are many criteria that we wanna use to keep it healthy.

The first is that it needs to be sufficiently detailed. So if your name of your work item in your backlog says, write blog post. It's not very detailed. It's going to be difficult if you just threw that in there quickly as you were in a meeting and then a week later you come back and you're like, what's the blog post supposed to be about? Is that a blog post for us? Is it a guest post somewhere else? Am I supposed to write it? Am I supposed to get somebody else to write it? Am I supposed to interview a client for that? I can't remember. It was such a good idea. Now it's gone.

Right, so providing good detail for yourself when you make a card is important, but then also if somebody from outside your team wants to log into your board and understand what's going on, it should be relatively easy for them to do so without pinging you and asking you to explain the contents of the whole card, because that defeats the purpose of visually managing your work in the first place. It should be, a clear document that reflects the reality of the work.

So if I need an update, I can just go to this card and understand, I don't have to talk to you. I can save you a meeting. Isn't that lovely? So keep a good level of detail in your card. And as you're working on it, update the card. Met with so-and-so, agreed on this next step. Here's a link to the meeting notes. This is a PDF of the draft, we agreed to make these changes. If you use anything like Canva or some other collaboration and creative tool, link to the living documents, like Google Docs or any of those things, link to the Slack conversations about it. Keep it all in one place. You want your backlog to be the single source of truth about the work. And so, closely related to this, your work items, which is the name of the thing that lives in your backlog.

We're gonna talk about how big those need to be later. They need to be up to date. And if we're using backlogs for teams, or very much if we are using them for scaled teams, everybody has responsibility for their own cards.

It's not just a project manager or a scrum master's job to update the cards. The people doing the work who are putting hands to keyboard multiple times a day, those are the ones who keep the cards up to date. And that's the only way that people will trust that the board is true and that the backlog is real is if it has current information on it. And so if a project gets canceled or deprioritized or bumped to the top of the list, your backlog should include all of that information. Okay.
We can't talk about backlogs without talking about estimation. If you've been on an agile team, no doubt you've had the estimation debate.

Buckle up, we're gonna talk about estimation right now. All right, what estimation is, is estimating the amount of effort that an item in the backlog is going to take. Here's why this is a big issue. Humans are terrible at this, really bad. We are just terrible at guessing this, unless it's a task that we've done many times and it's
Exactly like the task we did like a day ago, we're gonna get it wrong. And so we've come up with all of these little tips and hacks and tricks to try to get it less wrong, but it's never perfect. So the question is always, is it worth going through the time and trouble to actually estimate the work if we know it's not gonna be great anyway?

This is an individual decision that you and your team will have to decide for yourself. I cannot tell you what is the exact right answer for you. What I can tell you is the best reason that I've ever seen to go through the time and trouble of estimation is to have a data-driven tool with which to say no to work. Because if you can
And quantify how much work you're doing and how that compares to the amount of work you have historically completed in a set amount of time, you can now confidently say there is no way we will get that thing done in the amount of time you think we will. And that's not because we're lazy, it's not because we're not working, it's because the data that we have been keeping shows we complete this much work in a week, in two weeks, in a month, and you're asking us to do 30 % more than that, or twice as much as that, and that is not a reasonable thing to expect.

If you struggle with unreasonable expectations from your stakeholders, then estimation can help with that. It's not a simple thing. It takes time and effort. Maybe this is a future podcast episode where we just talk about estimation, but it's sometimes worth the hassle. So you will have to grapple with this decision yourself, but some kind of estimation in the backlog items can be what is absolutely never up for debate is that your backlog must be prioritized. And ideally, we prioritize by value to the business, to the customer, not just by due date or urgency or how hot the flames are around a particular task or project.

So, hopefully we're able to say this is the most impactful and important work and it is at the top and then so forth all the way down. Certainly deadlines are a factor. We are sponsoring an event, things must be done at a certain time. That is a thing. We always put out an email at this time. That is real. But hopefully we are only doing those things because they add value to the business, to the customer.

So the more we can prioritize by value, the better. Talked a little bit about this, but we'll explicitly say it here. The backlog should be visible. Even if it's your personal backlog, it's nice to have it open so others can check it out if they want to. And I found it's very useful to bring it to one-on-one conversations with your manager, with other stakeholders, so that they can understand what you're working on.
When I was a content marketer, I was the only writer in the whole building, and it was super helpful to have my backlog out where others could see it. Back then, this is dating myself a little bit here, but back then we used sticky notes to put our backlogs up on the wall, and people would come to my desk and I would show them what I was working on and what was in the backlog.

Oftentimes they would say, I had no idea like all this other work was coming up. no, really this is 10th priority compared to other stuff that you've got going on. So it can be really helpful for the backlog to be visible, especially if you're using this for a team. You've got to have a shared blended view. Even if people's boards get sorted out separately for them to see their own so they can manage their day-to-day tasks, that's fine, but you've gotta have a shared, blended view for the team. Must, must, must.

Okay, as we've said, the board is not a set it and forget it. The backlog is a living, breathing entity that should reflect the realities of work. So we don't get to just do it once. This is a constant activity. So some best practices for maintaining your backlog over time. Ideally, you have a mechanism by which m any people can add things to the backlog. Now depending on how big your team or your organization is, you may wanna put some guardrails around this because what you don't want is 300 cards in your backlog that you just can't possibly put your arms around.

You can have an icebox or a to-be-reviewed area where then leaders can parse ideas and pull the best ones in to the real backlog. That's one way to kind of create a filtering mechanism. But it's good to capture people's ideas, right? Especially if you get a lot of incoming requests, you can say, great. Type, type, type, type. I've documented your idea in our backlog and we will get to that at our next refinement session.

We'll come back to you with questions. I'm so excited to work with you on this. But you didn't commit to start it. You did not commit to do it tomorrow or even next week. You committed to explore and understand and document it. And the next time you do a backlog refinement session, which is where you get it down and go and do all the things we talked about to keep your backlog healthy, right? Add detail, add effort estimation, add prioritization, all of those things while you're doing that. Then you can go and talk to the person whose idea it was and decide whether that item needs to stay in the backlog or not.

But always good for team members at the very least to be able to participate in backlog health activities. Ad cards suggest that cards have aged out and should be removed, right? This was a good idea at the time, but we never got to it, and now it's really not relevant. Don't be afraid to pull things off the board. It should be a real-time reflection of priorities, and priorities change. So, cards coming off the board is a good thing.

All right, so we've been talking about how lots of people can maybe add things to the backlog, and you might be imagining how it can, very quickly, get out of control. And you're not wrong. It can. So what you want is to have a final decider, an arbiter of the backlog's final state. We often call this a marketing owner. It's borrowed from the phrase product owner, which is what software developers use.

You can call it whatever you want, and it can just be a team lead of some kind. But someone needs to be formally anointed as the owner of the backlog. They will be the one to finally choose what the high priority items are. They will be the one ultimately responsible for its state of refinement and to ensure that conversations are had when they need to be had with stakeholders. So final decider is ideal.

If you can avoid backlog management by committee, avoid it. Speaking of involving others and refreshing the backlog often, I strongly strongly strongly recommend at least once a quarter do a 90 minute to two hour backlog review and have people from the team join you periodically to get real about whether the stuff in the backlog still belongs there or should be pulled out. And that's gonna make sure that you don't end up with a bunch of old irrelevant work in there that you keep touching and never working on.

So plan for some hard refreshes. It's like spring cleaning, right? Do it every quarter and just keep the backlog clean and nicely organized.

Okay, we need to talk about complicated backlogs. Because part of the backlog is gonna get complicated, right? The way that I'm talking about it so far, it sounds nice and simple. And the concept is quite simple. But once you sit down and start doing it, you're gonna realize that there's a lot of nuance. So I wanna prepare you for what that's gonna look like.

Because as soon as you start to document stuff, right? You're gonna start to write down the work that you're doing. And part of the questions are gonna be, do I write down a task in this card? Do I write down a project? Is it a campaign? If you've heard about Agile before, you might have heard the phrase user story. Is it a user story on this card?

And the answer, just like I told you with estimation, is a little bit of you're gonna have to explore for yourself. And in my experience, and the way that we do it at Agile Sherpas, is you're gonna end up with a mix. Some cards will be really big. We call them epics, our OKRs, our quarterly big objectives, are epic cards. They're really big.

And they will stick around for a while in the backlog. And they will have a lot of subtasks underneath them. And then we will pull a subtask out of that card and into active columns. We use sprints, but we'll pull it into a sprint.

But sometimes there's more of a one-off activity, right? So, I'll give you an example. We recently needed to update our About Us page to change out some of the people who were on that page. So that was an important piece of work that needed to be done. It wasn't a big thing, but it needed a card because it took some capacity from the team.

So that got its own individual card in the backlog, and that moved out and through the sprint pretty quickly. But that was a much smaller card than an OKR card that has lots of subtasks and lots of activities underneath it.

What you wanna keep in mind is the point of the backlog. The point of the backlog is to visually manage work so you can have shared understanding from the people doing it and they can collaborate effectively.

So, set up the cards to accomplish that goal. Don't get too caught up, especially in your first go, on having them all be exactly the same, c an them all be perfect? Feel it out.

Try adding subtasks, little checklists, right, of when all of these are done, then the card is done, or they can be separate projects of their own. Feel out what feels right for your team, and make sure you're having conversations with the people doing the work regularly so that you know if it's working for them or not. There's a lot of options on how to do this.

You can also give other indications of how to address a card using other visual cues. So you can label something with a priority, high, low, for example. Or you can give it a label, is it lead generation, is it sales enablement, is it content marketing, is it an experiment, you can have different labels.
Maybe it belongs to a certain business unit or a certain product line that can have a different color on the card. So all of these things are possible. Not all of them are necessary.

So keep in mind, coming back to the purpose of the backlog, visual management. We wanna be able to understand the work visually and easily. So if a priority label helps you do that, add a priority label. If color coding gives you a quick, hitting understanding of where the team's capacity is going, awesome, add those in. But remember that especially with modern project management tools, there's also a lot of opportunity to sort and filter. And so you can use some of those capabilities to get at that same information.

In my experience, keeping things simple is often the preference. So, when in doubt, keep it simple and let the tool help you. Don't add complexity just because it's got that feature.

Let the process dictate what the tool does for you. Don't let the tool dictate how your process needs to work.

All right, so there we go. That was the deep dive into what a backlog is, how it needs to work, and how you need to keep it healthy. This is like the engine of your agile team. So just like the engine in your car, you can't expect it to run well if you don't ever take care of it. So make sure that you do.

If you've got a backlog and you're struggling with how to prioritize it specifically, we just released a brand new micro course on that. So it's designed to help you prioritize your backlog in 30 minutes or less. And you can find that at theropes.agilesherpas.com. And of course it will also be in the show notes.

Thank you so much for being here. And until next time, remember, the struggle is real, but so is agile.