One of the questions I get asked the most is “What do we mean by feature or user story, and what the hell is an Epic???” If you or anyone you work with has had to deal with detangling the jargon around how Agile describes the outcomes or work being done by different levels in an organization, this is the article for you.
Before we jump into using the diagram to describe how each item is conceived and used, let’s take a brief detour to address the mess that has become of Epics. Before the arrival of SAFe, Epics in Scrum were originally user stories that were large, sometimes very large, certainly too large to fit into a sprint. The idea around them was for people to be able to quickly brainstorm ideas to serve customer needs, organize them by priority, and plan their delivery. During the brainstorming session, some of the ideas did indeed turn out to be user stories - small enough to deliver in a single sprint (usually 2 weeks) - but many of the ideas would need to be broken down into several stories, they were giant, EPIC stories (I once joked before the advent of SAFe that the level above epic should be odyssey, keeping the storytelling metaphor intact). All we had to think about back then was that in order to deliver a new product to a customer (often referred to as an initiative or project) was whether the idea would fit into a sprint, if it didn’t we knew we had to break it down before building it.
SAFe came along and defined an Epic as the Initiative itself - the entire customer value proposition attached to funding - and put a couple of levels of hierarchy in between the Epic and User Story thoroughly confusing everybody. This overloading of terms and the confusion it caused has led me to eliminate the term epic from my coaching efforts unless I’m coaching in a pure SAFe or Scrum environment (in which case I use the appropriate definition as defined by that framework). In short, if you’re using SAFe, an Epic is analogous to the Initiative, and if you’re not, Epics would be either the feature or capability in the table below.
Ok, let’s get onto the good stuff. The easiest way to think about the different types of work or outcomes is how they correspond to the different levels of scale (holons). These constructs exist in different ways in different frameworks, the above is how I like to describe them to folks I coach because I found these terms to be the most easily accessible. It’s also important to note that the hierarchy is not absolute, you can have a User Story that’s parented directly to an Initiative, or a random Feature that’s on its own with its own mini value proposition, not a part of anything larger. Let's start from the top.
Strategic Theme - There are many ways this idea is described, with attendant templates to follow (OKRs, etc.) but the overarching intent here is for the enterprise as a whole to plan out their strategic direction. These should be VERY high level, aspirational and inspiring. An example could look like: “We believe that by successfully launching and marketing disruptive products into a new financial space, we can excite a younger audience and capture X% of the market. We will know we have succeeded when X number of colleges around the country use our products as their default funding plan.”
Initiative - Once the company’s strategic direction is ironed out, people come up with ideas for either new products, or evolutions of existing products to meet the strategic need. Ideas should be thoroughly vetted using market research, customer research with feedback, competitive analysis, risk assessments, etc. The Initiative is what we think of when people use the word “project,” but rather than being project oriented, modern Agile enterprises are value-stream oriented, with most new product ideas (Initiatives) fitting into an existing value stream.
Capability - This is one of the terms SAFe uses that I like, because the word in English actually means what it is (score one for the anti-jargon folks!). I like to define a Capability as a step in the customer journey, so if the initiative is the whole customer journey, spanning the start where a customer becomes aware that a product exists, through the end, where the customer benefits from the value proposition that product has to offer. An example could look like this:
Customer Trigger > Apply for Account > Risk Decisioning > Account Creation > … Select Loan
The customer is CAPABLE of applying for an account, and eventually getting a loan. The company has the CAPABILITY to assess risk, etc., it’s clear, everyone understands what’s going on, and it’s easy to visualize how we intend for a customer to interact with a system.
Feature - In another example of the triumph of English over jargon, we have the Feature. My favorite way to describe Features is that they negotiate the robustness of the capability. Someone wants to apply for an account, great, what are the various ways we would like for them to apply? Phone, desktop, mobile, partner channel, etc. How many of those options do we want to build in for our MVP? Which are the most important? Given we are targeting a younger market, could we go live with only mobile active? People should be encouraged to come up with as many Feature ideas as they can, but we should only build those that support the realization of the outcomes we are trying to achieve.
User Story - Ah User Stories, our old friends. Most agilists are pretty clear about what a user story is, but my favorite way to describe them is: The smallest chunk of work that is verifiable, testable, allows for stakeholder feedback, and delivers an increment of customer value. The INVEST mnemonic is useful to use here.
INDEPENDENT - is whole unto itself while still being part of a greater whole (holon)
NEGOTIABLE - is a statement of intent, we can negotiate how we will fulfill the intent
VALUABLE - this one should be clear, if we can’t articulate the value it provides, get rid of it
ESTIMABLE - we should be able to estimate its size relative to other user stories
SMALL (OR SIZED APPROPRIATELY) - smaller stories carry less risk
TESTABLE - if we can’t verify that something good happened, has anything happened at all?
If your story doesn’t meet the above criteria, it’s probably a task (like configure a database) or a feature (too big to size or test easily). User Stories should be treated the same way as Features in that people should be encouraged to come up with as many ideas as they can, but we should only build the ideas that fulfill the outcomes we want to achieve. Minimal output for maximal impact.
Task - This is where all the work happens, in reality all anyone does all day is a series of tasks in the hope that something good will happen as a result. How do we know whether anything good will happen? We create the User Story construct to ensure we are focused on delivering value to our customers. Once the intent of a User Story is established, task plans are usually established against the acceptance criteria of the user story. Teams who choose to task plan should do so in a very lightweight fashion - it should take no longer than 3-4 minutes to think through the tasks necessary to complete a user story that meets the team’s Definition of DONE. Tasks are useful in validating that we are clear about how we are going to implement a given story, and in generating a sprint burndown chart.
Final note - There are two kinds of artifacts at each one of these levels, CLOSED (work that gets completed) and OPEN (activities that are ongoing. Wherever possible we want to construct anything we’re describing at any level of scale using CLOSED language, even if it’s an ongoing activity that may never end.
Describing what we’re doing using “open buckets” doesn’t allow us to understand what we’re doing, or why we’re doing it. This creates a situation where effort is being poured into a black hole as people log work against an item because they think it’s the right thing to do, as opposed to only doing what’s necessary to realize a tangible outcome. Let’s wrap up with an example.
The vague bucket “System Maintenance” turns into:
- Ensure the system has 99.999% uptime through Q3 2023
- 100,000 concurrent users can use our product without experiencing any slow downs
- Architectural uplifts will be described in the following Features
- F1 Uplift one
- F2 Uplift two
- F3 Uplift three
- Legacy Feature X will be decommissioned by X date
You get the idea. No matter what kind of work you’re doing, it’s possible to describe it from the perspective of the outcomes you want to achieve if you time box it using the holons in the above diagram. Things like System Maintenance should be a part of the strategic conversation at all levels, and should have attendant outcomes with tangible, measurable results that are aligned top to bottom and can be verified.
Thanks for reading!