I’ve been thinking a lot about the relationship between Epics, User Stories and Tasks in the practice of Scrum and particularly how those relationships are different for marketers compared to developers. Those differences have led me to conclude that marketers who practice Scrum need a fourth construct, which I call a deliverable.
Epics, User Stories and Tasks
I’ve written about user stories here, here, here and here. Agile Marketers write user stories to make sure they understand what the buyer is trying to accomplish and why. Traditional Scrum methodology defines an Epic as any User Story that spans more than one Sprint, although as I’ll show below, Agile Marketers tend to use Epics in a different fashion. And tasks are the single lowest unit of work, with each task being estimated, assigned to someone, and moved through the process of a Kanban board from doing to done.
However, in my experience, Agile Marketers need a fourth construct, which I call a deliverable.
Why do marketers need a fourth category? Because developers satisfy a User Story in a fundamental different fashion than do marketers. Let me explain.
When developers are presented with a User Story, they realize that there are multiple ways to satisfy that User Story, but they implement only one of those ways. In general, good software design dictates that there be one clear way to do something, rather than several different ways to accomplish the same task. There are exceptions, but they’re not common.
Marketers, however, almost always execute on multiple ways to satisfy a single User Story. For example, let’s take a User Story like the following:
As an Evaluation lead, I want to understand quickly what differentiates you from your competitors so that I can decide whether to include you in the final list of vendors under consideration
A marketer could satisfy this user story on the front page of their web site or on a product page; they could satisfy it through a webinar; they could satisfy it in printed materials like white papers or cut sheets. They could also provide their sales force with presentations or talking points that satisfy this User Story. They may provide their channels with customized materials which also satisfy this User Story. Marketers almost always create different Deliverables to satisfy the same User Story, depending on channel and touchpoint.
For this reason, I suggest that Agile marketers think of a hierarchy: User Stories consist of multiple Deliverables, which consist of multiple tasks. Tasks are the units of work and estimation. A particular Deliverable should be completed in a single Sprint. User Stories often span multiple Sprints, and in some cases, they may never be “completed”. Marketing teams may come up with almost an infinite number of Deliverables that satisfy what users are looking for.
Although an Epic is defined as any User Story that spans more than one Sprint, in my experience Agile Marketers tend to use Epics in a much different fashion. The two most common uses are:
- Epic as initiative – many companies have quarterly, semi-yearly or yearly business initiatives. These are high level strategic goals or activities designed to reach certain goals. Some teams group their user stories and their deliverables under these initiatives.
- Epic as core marketing function or group – some teams will group their user stories and deliverables by core marketing functions. For example: lead generation, sales enablement, marcom, etc.
Implications for Tools
If you are going to use the category of Deliverable, and have a hierarchical relationship between your Epics, User Stories, Deliverables and Tasks, you need a tool that supports hierarchies and parent-child relationships. Many basic Kanban board tools, like Trello, don’t support hierarchies out of the box. There is a Chrome add-in for Trello, called Ultimello, that supports parent-child relationships, but it only works for the Chrome Browser. If you use IE or Firefox, you’re out of luck. Other tools, like Jira or Asana, do support hierarchies. Consider this when you’re selecting your tool.
Let me know if the introduction of a fourth construct, Deliverables, simplifies how you think about User Stories and tasks. I’d love to hear your feedback.