Mike Lyons breaks down six types of backlog items: epics, features, user stories, tasks, spikes (time-boxed research), and enablers (infrastructure work). Each maps to a different planning horizon, from releases down to daily work. Prioritization and shared understanding matter most.
Epics features, spikes, enablers. Oh my. There's so much more that can go into a product backlog. I want to talk to you a bit more about some of the things you'll find in the product backlog at the team level. I mentioned Epics when we were discussing user stories together and epics sometimes get described as just really large user stories. We need to go a little bit deeper there. Epics are the, indeed the largest piece of work that we might have in the backlog. They span sprints, but they can, they can even span releases. So an EPIC is a large piece of work, but it does have some clear benefits. A benefit hypothesis typically, like we might say, well, we think this EPIC will release this piece of value and then we break that down further into smaller components. Epics are part of the planning cycle, the planning onion, if you will, and really tie into that vision. That sort of piece of where is this product going? What problem is this product going to solve? At the most macro of levels, sort of one level down from Epics, we have a very common term in the industry called feature. But a feature is something that spans sprints but can fit within a release cycle. A feature, common industry term to you might recognize as a feature on your mobile device, like facial recognition would be a feature of that, or the ability to swipe left, to delete or swipe right to mark as unread. Those would be features. Features of a product. Very common term. You're probably familiar with the term anyway, but it's comprised of a number of different user stories. So features are fulfilled by user stories. So think about this work sort of in a breakdown in this way. Epics span multiple releases. Features fit within release cycles and then stories fit within, within Sprint sort of epic features stories. And we can even get more granular at the daily level with tasks. And so there's kind of this work sizing breakdown, if you will. Again, we're taking big rocks and breaking them into little rocks. Spikes is a term you'll hear me talk about. Well, spike spikes are just this time boxed research activity where we're going to go find out more about what we don't know. We might try out alternatives. Maybe we've got three different ways that we could solve a particular feature. We might go try that out. Let's go run through that. So we'll insert a spike and do our research and then come back and we want to demo what we found. So you always want to demo the work you find during a spike, but that needs to be in the backlog. If you is it important prioritized by the product owner? Is it important enough for us to go do this research? Maybe not right now. And that's okay. It would get a spike yet reprioritized. Another component you might find is this idea of enablers. So sometimes enablers could be infrastructure enablers. Maybe it's setting up the database layer, maybe it's setting up business rules. Those things that don't inherently of themselves release value, but are needed to enable the release of that value. They're called enablers. So those are some of the additional items you might see in your product backlog that can be prioritized and will determine whether or not we want to we want to work on those things. And again, you'll find here, each of these items really helps us get to that shared understanding.
