Using Agile concepts to manage Marketing work
January 28, 2015
Here is a process for managing marketing work that I’ve found to be very successful. In fact, based on my estimates, it lets us get at least 30% more work done. It incorporates some Agile concepts.
Everything we have to do is in a ticket management system, as a ticket.
Well, what’s a ticket? Tickets are little chunks of work, like “Design a banner”, or “Fix this bug on the website.” They could also be “Produce this email”, for example. They’re stored and displayed in a format that lets us easily track comments and other stuff that’s related. We use Jira, but a lot of people swear by Trello.
When we open each ticket, we first make sure we understand what it is, then we assign it a number of Story Points. Story Points, for us, roughtly correspond to the number of hours the ticket is expected to take. (Other teams use Story Points to mean other things.)
Ideally, a ticket is the smallest possible useful chunk of work. That helps us deliver useful things faster, rather than waiting until any particular set of interdependencies is resolved. Figuring out how to break big projects into useful pieces also helps us work more efficiently in general, by prioritizing the separate parts of each large project that have the highest ROI.
Every two weeks, we set out what work we’re doing for the following two weeks. This is a “sprint period”. You can use other periods, like one, or three weeks. The sprint planning meeting is useful, because, in conjunction with our Story Point (hour) estimates, we know how much we can plan to get done with the time that we have. And in the planning, we have to think ahead, and we have to force-rank work; some things make it into a sprint, and some don’t. That:
- Forces us to have an explicit conversation about priorities, and tradeoffs
- Reduces the amount of unneccessary work, because we don't start on things that aren't ready to be started on
- Makes it easier for problems and dependencies to be exposed before work starts, because everyone starts thinking about the work in advance
- Reduces the amount of low-value, high-urgency work that we do, since (a) it is known that adding work to a sprint is expensive, and (b) something has to be explicitly dropped in order for the new work to be done
Within the two-week period encompassing the sprint period, we retain flexibility by working on a small number of things at a time, which means that, if necessary, we can swap out tasks that have not yet been started for other ones that have come up.
We also build in a buffer of unallocated points. This is actually a really bad idea, since buffers hide problems. For example, if we are building in a buffer because one particular team tends to wait until the last minute to submit requests, we should be trying to fix that actual problem. But a buffer is what we do for now.
During the sprint planning meetings, we also review the previous two weeks of work. This gives us an opportunity to make improvements in our process, so that work takes less time. A nice thing about having Story Points be equal to something objective, like complexity or effort, rather than hours, is that this lets you show an increasing number of Story Points completed, in the same amount of time, across sprints.
This in turn lets you track improvements that you’ve made to your process, to make things more efficient.
Finally, during the two-week period, we have several meetings to discuss how tickets in the sprint are going. Because we are discussing a very small number of tickets, these meetings are often very short or can be canceled altogether. We track progress on a public board that shows exactly where each ticket is, which gives visibility to everyone who asks us for work, and reduces the need to meet even further.
Jira lets you set these boards up easily and drag things across as they’re completed, as do other ticketing systems, like Trello.
A common objection I’ve heard to this system, from marketers, is that Marketing work is somehow special in that it’s more iterative and therefore can’t be planned as easily. (For example, you aren’t building toward a giant, complex piece of software). So this sort of system shouldn’t work. But I’ve found that most of the practices developed for engineers also work for thoughtful marketers. If want to deliver good marketing, fast, you should want to build an assembly line for it. That’s essentially what this does for you.