Learn how to improve the effectiveness of sprint planning to elevate the success of your overall agile marketing process and every sprint you run, with actionable tips, secrets and lessons learned from 4 years of agile marketing.
In a 2016 report from Work Front, 30% of marketers were currently using agile marketing methodology to manage their work processes.
As a big fan and active practitioner of agile marketing for the past four years, that statistic is very exciting news to me. Although I can’t say I’m particularly surprised, as someone who understands the huge value and impact agile can have for a marketing organization.
With agile marketing adoption numbers rising fast, more and more people are brand new to agile or just getting started. In a 2016 report from Wrike, 33% of marketers currently using agile had only started within the past six months, and another 22% were just in the first stages of getting started.
Jumping back to the WorkFront report, it also found that 70% of marketers cite lack of knowledge or expertise as the greatest barrier standing in their way of implementation.
This confirms a fact that I personally see all the time, which is that despite the fact that agile marketing adoption seems to be really heating up, a huge knowledge gap exists in the marketing community around what agile marketing really is exactly, how it works, and how to go about actually putting it into practice.
With four years worth of agile marketing lessons (many of which learned the hard way) to share, this will be first in a series of posts over-time in which I’d like to pass on some knowledge we’ve acquired along our own agile journey, that I would have probably killed to have known from the start.
Quick Refresher: “Nutshell” Definition of Agile Marketing
Adapted from agile software development, at its core, agile marketing is a tactical marketing approach in which teams identify and focus their collective efforts on high-value projects, complete those projects cooperatively, measure their impact, and then continuously and incrementally improve the results over time. (Via Work Front)
As established by the Agile Marketing Manifesto in June 2012, agile marketing is based on a unique set of core values that contrast with that of most traditional marketing approaches.
7 Core Values of the Agile Marketing Manifesto:
- Validating learning over opinions and conventions
- Customer focused collaboration over silos and hierarchy
- Adaptive and iterative campaigns over Big-Bang campaigns
- The process of customer discovery over static prediction
- Flexible vs. rigid planning
- Responding to change over following a plan
- Many small experiments over a few large bets
Note that #6 and #7 above are about planning, which steers us head on into the main topic of this post…
Agile Sprints and Sprint Planning
Agile processes commonly operate in “sprints,” which are short, repeatable work cycles that typically range between 2-6 weeks in which agile teams commit to focusing on completing a pre-determined list of high priority projects. Prior to beginning a sprint, teams typically go through a sprint planning process, which involves determining what projects and tasks will be added to a sprint, assessing priorities, estimating the amount of time and effort they will take to get done, and sometimes who they should be assigned to.
In contrast to traditional Waterfall models which favor rigid, long-term planning, an agile approach is all about focusing on smaller, short-term, iterative, sprint plans.
For anyone looking to be successful implementing agile marketing at your organization, one big lesson I’ve learned over the past few years is that sprint planning is an area in which your effectiveness directly impacts the overall results of your sprint.
Below are a collection of tips that I’ve picked up on how to be more effective in your sprint planning, that can really make a difference.
9 Ways to Ensure Agile Marketing Success with Better Sprint Planning
1. Make sprint planning a priority
The more effective sprint planning, the more effective your agile marketing process. Don’t underestimate the importance of spending the time and effort to thoughtfully plan your sprints out ahead of time. While you should be careful not to make the planning process too time-consuming and complex that it becomes a major project in itself, you do want to make sure everyone on the team is spending the time to thoroughly and thoughtfully plan their sprints.
2. When planning projects and tasks: Small, granular pieces > big, vague blobs
Break larger projects and tasks into smaller, granular pieces. If your sprint plan is full of large, vague tasks with lots of estimated hours for each, it will be harder to accurately track progress during the sprint, and less precise, without a clear understanding of all the smaller tasks that need to get done as a part of a project, in what order, and by when. Here’s a good instance where a little more time and thought up front in the planning process can go a long way in the effectiveness of your sprints.
For example, say you have a big project to build a new lead nurturing program that is going to take up a lot of your time in a sprint.
Big, Vague Task Planning Example
(How NOT to plan your sprint)
Task | Est. HRS | Deadline |
Build New Lead Nurturing Program | 18 | 1/12 (Last day of sprint) |
What the Burn-down Chart Looks Like:
(Useless…)
If you create one big task called “Build New Lead Nurturing Program” for 18 hours that spans the entire sprint, you don’t really have visibility into all the moving parts, and you won’t be able to see how you are tracking on progress until the last day of the sprint when you mark it as done. Instead, a more effective approach is breaking down the project down into a bunch of smaller bite-sized tasks, each with deadlines and estimated hours.
Granular, Broken-down Task Example
(The right way)
Epic Name: BOFU Lead Nurturing Program for Product XYZ
Task | Est. HRS | Deadline |
Customer research: interviews and survey | 6 | 1/3 |
Conduct Content Audit | 2 | 1/4 |
Create Content Plan and Order | 3 | 1/4 |
Build Marketo Lead Nurturing Program | 3 | 1/5 |
Write Email Copy for First 5 Assets | 4 | 1/8 |
Create Emails in Marketo for First 5 Assets | 4 | 1/9 |
Create New Landing Pages for 3 Assets | 2 | 1/10 |
Setup Campaign Tracking in MKTO & SFDC | 1 | 1/10 |
Testing and QA | 3 | 1/11 |
Total | 28 | 1/12 |
Notice that when the project is broken down into smaller, granular tasks and have a much clearer view of the moving pieces, it turns out the estimated time budgeted for the project is +10 hours longer than the original estimate. We now know that if you had planned your sprint using the first approach, you would be at very high risk of missing your deadline, or missing a deadline for another project to re-allocate more time for this one.
What the Burn-down Chart Looks Like:
Hey there, good looking…
4. Plan ahead for the unpredictable
We work in a very fast-paced business, so no matter how good of a job we do with planning, inevitably there are always going to be some high priority inbound tasks that pop up here and there that we still need to jump on and execute that we couldn’t have planned for or seen coming ahead of time. Even if your business is not as fast-paced, it’s bound to happen.
An effective way we’ve handled this at SmartBear is using what we internally refer to as “flex time” and “flex tasks.” The idea is, by setting some time aside while planning your sprint reserved for any incoming tasks that might suddenly pop-up during the sprint, you will always have the bandwidth to pounce on them when they do, without dropping other priorities and sacrificing other deadlines we’ve already committed to. We have baked “flex time” and “flex tasks” into our regular sprint planning process, and also report on it at the end of the sprint to track how many flex hours and tasks came in, and how many we were able to get through.
If the flex tasks don’t end up coming, we can then dedicate our flex time to optimization, experimentation, ideation or getting ahead on some tasks from the backlog.
5. Account for “non-execution” time
It’s amazing how much time we spend at work not actually working or executing tasks. Time spent in meetings, interviewing candidates, traveling, OOO at doctor’s appointments, PTO; all examples of items that can really add up and take away from the available time you have for actually getting work done. This is important to take into consideration when sprint planning in order to understand how many hours we actually have available to execute the tasks so we don’t over-commit.
To plan for this, try making a ballpark guesstimate (doesn’t need to be super exact) of how much time you might be tied up with other “non-execution” activities during business hours in your next sprint.
You might be surprised how much less available time you end up with to GSD once you’ve deducted your “non-execution hours” or “personal problems” as we call them internally at SmartBear.
6. Benchmark your bandwidth
Understand the average amount of execution hours each team member can get through in a sprint.
Taking planned “flex time” and “non-execution time” into consideration, when you run your reports at the end of each sprint, you will get a much clearer view of how much actual execution time each person was able to get through during the time frame of a sprint.
On my team for example, we saw that in a one-hundred business hour, two-week sprint, on average each person is able to get through around 50-60 hours of execution time for tasks they committed to at the beginning of the sprint.
With this information, we know that whenever someone has more than 60 or so hours of execution time planned in the sprint, that’s probably more than they will be able to get through. We can easily identify this, and make adjustments accordingly to make sure we are not committing to more tasks than our bandwidth will allow.
7. Review and commit before every sprint
Review planned tasks and give each member of your team the opportunity to commit before the sprint.
Once your team has planned all their tasks and projects for an upcoming sprint, its important to make sure that each team member has a solid understanding of everything that they to accomplish during the sprint, and also for managers, and other stakeholders involved to have visibility and ability to give input as well.
At this juncture, you have an opportunity to have discussions and make any changes that might be necessary before the sprint is locked in, such as adjusting priorities, deadlines, hour estimations for tasks, and again making sure each team member doesn’t have to much (or too little) on their plate. For managers, now is your chance to see where your employees’ time is going, and to make sure team members are focusing on the needle-movers.
Hour estimates for tasks is one example that can cause problems if you don’t take the time to review and ensure accuracy. If someone under-estimates the time required to complete a task (such as in the example in #2 above), deadlines can be put at risk. Sprint planning poker is a common team activity that was invented as a way to help police time and effort estimates, which we’ve experimented with in the past.
Once you’ve finished reviewing, I’m a firm believer in adding a formalized step to the process to give each team member an opportunity to share whether they are comfortable committing to everything in their sprint or not. Speak now or forever hold your peace. Doing this acts as a final filter to weed out any remaining potential risks of over-committing. When you over-commit, everybody loses. Since everyone is given a fair opportunity to speak up, they know that they will be held accountable for everything they do commit to.
Prior to perfecting our current agile process, my team was only completing around 55-65% of the tasks being requested of them within a given sprint. We had a bit of a unique situation due to organizational structure to support 15+ different products across 5 core business units, but basically people were getting assigned tasks left and right from all different directions and it would have been impossible to get through them all in a two-week sprint, let alone on time.
After adding a commit session to our process, we were able to see that many of the requests people were getting were complete time-wasters. Many were a low priority, or reproducing work that’s already been done, and sometimes even not the responsibility of the person it was assigned to. And some of these were making it onto people’s to-do lists before much more important priorities. And even after weeding all of these out, people’s plates were still overloaded. I once had a new hire who in their first sprint commit session had over 180 hours of tasks requested!! As I mentioned earlier in the benchmark your bandwidth section, it would typically take an average of three full sprints to get through that many execution hours. Let alone in their second week!
With our current process, now our team delivers on average 95% of the tasks they commit to working on at the beginning of the sprint.
This is also important because it places a much higher currency on every task that gets into the sprint, as those assigning the task and managers can have a 95% confidence that whatever gets committed to will be completed on time during the sprint.
8. Use your backlog, and keep it clean and up-to-date
Your sprint backlog is a running to do list of tasks and projects that you are not assigned to a current sprint. When a sprint is in progress, typically many of the new tasks and requests that come in should be temporarily added to the backlog, and later added to a future sprint as to not distract someone for executing the list of priority projects they have already committed to completing during the current sprint.
If you are using your backlog as a huge dumping ground where tasks and projects go to rot, you are missing out on the purpose and value of the backlog. If something is never going to get done, it shouldn’t still be in your backlog.
You should be reviewing and pulling tasks from your backlog while sprint planning, and also during existing sprints when you have some unexpected free time.
9. Don’t forget the long-term. Think ahead and plan multiple sprints in advance.
Just because sprints are designed to focus on short-term execution, does not mean you should be near-sighted from a planning standpoint. Below are three examples related to this.
- Have a system in place to balance long-term planning with short-term sprints. It can be easy to not be seeing the forest through the trees and lose sight of the big picture, and long-term, when you are always heads down executing a sprint or planning in two-week increments. Be sure to bake in a recurring long-term planning process to run in tandem with the sprint process, and then you’ll have the best of both worlds.
- Plan ahead for projects that span multiple sprints. When you have a big project that involves multiple people, and spans multiple sprints (often referred to as an “epic”), like a product launch or big webinar for example, you usually are much better off planning the entire project out in one sitting ahead of time, as opposed to planning and assigning pieces of it before the start of every sprint. This will give you a much better view of the moving parts, help make sure you are not forgetting any steps or tasks, and help keep everyone on track so there is less risk of missing a deadline.
- Spread your planning out instead of waiting until the last minute. If you want to do a thorough job with sprint planning, but start finding you spending hours on hours planning the week just before a new sprint starts, you can make it much more manageable for yourself if you break it up and start doing just a little planning for a few minutes every day or every other day.
What sprint planning tips and best practices do you recommend for agile marketing? Please leave a comment if you have some good ones, would love to hear them!
Be sure to subscribe to Customer Journey Marketer Blog if you haven’t already so you don’t miss my next post in this series on how to implement an effective agile marketing process at your organization.
If you’re interested in learning more about our experiences with agile marketing at SmartBear, check out the last ten slides of this SlideShare below from a presentation I gave recently at Boston Agile Marketing Group.
Jim Ewel says
Gary, great stuff! I’d love to be able to interview you for my blog, http://www.agilemarketing.net. Interested?
Gary DeAsi says
Hey Jim, thanks a lot! And cool blog! Just subscribed.
Sure, I would be happy to chat. Please email me at [email protected] to discuss.
-Gary
Justin Norris says
This was a very thorough and useful post Gary. I have heard much talk about agile marketing but have not seen a process for it articulated with as much clarity and detail as this before. Nice work. This is a solid model for others to follow.
You’ve alluded to it in terms of having longer-term planning sessions, but I’d be curious for more detail (perhaps a follow up post) on how you and your team incorporate strategic planning into this mix.
I.e., if your sprint planning is the “how” or execution component, what process do you follow for assessing *what* to devote effort to and to prioritize in a marketing roadmap of “features”.
I find this part is hard to get right – people can be executing with precision but not necessarily executing against the right things that will bring the most benefit to the business.
Gary DeAsi says
Hey Justin – Thanks so much, excited you found the post helpful. Apologies for the long delayed response – I was actually traveling in Europe for the past few months and just saw your comment now.
You bring up a terrific point, and I agree that would make a great topic for a follow up post.
In short, IMO, you need to an ongoing parallel process in place for understanding and evaluating A) what is working and what isn’t (metrics) B) Goals, objectives and priorities and C) The go-forward strategy for your marketing roadmap.
In the past, I have typically run this long-term strategic planning in tandem with agile using the outcomes to inform what gets prioritized for execution. Thus, the agile process becomes the means to execute the plan, stay on course, and bake in flexibility to pivot as modifications to the plan and priorities shift.
Thanks again for the note, Justin. Definitely an important point.
Gary
Dave Vranicar says
This is an excellent post, Gary.
I’ve been working with a few clients to implement agile marketing for a little more than a year. It’s a great marketing approach that I find especially well suited for small marketing teams in fast-moving industries such as tech. It will probably also work for much bigger companies. But bigger companies have more process and culture to overcome.
At one of my clients, we ran into a number of the challenges you cited here. Your tips for overcoming them are helpful and appear to be spot on. I especially like the idea of breaking up big tasks into smaller ones. I also agree with your point about the need to monitor your team’s available bandwidth. Until you know your bandwidth, you’re likely to overcommit to sprints.
With the growth of interest in account-based marketing at B2B companies, I believe the next stage of evolution will be to introduce agile methods for use by agile revenue teams. Agile revenue teams will consist of salespeople, marketers, and possibly participants from other disciplines such as Customer Success.
Gary DeAsi says
Thanks for the note, Dave! Glad you found the article helpful.
Yes, implementing at much larger companies is something I’ve had come up when talking with folks in the past, and certainly can be a greater challenge. But just think, at one point all of those companies were still using waterfall development – but of course, eventually the tide turned for the large majority.
I think your agile revenue teams thought is really interesting. I would also suggest potentially adding product team members to your list as well. For something like a major product release for example, you could then have the product manager, marketing team, sales, and customer success all tightly aligned with all of their respected smaller pieces surrounding a single initiative.
Thanks again, Dave!
Gary