Skip to main content

A quick tour through agile marketing methodology

It is possible to use agile terminology to make it seem more mysterious than it needs to be… This is an attempt to clear that fog.

The building blocks of a project: The stories

Perhaps the single most important part of the agile methodology is the story. Stories are the building blocks for communicating the goals of the project, and as a basis for planning the development.

Each story describes a value that the project delivers, and provide a way of reviewing the goals of a project with other stakeholders, before content development or design work begins. Getting the stories right has huge potential to speed up and streamline the approval process later.

  • The story should usually use the template “As <role>, I want to <do something>, so I can <achieve value>.” This ensures the scope of work is documented in a way that reflects the value it is supposed to deliver.

For example, a brochure formulated as stories could be “As a sales person, I want to have a brochure, so I can either send it to my customer or print it as a leave-behind as a reminder of the sales pitch.” and “As a potential customer, I want to have a brochure, so I can refresh my memory about the product, and discuss the product with colleagues.

  • For planning purposes, the story should also be given complexity points, as the current estimation of the likely development effort. Complexity points make it possible to compare the relative complexity of different stories, so the full set of stories for a project can bem mixed and matched to make the best use of the available development resources.
    In theory this should not be a quantification of the time needed, but that is usually what it comes down to for practical reasons: these are numbers most people are familiar with, and that we need for initial planning anyway (see Tasks, below).

  • The final part of a full story are the acceptance criteria. These list the characteristics of the deliverable that the developers can use to know they have delivered what was agreed.

For example, for the brochure, the acceptance criteria might include

  • PDF format

  • Single-sided, for personal printing

  • High res version, for printing

  • Low res version for emailing

Special stories: Epics and Spikes

Though unlikely to arise in the context of the example used here of creating a brochure, working out the stories for more complex projects can come up against stories that are not easily written.


Epic are a way of capturing stories that involve new ideas that need further input before they can be formulated properly, or that aren’t needed in detail yet.

Rather than this becoming a gating item for the project as a whole, calling these “epics” makes it possible to recognise and document the need, but also to park them for re-evaluation and for formally breaking down into manageable chunks (stories).


Resolving the epics into stories can take effort aimed to answer questions or gather information. So that these are visible in the planning, but do not get confused with stories for implementing user stories, these are called spikes.


After the stories have been approved for development, they need to be broken down into manageable, doable, and trackable units of work. These are the Tasks

Typically there are several tasks per story. Each of these should have

  • A description of the work to be done, in either technical or business terms

  • An estimate of how much time the work will take

  • An owner

  • The acceptance criteria for the task – which will obviously be based on those for the story, but can often include other measures

  • A description of how the task will be verified, including who is responsible for the verification

For the brochure example, one task might be the content creation, for which the acceptance criteria could include

  • Consistent with the customer-facing presentation

  • Arranged in sections for the different members of the typical customer’s decision making unit

  • In a suitable format for easy commenting by the product management team

  • In a suitable format for easy transfer to the designers for layout.

Agile project planning: Scrums, Sprints and Standups

Scrum is the name given to the framework used for managing agile projects. This framework clarifies the roles within the project and the correct communication paths and points, as well as tracking the progress.


Scrum defines three roles:

  • The project owner, who is responsible for the quality of the final deliverable

  • The scrum master, who is responsible for getting the work done (in effect the project manager), and

  • The scrum team, who are the people doing the work – depending on the project, in a marketing context this will typically be the content creators, designers, videographers, editors, ...


There are also three important “lists”.

  • The project backlog is the list of the stories (and tasks) that have yet to be assigned to the the scrum team. All of the stories and spikes start off in the project backlog.

The remaining lists will be covered in more detail in the next section:

  • The sprint backlog is a list of what the team is currently working on.

  • The burndown shows where the team is, and where they should be, to be able to meet the goals set for the current iteration…

Doing the work: the sprints

A scrum consists of a series of short iterations – called sprints – each of which ends with the delivery of an increment of the project.

A sprint is time-limited (usually less than 30 days), typically tackles a bundle of related stories, and includes near immediate evaluation of the results.

Getting started: Sprint planning

Each sprint starts with a sprint planning meeting with the scrum master and the scrum team. The focus is on prioritizing and identifying the stories and tasks for the next sprint.

  1. By reviewing the project backlog, discussing the sprint objectives, and clarifying anything that is not clear.

  2. Then deciding how the tasks will be done (who does what, in what order, handing over to who).

The output of this second step is the sprint backlog. This makes the work to be done visible to the team, and helps them focus on the currently relevant tasks.

The burndown is how progress on the the goals set for a sprint are tracked. During the sprint planning, the expectation is set by the number of complexity points planned for the sprint backlog: the burndown. During the sprint – for example, during the standup meetings – complexity points that have been completed can be logged against this expectation.

The purpose of the burndown is to motivate the team by making progress visible as it happens.
It can also act as an early warning of potential problems, or an early indication that something is more complex than anticipated. 

By the way, this is why complexity points should not be equated with time or effort – even if this is tempting for initial planning.
For example, we might give the first draft content for our example brochure 8 complexity points (because it typically takes 8 hours). However, if it turns out that more research is necessary, then the content might only be half finished after 8 hours of work. For the burndown, this means 4 points, not 8.

Staying on track: Standups

During the sprint, there are standup meetings to make sure everyone is aligned, and everybody can keep working.

These meetings are quick (around 15 minutes), and periodic (once or twice a week): standup meetings should not impact productivity.

The scrum team should arrive to each standup with the answers to three questions:

  • What have you done since the last meeting?

  • What are you planning to do until the next meeting?

  • What obstacles are blocking your progress?

This is about marking progress and capturing issues. It is not about showing the work-in-progress, and if there any issues that need to be resolved, this should happen outside the standup meeting: As with the burndown, the idea is that any changes necessary can be flagged, and then dealt with in a planned, proactive way.

Evaluating the results: Sprint reviews

The sprint review held at the end of a sprint, for the scrum team to present their current status of development. This provides opportunities

  • For the team members to re-align as necessary (for example, if the content creator spots an artifact in the layout that could make the content harder to understand).

  • For the project owner to evaluate the work done to date, and react to it, to guide further development.

Evaluating the process: Retrospectives

This is a chance to make improvements in the way of working, by having the team examine what succeeded and what could be improved. The retrospective is key part of the agile philosophy of “inspecting and adapting” in the pursuit of “continuous improvement”. Taking a step back at the end of each sprint provides an opportunity take corrective action before any process problems get too big to handle. The goal should be to identify one or two high-priority, actionable items the team wants to work on in the next iteration.

And repeat

Sprints should be done consecutively, without intermediate gaps. Normally this means that at the end of each sprint there is a single event for the whole team which covers the review, the retrospective, and the planning for the next sprint.