Stories, Epics, Themes and Initiatives for Product Managers

It sounds like something out of a fairytale, doesn’t it? Stories, epics, themes, and initiatives are the building blocks of great agile Product Management. They’re especially useful when you’ve got an impossibly large task ahead of you, like slaying a dragon or launching an enormous and complicated digital product. (Yes, they’re absolutely the same thing.)

When you’ve got a mountain to climb, you need to break it down into manageable parts of the journey. It’s why Everest has base camps, and it’s how great digital products get built.

Today we’ll show you how work is broken down in agile, into stories, epics, themes and initiatives.

Agile in a Nutshell

Skip this part if agile product development is nothing new to you, as we’re going to go over a super brief overview of agile for any newcomers.

1. What is agile?

Agile is a methodology within product development that aims to keep teams lean and to allow for quick pivots and changes. There is no one way to do agile, as there are dozens of frameworks and methodologies within agile that product teams can pick and choose from according to their needs.

2. When did agile come about?

Agile software development was born in 2001, when 17 software developers got together at a ski resort in the Wasatch mountains of Utah, and wrote the Agile Manifesto. Since then it has taken off in popularity, replacing the traditional waterfall method.

3. Who uses agile?

You’d be hard-pressed to find a modern development team that doesn’t use agile. It has become the defacto methodology across the world. If you want to be a product manager nowadays, you have to be comfortable with agile!

4. Why use agile processes?

Agile is well loved because it is easily adaptable. In linear product development, any massive changes in the industry can cause enormous upheaval, and pivoting can cause a huge loss of time and resources. Agile’s goal is to be flexible, and allow for these pivots more easily. Agile is also more customer-focused, as the teams build from the point of view of the user, not what c-suite wants. It’s also a more people-focused approach to working, as teams are self-organizing.

5. How can I learn more about agile?

To learn more about agile, check out our guide, What Is Agile Development and Why Is Everyone Talking About It?

For a longer read, you’ll want to check out The Product Book, which tells you all you need to know about becoming a great product manager in an agile setting.

Or why not go ahead and get certified as a product manager? Getting taught about agile by professionals who build digital products loved by millions every day is the best education in agile that you could ask for!

Organizing Work Through Agile: Stories, Epics, Themes, and Initiatives

Now that that’s out of the way let’s dive deeper into what the components of agile project planning are.

Note that not every single product developed in agile is broken down into stories, epics, themes, and initiatives. Other teams may prefer to use Scrum or Kanban. Some companies will use a variety of frameworks across different teams, depending on how those teams prefer to work and the size of their projects.

For now, let’s focus on stories, epics, themes, and initiatives:

Stories

Starting from the bottom and working our way up, stories are the smallest component of the framework. They may also be known to you as tasks. They’re small chunks of work that need to be done, such as a button being added to a landing page, a small feature being added to an onboarding process etc.

They differ from a typical to-do list, because they’re written from the point of view of the user. This keeps the teams working on them user-focused, and allows for more creative thinking.

Check out our full guide on agile user stories for a more detailed deep-dive.

Each story has its own timeframe for completion, but developers should be able to handle multiple stories in a month. If a story takes too long to complete, it can be split up into smaller stories until it’s a manageable task.

Epics

Epics are collections of stories that are working towards a particular goal. For your first MVP of a particular feature, an epic might be ‘September Launch’, and all the stories under that epic are what needs to be done before launch.

By breaking down the body of work in this way, it makes it more manageable to track and distribute the work within the development process.

While many stories may be completed every week, an epic will usually span anywhere from a month to a quarter.

Initiatives

While epics span a quarter, initiatives are the drivers of those epics and therefore take much longer to complete. You may have many epics running simultaneously under an initiative, or if you have fewer teams, you may have to run epics concurrently. You can expect an initiative to take up to a year to be completed.

Themes

Themes are the largest of the four, as they track the high level goals of your organization. For example, a theme at Spotify might be ‘providing a home for artist’s music’ as well as ‘becoming the leading streaming platform for listeners.’ These are very high level goals, which look almost impossible if you just look at them without breaking them down into their component parts.

You might also be interested in: Product Management at Spotify with Former VP of Product

Management will work with product leadership (mostly the Director of Product Management / Heads of Product at this state) to figure out how to break these down into initiatives. Product leadership will then take this to the product teams to figure out how to break it down into epics, and finally the product teams will turn these epics into stories.

Does that sound too clean and easy? It rarely is! Product development gets messy, involves backtracking, scrapping ideas, bringing ideas back from the dead, having a competitor throw your plans out of the window, and having huge breakthroughs rocket you forwards.

That’s why agile is such a well-loved methodology, because it’s prepared to adapt alongside your teams, your industry, and the wider tech landscape.

How to Slay a Dragon

So let’s say you and your knights (developers, marketers, etc) have to slay a dragon. But because you’re knights, it’s not enough to slay the dragon, you also have to save the townsfolk, whose village has been ravaged by the beast.

So now you have two themes. Slay the dragon, save the townsfolk.

To slay the dragon, you’ll need to attack its lair. But in order to do that, you have to find out where that is. While you’re doing that, you’ll need to gather what you need; a good sword and some strong, fire-proof armor. Suddenly the task doesn’t look so impossible.

While you’re off doing that, the rest of your knights need to save the townsfolk in the ruined village. The best way to do that is to fortify the town, which you may do by building walls, and then supplying them with blankets and food to get through the winter.

And there you have it. Two impossible tasks broken down into manageable pieces.

Now, no one expects everything to go to plan. A few developers are probably going to get eaten, a few office chairs might burn down (are my metaphors crossing over?) but agile is prepared for that.

Why Are Agile Methodologies Important?

Perhaps a better question is, are agile methodologies important? Considering you’ve just read nearly a whole article about them, then supposedly they are.

But if you prefer to call your stories ‘tasks’, or you’ve already got a system that works, that’s fine! Agile isn’t a hard and fast rulebook. It’s a set of principles and a toolbox that you can dip into as and when you need it.

Building great digital products is about so much more than the lingo and the vocabulary. It’s nice to know what everything means, so that when you encounter a team who uses these frameworks, you can slip right into working alongside them.

The product management role is varied, and having as many tools in your box as possible will keep you nimble, adaptable, and employable!