Why do I prioritize a product using epics instead of user-stories or initiatives?

Have you ever seen a toddler, who can't yet crawl on all four let alone sit upright, already able to peel shrimps with a knife and a fork? I would love to witness this. But so far, I haven't. That said, I have seen many software projects that could do pretty much exactly this. The database model is left untouched, the API communication with crucial services had not even been tested yet, but we are fighting about the color of some buttons and where to place a hint on the screen.

When you create software, you want to go thin-deep and customer-value-oriented. You want to traverse as many layers as possible, and deliver value as soon as possible. We talk about cutting the topics "vertically". But even when we follow this approach, we often land with some big vertical ideas competing against each other. So how do you rank those topics against one another? You don't.

In our software/agile lingo, we talk about "user-stories", "epics" and "initiatives" when we talk about those topics. Among the many definitions of "user-story", "epics" and "initiatives", here's the ones I like to use:

• User-stories (US) are atomic changes we do in order to help the user achieve a goal. Each of them create value in itself and is of releasable quality. They are "potentially shippable". But quite often, a user-story will only help X% of our users. We will then gather feedback among chosen customers. But we might hold the release until a bigger use-case is covered.
• Epics are those bigger use-cases. They are a bunch of user-stories, bundled together. And we think that it makes sense to roll those out at the same time.
• Initiatives are a bunch of epics bundled together. They form a container around a set of epics relating to the same topic. They exist solely so that items that logically belong together, somehow fall under the same umbrella.

The right item level to prioritize your work, is the "epic level".

Let's take the analogy of a baby. In the development of a baby, there are multiple big topics: “eat”, “move”, “become clean”, “motoric development”, “play” etc. Sure it would be nice, if a toddler could use a knife and fork or walk upright right from the get go, but it’s not realistic. We won't be able to finish any of those and then go to the next. We need to advance those, chunks at a time, incrementally. We'll settle for crawling and drinking from a bottle. Then we'll go for walking on all fours and eating with their hands. Later on we'll talk about table manners and sitting upright. Can you hear the french-man in me talking?

Those big topics are "initiatives". If you were to try to rank them against one another, you would face the following problems:

1. You wouldn’t “finish” any of them before years (if ever?) and thus they would all remain "prio 1" forever
2. You would risk ending up with a toddler eating with a fork and knife, but not yet able to crawl on all fours
3. One day the priorities would be Topic 1 > Topic 2 > Topic 3, and the next month Topic 3 > Topic 1 > Topic 2 and then change again...
4. In order to prioritize those topics, you would constantly have to “look inside the topic" to know what has to be done next

So as soon as you feel the need to rank something, it has to be "small enough". If the items you rank are too small, you spend a lot of time refining them, regardless of their priority. On the other hand, If your items are too big, you will most likely rank them all "prio 1". Which will lead you to context swapping and not finishing any of them before a long time.

Don't get me wrong, there is a time to rank user-stories against one another. That is shortly before you tackle them. But when you think about steering a product, epics is the biggest measurement you can and should use.

Photo by Denise Johnson on Unsplash.

PS: when I chose this picture, I wanted to hint at sorting containers of different size... not sure that worked out so well 😂