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.
Deliverables
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.
Epics
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.
Hello Jim,
You’re always thinking and challenging and sharing, all of which are good things.
Have not tried your Deliverable idea so I am visualizing it and at least at first blush, I think that it could help but not necessarily so.
Sticking with what I know works, and works well, our team never adds a user story to a sprint that we do not believe we can accomplish within that sprint. If it goes up on the board and in estimation we realize there is more there than initially thought, we get out the scalpel and excise what cannot be done in the sprint, and add it to the backlog (or add it to the sprint, albeit as 2 (or more) distinct user stories. It certainly happens that we miss sometimes but we never plan to fail meeting the commitment.
While there can be many deliverables to satisfy a user story in your scenario, I would still treat them each as a separate user story, and write the specific tasks germane to each user story.
Hopefully others will weigh in as well.
Have a great weekend, Jim.
Mark
Mark,
Thanks for the thoughtful comment. I’d love to get some examples of your user stories. How do you choose the channels, touch points or formats for your user stories?
Can those tasks created as small user stories.
Rewrite as “As a website 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”.
Deliver this in a sprint and get feedback from users. Then clone this story for printed media, product page etc based on Moscow priority
This helps to be following inspect.adapt. Deliver
Venkata, I suppose you could add the delivery mechanism into the user story, but I prefer having a deliverable that is sub-ordinate to the user story. One, that’s the way users think, and second, it ensures consistency. If you have a bunch of user stories that include the delivery mechanism, I guarantee that some of them will get out of sync in terms of the core user task and the “so that” reason or benefit. That being said, I’m not dogmatic about this, and people should use what works for them. Thanks for the comment. Jim
Hi Jim,
This is a timely post and discussion, as it’s often true that those outside the core (Agile) team aren’t clear what they should expect at the end of an Iteration/Sprint:
– There are often multiple ways to implement/deliver a user story, and these options and tradeoffs should be discussed during planning (as a prelude to sizing, for teams that engage in user story sizing as part of their planning and commitment.) If you’re hearing that there’s a 1:1 correspondence between a user story and it’s implementation, that’s probably a rushed planning session and it would be good to remind the team that alternative approaches are welcome and encouraged.
– The output/deliverable from an iteration (or Sprint) is usually specified (before committing to a start an iteration) as the Sprint (or Iteration) Goal. When we have Daily Scrum (in the Scrum Framework) we’re acknowledging our work towards fulfilling our Sprint Goal (versus solely updating our last daily cycle.) At higher levels of planning, some Agile Frameworks (SAFe, for example) use a Program Increment (PI) Goal to capture the planned deliverable(s) for multiple Sprints. There are also team-centric goals, too.
– Marketers (and everyone else, too) would benefit from participating (and seeing maintained) higher-levels of planning (and delivery) in the form of release plans aligned with product/system vision. Those plans need to be aligned with Sprint/Iterations, too.
The healthiest practice of all is persistent participation of all key stakeholders (especially at Sprint Review) to ensure teams are delivering per product/system vision. Stakeholders (like Marketing) can also participate at Daily Scrum (passively) to ensure teams are operating per their commitment (and shared vision.)
Cheers,
Greg
Greg,
Thanks for your thoughtful response. In my experience, marketers and developers write very different user stories. Developer user stories tend to be at a finer level of detail, and there tend to be more of them. So even if there doesn’t have to be a 1:1 correspondence between a user story and it’s implementation, and alternative approaches should be encouraged, in practice, there often is a 1:1 correspondence for developers. Whereas, and again this is just my experience, there is almost never a 1:1 correspondence for marketers. Marketers, by the nature of their job, think immediately of channels or points of interaction. How can I re-use this content in different channels? What are all the different ways that a prospect or customer might seek to educate themselves or reach out to us? These are natural marketer questions, which lead to different deliverables.
I was not familiar with the SAFe framework; thanks for bringing it to my attention. There may be something useful for marketers in some of their concepts.
Jim
On a positive your article does make it clear that marketing backlogs differs from software development backlogs.
But your interpretation of epic, stories, and tasks are a bit off.
First, while many Scrum teams use the story framework for organizing their backlogs, Scrum doesn’t mandate its use. Stories are borrowed from XP (extreme programming).
There may be a multiple of ways to implement a story. There isn’t necessarily one obvious best way. If there was there wouldn’t be a need for Scrum.
What you’re calling deliverables are stories.
Your alternative definition of an epic, as something other than a story that spans multiple sprints, is commonly referred to as a theme.
But all of the above is quibbling over definitions. What’s important is that you find a framework for structuring and decomposing your backlog that is useful to you. Which it appears you have done.
Brad, thanks for the thoughtful comment. You’re right, stories did originate with XP, but almost all the Scrum teams that I’ve encountered use stories. And while I agree that there are multiple ways to satisfy a story in development, in my experience, development teams seldom implement those multiple ways, whereas marketing teams often implement the same story in multiple fashions. For example, they may deliver content in multiple ways: a white paper, a series of web pages, a webinar, etc. All of those may have the exact same user story. Which is why I felt the need for a fourth category which I called deliverables. And you’re right, what I’m calling an Epic are commonly called themes. Thanks again, Jim.