The Role of Epics in Agile Project Management

The Role of Epics in Agile Project Management

A complex project can derail in so many ways. The software team might hunker down and develop an innovative product, only to discover that it’s not what the user wants. At the other extreme, the team might set out to solve the client’s problem, only to realize mid-way that it doesn’t have the capacity to complete the project. And in any large organization, mis-management and waste of resources always poses a huge risk.

Getting it all right means meeting business objectives, aligning skills and resources, and solving user problems all at the same time. It means weaving these multiple tensions together, and coordinating various objectives within one initiative.

And this is no small challenge. To hone in on one area so often means completely ignoring another, and then everything veers off track. It almost requires a master puppeteer.

Or maybe just a master system. And agile has come up with one that delicately pulls this feat off.

Just how does the agile method work? It arranges several artifacts together into what almost looks like a three-dimensional game of Tetris. And one central artifact within this mix is an epic.

Wondering just how and where an epic fits into the agile puzzle? That’s what we’re going to break down in this post.

The Purpose & Challenge of Agile

The agile revolution back in the 90s fueled itself on a plenteous stream of frustrating and failed projects. The waterfall approach carefully planned everything at the start, and then the team went into a black box to see the plan through. Time and time again, they would emerge, after months of tireless and diligent work, with a product that the customer didn’t like and didn’t use.

Agile set out to change what it saw as a fundamentally flawed system by taking an outside-in approach to project planning. Rather than making hard and fast decisions at the start, and deciding for themselves what the end user needs or wants, the agile method allows a project to bend and flow, soliciting feedback from the end user continually. As the Agile Manifesto states, it seeks “openness to change over following a plan,” meaning that it pivots and adjusts based on the feedback it receives during the project from end users.

It achieves this outside-in orientation with “user stories,” which outlines a task from the perspective of the end user, first defining how the task serves a user’s need, then working backward to outline what the task must consist of.

On balance, this system improved things. The agile method yielded user-friendly software; products that solved user problems, and included innovative features the users enjoyed. Agile, then, isn’t just about increasing efficiency. Its revolutionary approach really makes end products more effective.

But it isn’t entirely perfect. With this outside-in approach, the organization caters to the whims and preferences of the client, which it can’t ever pin down or know entirely. Agile even goes so far as to “welcome changing requirements, even late in development,” as it states in its Manifesto.

The agile approach, in essence, means that the company loses control over significant things like scope and budget. A project that is slated to last three months may well extend into six, as requirements and client’s needs change. A change in the client’s request mid-way into a project might require architecture or skills that the company doesn’t possess. In short, agile, in some respects anyway, poses a huge business risk.

In order to be a going-concern, then, a business cannot entirely embrace this outside-in approach, to the exclusion of other perspectives. It needs a method that also keeps a keen eye on the bottom line, that considers business objectives; a system that takes an inside-out and an outside-in approach at the same time. Striking this balance means incorporating epics into the mix as well.

With this background, let’s break down just what an epic is, and the role it serves within an organization.

The Evolution & Role of Epics

Originally, “epics” were understood as one, giant user story, basically a big chunk of work that couldn’t be completed within one sprint. A development team, over sprint planning sessions and with games like planning poker, would decompose the epic into smaller stories that could be completed within a single sprint. Breaking these down collaboratively fostered the autonomous nature of the agile team.

And for some organizations, epics still function pretty much in the same way. Epics are almost like one of the higher tiers in a work break down structure, while the user stories represent the lower tiers.

As organizations increased in complexity, however, managing a project became like juggling hundreds of balls, of various sizes and weights. And the role of epics has also evolved to address this complexity.

As organizations increased in complexity, however, managing a project became like juggling hundreds of balls, of various sizes and weights. And the role of epics has also evolved to address this complexity.

Within this context, what some have come to call a scaled agile framework (SAF), epics represent higher tier, executive planning. A single epic provides the business justification for a broad amount of work. Rather than orienting around end-user needs, the epic uses business syntax to explain how the project serves the needs of the company. For example, an epic might have the objective to tap into 10% of the user base for a certain product or service. Or it might aim to increase overall sales by a certain percentage within a quarter.

Due to its distinct framing, an epic oftentimes has a backlog all of its own, separate from the backlog for user stories. The epic backlog represents the portfolio, or business position of the project.

Epics, then, keep a close eye on the business component of a project, and hedge against the risk of agile’s user-focused emphasis.

And epics and user stores aren’t the only tools in the agile mix. In order to keep a company churning, several more artifacts come into play. Let’s next look at this synchronous blend of artifacts and see how they work together to solve organizational problems and meet consumer and business needs, all at the same time.

The Agile Artifact Mix: Epics, Features, User Stories & Themes!

As mentioned, organizations must meet many various and sometimes conflicting demands. In addition to solving the users needs and addressing the financial needs of the company, it also faces the challenges of aligning resources and labor within a project, and of releasing products in a sequence that appeals to the client. Four agile artifacts; epics, features, themes, and user stories; serve to blend these complex perspectives.

Using an example, let’s see how each artifact functions in a coordinated effort to meet a medley of complex demands.

Take a social media management (SMM) software company, whose principle service is to enable an organization to coordinate, plan and schedule a social media marketing plan from its platform. In its bi-annual planning, the SMM company is considering several strategic objectives:

• The company’s business strategy is to double the number of clients who sign up for its top-tier package, so that they represent more than half of its overall clients.
• The product strategy is to improve its analytics features. It wants to offer more robust tools that make it competitive with other companies, and that suit the client’s needs.
• And its internal strategy is to better coordinate projects and skilled team members, and to decrease turnaround times by 20%.

Let’s go over how user stories, epics, features and themes meet these distinct objectives.

User Stories

User stories, as mentioned, take an outside-in approach to a project. Good user stories are the fruits of in-depth conversations with the customer. They have a solid grasp of his or her central frustrations and needs. The outside-in approach leads to better choices around what product to build. (A knowledgeable product owner is helpful in this respect).

In the example of the SMM company seeking to improve its analytics features, the product owner studies its clients closely. Some effective methods here include reading feedback, gathering surveys, and looking at competitor’s products and reviews. All of this research allows a company to glean an understanding of what the client really wants.

For example, if a large portion of the SMM’s company’ users run international social media campaigns, it would benefit from offering analysis capabilities that break data down by geographic region. While, if it has a user base that regularly meets together in person, the company would benefit from a functionality that allows users to download statistics and reports into pdfs that can easily be shared with the team.

Epics

When evaluating a project or body of work, an epic carefully evaluates both the capabilities and the needs of the company. It looks at the capacity of the organization, considering the skill set of its workforce, and any skill gaps within the team. It also considers regulations and compliance laws surrounding the project. It carefully studies the company’s overall business plan and considers how the project could help it meet both short and long term objectives.

In essence, the function of the epic is to align the customer needs with the company’s needs and capacity. It rules out misalignments, such as a project that would require a skill set the team doesn’t have.

Take the SMM company, which has a business objective to double its number of top-tier clients, at the same time that it wants to augment its analytics features. One clear way to meet both these objectives is to provide its newer, more robust analytics tools exclusively to its highest tier clients. The free and lower-paying clients would have access to a more basic set of analytics features. This would ideally incentivize people to sign up for the higher tier plans.

And while on paper this sounds like the straightforward solution, this of course may not be the case in reality. That is to say, marrying multiple objectives is a delicate balance, and one which requires carefully studying consumer behavior. Customers might be upset by this arrangement, feeling like they’re being pushed into paying for the higher plan, in which case this strategy could backfire. Or if the competition on balance offers the same statistical functionality to every tier, then the effort might fall flat as well.

As you can see, it takes creativity and brainstorming to come up with a strategy that meets both customer and consumer objectives.

Themes

Themes are a collection of related tasks in the backlog. When released together, they create a desirable package for the end user. It’s a user-focused collection of work.

In the example of the SMM company, a product owner might groom the backlog so that a set of new analytics features are completed within the same period of time. The release of these new functionalities serves as a powerful marketing tool; it entices new clients to the product.

Features

Features are another method for sorting work which principally considers the coordinated work efforts between teams. Oftentimes large projects have hundreds of separate tasks in the backlog, each requiring a distinct set of skills and resources. It takes some strategy to align all of these tasks in such a way that it prudently utilizes the company’s labor and resources.

For example, say a workforce has only a few individuals with a skill set that happens to be required in order to complete several packages of work. A feature would arrange these tasks sequentially, rather in parallel, in order to properly utilize these skilled individuals. Or if a task requires scarce resources, the feature considers this as well when arranging work.

In the event of the SMM company whose objective is to decrease turnaround times, creating features would entail looking closely at the skill set of the workforce, and coordinating employees with the skills required for each task. Strategies such as resource leveling, resource smoothing, the critical chain method, fast tracking and crashing would all come into play here.

The Symphonic Blend

Taken together, epics, features, themes and user stories create the balance required to meet various demands and successfully execute a project. It creates the right distribution of outside-in and inside-out focus. Epics principally focus on the business outcomes of a project, while features define the labor and resource coordination, and the user stories focus on the end user goals.

While each of these artifacts function in parallel with one another, they don’t necessarily feed into one another. Some questions naturally arise then, such as “How do you map them out?” and “Where do they overlap?”

Tools for Writing Epics, Features & Stories

Managing a complex organization is a bit like playing a game of chess. Arranging work to solve a user problem, for example, may well create vulnerabilities in other areas. Maybe it poses a business risk or wastes resources. So there’s a need to constantly evaluate many complex variables and implications all at the same time.

Where does the process of arranging work begin, then? With the end user, the company’s goals, or somewhere in between? The answer, really, is that it can begin anywhere.

Maybe it begins with a user story. Although it’s common to begin a user story in a “what” format, explaining the solution it provides, re-framing it into a “why” format opens the door to more versatility. For example, maybe the initial user story is to add a drop-down menu to a webpage. Re-framed into the “why” format, this story really becomes about improving the website’s usability. And this opens the door to a variety of solutions, creating a greater possibility to align the work to a company’s financial goals and its capacity.

Or a project can start with an epic, a high-tier executive goal. Maybe it’s to develop a product that allows the company to tap into a new market. From this point, it can move into writing user stories, which entails researching the market to identify suitable products.

Mapping out these epics, features, themes and user stories can be a complicated process, and fortunately agile has a few tools to help create a seamless web between these various artifacts. Let’s look at a few.

A Venn Diagram to Weave Epics With User Stories

Everybody’s seen a venn diagram before, where the overlapping circles indicate a logical correlation between two related topics or themes. With agile, a venn diagram can serve to identify those places where the outside-in and the inside-out perspectives overlap.

In this instance, one circle represents the business goals (epics), and the other represents the user goals (user stories). And where these overlap outlines the work that is chosen to include in the project. Features would consider the most strategic method for tackling the problem. And themes, finally, would arrange work to be released in related batches.

Agile Roadmaps

An agile roadmaps strategizes using an outside-in approach, and so it provides a template for epics. The roadmap looks at a company according to its current state (the benchmark) and a desired future state. Then it outlines each of the phases the company must go through in order to reach the future state.

For example, a company’s current state might be 5% of the market share for a service, and its desired future state is to double this and earn 10% of the market share. Its primary means to achieve this is by improving both its services and marketing. The phases for this roadmap, then, would outline a specific milestone related to either marketing or services. And a shift into a new phase means that a milestone has been met.

The roadmap serves to outline a broad amount of work. From there, it’s possible to consider a variety of possibilities for solving user stories, and then creating features to coordinate work.

User Story Mapping

User story mapping is a method of creating a collection of user stories, ideally at a user story session where a group of stakeholders come together to brainstorm and contribute.

A typical user story format goes something like, “As a [type of user], I want to [action] so that [benefit].” or “As “who,” I want “what,” so that “why””.

Here is an example: “As a busy executive, I want to improve my email functionality so that I can reduce the time it takes me to empty my inbox to thirty minutes a day.”

When a collection of user stories have been gathered, they are arranged by priority. The features form the backbone of these stories, which then feed into an epic.

Impact Map

An impact map helps to clearly outline the set of deliverables that stem from a stated objective. While at one end it outlines the “what,” of a project, the right side identifies the “why.” This simple strategy creates a through-line from the epic to the user story, and helps to keep daily work aligned with the overall objective.

These are just a few tools that have proven useful in weaving together large and complicated batches of work. Generally speaking, user stories include smaller pieces of work that can be included within one sprint. This work is captured within an epic, which encompasses an overall theme or business objective.

A large organization has multiple layers of concerns, and so oftentimes epics, features and stories might each have its own backlog.

It’s a bit of a trick to combine this work together, and so oftentimes multiple tools and brainstorming sessions are necessary to arrange everything sensibly. The work can start from a business objective and then develop into solving a user problem, or vice versa. As with any agile project, retrospectives serve to evaluate progress and create updates to the backlog, if necessary.