Initiatives, Epics, Features, (User) Stories… which is which?
A small side note first. Just in case any of you were expecting the second part of the series on how product development benefits from flow, I still owe you that one. But thought of today exploring something else, which has some connection to flow as well.
Sometimes I observe people getting too focused on semantics—on what language we are using for something. Don’t get me wrong – I am all in favor of using more precise language when that adds to clarity (in fact, I have humbly identified not focusing on that as a shortcoming at some point in my career).
The thing is that often the problem is not fundamentally a matter of the language we use, but rather of a shared understanding of what we are trying to achieve. And only then, afterward, arguably standardizing the language in a context can have some applicability.
To me, that’s the case when we talk about all those different terminologies that ultimately are meant to capture what we are working on. Just to name some recurrent ones:
Initiatives
Epics
Features
(User) Stories
Tasks
To be more specific, an example where I see conversations derailing is when you get stuck on what some piece of work should be: an Epic, a Feature or a Story. And people can get quite passionate about arguing that.
In my humble opinion, that's the wrong framing to deal with issues like that. Take (User) Story; it is much more about a technique to frame how you write the stuff you are going to work on. It doesn’t tell much about how big or small it is.
That brings me to my fundamental point:
A much better framing for those different levels of stuff to work on, is the idea of batch sizing.
Slice it as many times as it makes sense in your context. Lean towards smaller (less risk, more progress, faster learning) for the stuff that actually flows through the development process (that's the bit of connection with the series on flow and product development).
A very useful thinking model on how to approach that is Klaus Leopold's Flight Level. Think of slicing and batch sizing from the angle of how much detail or broader perspective you want to have (like also in the metaphor of "seeing the forest for the trees"). It's largely a matter of visualizing and giving context that connects what is happening in the ground to the bigger picture, and vice versa.
Be aware that there’s likely a limit where you reach diminished returns in slicing. I would imagine that in some context, something up to 5 could be reasonable. More often (from my experience), we will talk about something around 3 levels (4 if teams like to break down things into even smaller bits of work).
I remember that at some point I told the team I was leading at the time something like this:
In the end, if you really think about it, there's only work. That's what makes things happen, or not. Obviously, it's better if we can put that in context and understand how that connects to the bigger picture, the goals we are after, and all of that. But we did our job wrong if, on an ongoing basis, what you mostly care about isn't the work you defined (by having the context you need to do it properly) to work on.
I know it's a slightly more complex than that, but I try to keep things simple. It's often a challenge, but one worth putting the fight on!
By the way, although there the dynamic is not quite fully the same as with the example I am exploring here, something similar also applies to things like OKRs (or any equivalent way to capture goals we are after and measure them on an outcome basis). You ain't working on your OKRs. That's a bit of nonsense. You are working on "stuff" and hopefully that is the right thing to do now, so to move the needle of what you are measuring with your OKRs, for instance.
That's why I personally prefer to stick to the language of work items, as a general definition. Should we need to create a common language to describe the different (flight) levels of batch slicing? That's fine with me, but don't start the conversation from the angle of the language.
Rather, create a shared understanding of what you are trying to achieve and how that can be modeled at different (flight) levels; maybe agree on some principles for the slicing of the batches, and only then define the words you are going to use to describe that. By all means, then adopt stuff already used out there (initiatives, epics, features, stories, etc.), if there's no good reason to create your own.
Do you see the difference? I would expect that to lead to a much more meaningful conversation than arguing whether something should be X or Y or Z…
By Rodrigo Sperb, feel free to connect, I'm happy to engage and interact. If I can be of further utility to you or your organization in getting better at working with product development, I am available for part-time advisory, consulting or contract-based engagements.