Bring structure to your agile project with epics, stories, and more

No matter what industry or field of work you find yourself in, if you have ever managed or been part of a relatively large project, then you have probably, at some point, found yourself needing some structure.

There are many ways to do so, and a common one is to find a project management methodology you can adhere to. A popular option in the software industry is Agile. You may have also heard names such as Scrum or Kanban, but these are all, in essence, also Agile methods.

Agile is great for its flexibility, but this can sometimes mean that companies and project managers find themselves applying other layers of structure to their project management practices to stay better organized.

Before we take a deeper look at one of these structure layers, however, let’s go over the basics and take a quick look at what it means to be Agile.

What is Agile?

The Agile Alliance describes Agile as simply "the ability to create and respond to change”. See, although it is often described as a framework, Agile is more of a frame of mind, nothing but an approach or a way of looking at a project.

However, just because it is “simply an approach”, it doesn’t mean that it isn’t useful. In fact, it could be said that it has had a revolutionary effect on the tech industry, with most industry giants following its principles.

Agile was devised precisely out of a desire to change the way in which software projects were being managed. Its creators thought that companies were too focused on planning and documenting their products, so much so that they were forgetting to think about their clients.

With that in mind, they came up with an “Agile manifesto”, that is, a short text describing how they thought software development should be approached. Namely, they set out the following four statements:

●??????Individuals and interactions over processes and tools

●??????Working software over comprehensive documentation

●??????Customer collaboration over contract negotiation

●??????Responding to change over following a plan

Since then, the Agile approach has been refined and has kept on growing. But, at its heart, it has remained as a relatively loose guideline for teams and companies to follow, allowing for as much flexibility as possible.

For this reason, other complementing frameworks and ideas have come up to help bring a bit more structure to these ideals, thereby helping organize work and better implement Agile principles.

A popular take on this is to bring structure to the list of to-dos that is often the heart of any software project. But, how does this help make work more effective? Let’s take a look!

Why should I categorize my to-dos?

At the heart of every project, is a long list of to-dos. The larger and more complex the project, the longer that list will be and, often, it can be overwhelming to figure out where to start and how to identify and prioritize all your pending tasks.

This is where adding some structure, in the form of categories, can be of great help. The system we’ll introduce in this article is extremely popular. In fact, it is used, at least in some form, by most agile companies in the industry.

What is more, it will not only help you prioritize tasks, but it will also help you break them down into smaller parts, hence helping you identify to-dos you might have otherwise missed.

How should I categorize my to-dos?

There are many ways in which you can group your project’s pending tasks, but a highly common approach within Agile products is to divide them into Themes, Initiatives, Epics, and User Stories (or simply Stories). This is the approach we’ll be looking at in this article.

We’ll take a look at these categories from the more general ones (Themes) to the most specific ones (Stories). As we mentioned, this approach helps you identify larger groups of to-dos you need to work on, and break them down all the way to the more granular Story level. By doing so, you’ll have a better idea of what’s ahead of you and how to approach it, you’ll be able to better organize your time, and you’ll do a better job at identifying all your pending tasks.

Themes

As mentioned above, themes are the most general of these categories. They are meant to represent goals at the level of the organization, and not just a specific project. In fact, ideally, every project in an organization should somehow address whatever that organization’s themes or goals are at a given moment.

Because they align with company goals, it is common for these to be revised annually, and, as a result, many Agile teams are not as diligent with marking tickets with themes as they are with other of the categories in this article.

Initiatives

Just like Themes, initiatives encompass goals that are meant to be met in the longer term. They’re not month-long quests, but quarter-long ones, sometimes even yearly ones.

Unlike themes, however, initiatives are tightly tied to a specific project, and not necessarily to organization-wide goals. An initiative may fall within a theme, but, as with the other categories covered in this article, initiatives don’t need to have a specific correlation with a theme. In fact, an initiative can even correspond to multiple themes.

Lastly, the main characteristic of initiatives is that they are collections of Epics. Of course, this doesn’t mean much if you don’t know what an Epic is, so let’s take a look at that.?

Epics

Although many Agile teams overlook themes and initiatives, almost all of them work with Epics and User Stories.

Epics can be described as collections of User Stories but, then again, that doesn’t mean much when we haven’t defined User Stories yet. We’ll get to Stories soon, but before we do, let’s take a deeper look at Epics.

To start with, Epics encompass amounts of work large enough to be divided into smaller parts, but also large enough to take longer than a sprint or iteration to complete. In general, Epics take between a month to a quarter to complete. Because of this, there are also fewer Epics than there are Stories.

Moreover, an Epic doesn’t necessarily need to belong to a single project. On the contrary, they are large enough that they may be undertaken by multiple teams or projects who share a common goal.

User Stories

User Stories are even smaller than Epics. In fact, they should be small enough to be completed in a single iteration. They represent simpler narratives than that of Epics.

It is also important to understand that Stories are called User Stories for a reason. They aren’t just a description of a software requirement. On the contrary, they are meant to be described from a user’s perspective.

If you go back to the Agile statements we described earlier on, you’ll see that customer satisfaction is at the core of this project management approach. That’s why it is so important for Stories to reflect a user’s perspective and explain how the work they entail will give value back to the customer.

In frameworks such as Scrum, Stories can be thought of as the building blocks of Sprints. Every new Sprint, User Stories are selected from a Product Backlog, they are assigned an estimation of the effort it will take to complete them, and are finally placed in the Sprint Backlog. The team will then work on those Stories only until the end of the Sprint.

Just as Epics belong to a single Initiative, Stories will always correspond to a given Epic. This hierarchical system is what allows teams to organize their work and have a clear idea of how close they are to meeting their project’s goals.

If you haven’t tried organizing your workload in this way, we suggest you give it a try! If you’re intimidated by so many categories, you can try using Epics and Stories alone on your first try, and incorporate Initiatives and Themes as you start getting used to working this way. If you try it, let us know how it goes!