Adventures in Agile Marketing: Estimating Story Points
A lot has happened since my last Agile marketing post about revamping the editorial calendar. For one thing, I still use my editorial calendar, but it’s become a brainstorm repository instead of an organizational tool. Also, I now have another person on my marketing team which has been a tremendous help and immense relief as we’ve been really busy with conferences, white papers, blog posts, and started the arduous process of updating the website in addition to creating physical marketing collateral.
It is a lot to manage for a two-person team so I started to look for ways to become more effective with time and bandwidth. I have a backlog and a Kanban board to visualize the work, a good first step. Now, how do I discuss what’s involved with my team and stakeholders? Specifically…
- How do I have meaningful conversations about scope with my team?
- How do I show productivity in a way that’s meaningful to stakeholders*?
- How do I use data to discuss and prioritize with stakeholders?
I know story points are used in development to estimate work. Can it work for marketing?
Development teams assign user story points to describe their relative size to one another. This is different from how I estimated work in the past, which was time-based. For example, writing a blog post took two hours while a white paper may take six.
But there are problems with the Hours method. In marketing, estimating work in hours meant being a slave to answering a stream of continuous questions. Are we writing from scratch? How many sections? Is research involved? Any interviews? It was constant, exhausting re-estimating.
Story points are a measure of scope. A white paper has more scope than a blog post; a blog post has more scope than a tweet*. They are evaluated and estimated in relation to each other. Regardless of how many sections or research needed, a white paper will always have more scope than a blog post; a blog post will always be more scope than a tweet. In this way, the scale is fixed. Now, team members can discuss and debate just how much scope something is. Is it twice as big or three times as big? Using story points, if a blog post is a 3, is a white paper an 8 or a 21?
An advantage of using this strategy is that it frees managers to spend time on helping the team or setting strategy.
Why Use Story Points For Marketing?
In an Agile team, product owners use story points to discuss scope of the work in upcoming sprints with stakeholders. What happens if stakeholders have something they want to add to the product backlog and it’s an 8-point story. What should the product owner do?
There are a few options that don’t involve time manipulation. If stakeholders really want the feature added, the product owner and ScrumMaster can request more team members to help the heavier workload. The other option would be to cut planned scope to make room for new work. If planned scope was estimated ahead of time, the product owner has an idea of how much needs to be cut.
Story point estimation can be a valuable tool, especially for teams with limited time and manpower (every marketing team ever). Without getting in the weeds of estimating using time, there is still a concrete, data-driven way to evaluate scope, measure productivity, and negotiate with stakeholders.
First Estimation Exercise
We ran our first estimation exercise a couple of weeks ago. We’re a very young team, in terms of working together, and the exercise gave us time to discuss our personal experiences with the items at hand. After we finished grouping the items in t-shirt sizes and allocated a point system, we were able to create our own marketing story point cheat sheet.
If we add more members to the team, we will need to re-do the bucketing exercise to create a new scale.
It has been two weeks since we began this agile marketing experiment and I’ve noted how many points we’ve accomplished every week. I need a few more data points to calculate an average velocity. I’m really excited because I think story points will help me plan work better and improve my relationship with stakeholders. I can use our average velocity to have reason-fueled discussions with stakeholders on what work should be completed and how much of it will be done in a given time frame.
More on Agile marketing here:
It was 1984. Explorer, architect, and author Saul Wurman began to notice a convergence of multiple disciplines, and in an interview with 
When was the last time that your editorial calendar got a makeover? As a marketer before Agile (BA), my editorial calendar was pretty standard: title, info, status, and dates. It was the piece of data that, I now know, was a very waterfall way of creating content. Before Agile, I never realized how much risk was involved with every blog post that went out the door.
Imagine you were tasked with building a transportation vehicle for two individuals. What would be your first step? If you dove head first into your list of features, you made the wrong move.