So, in terms of breaking down, or more accurately, building up, your backlog, what is an epic? It’s more than just the result of functional decomposition of your intended application. It is a usage scenario, a process flow if you will.

One Epic Story will span many user stories, telling the adventure that a particular piece of data will go through as it is created, lives its life in the system, and finds its way to the end of its lifecycle after being handled by many people. One such Epic will tell the story of the “Happy Path,” the one that 80% of the time is the one that is taken. Other Epics will tell the story of the less common paths. It is the common theme of these Epic stories, what they have in common, that makes up a Theme.

Because Epics are a kind of process flow, multiple Epics may contain the same story. Which ever Epic is selected for implementation first will result in the stories that make it up being implemented. Later epics that are implemented will not (necessarily) need to do anything for some of the stories that make up that epic, but will involve implementing only those stories that do not yet exist in the system. This means that Stories and Epics have a many-to-many relationship.

Wait… many-to-many? How many of the tools actually support creating Epics in a many-to-many relationship? NONE. Yes, that’s right, NONE that I have evaluated, not even the Analog (3×5 card) method. How can that be?!

Chances are, it’s because the Analog can’t do it. Why can’t the analog do it? Because you have a physical card that can only be in one place at a time. The focus on automating the analog process has blinded the developers of the various tools to the advantage that a digital tool can have, namely that one ‘card’ can be in many places at the same time.

To make matters worse, the users don’t know how to express the fact that they need this to the tool vendors. They build documents OUTSIDE of their backlog management tool, to make up for the fact that the backlog management tool is not facilitating the true modeling of their system in this way. It doesn’t occur to them that EVERYBODY is doing this, for any project of any respectable size, and that this is an opportunity for the tools to help the product owners do a better job of defining what units of work really define “business value.”

You see, a feature, by itself, may not add business value. It’s only when several individual features are delivered together that the users can actually get WORK done. So in order to get business value, a collection of features need to be created in concert.

Problem is, the tools that allow grouping stories only allow those stories to belong to one group at a time. This precludes the creation of this kind of Epic story, that re-uses individual story cards time and time again. The end result? The tools actually encourage people to do functional decomposition. And there is NOTHING in the tool to allow the product owners to do the mapping between low-level features and high-level processes. The really good product owner will have to do it all OUTSIDE the tool, and map the end result into the tool. Less skilled product owners struggle to lead their teams to deliver value, because the tool has encouraged them to break down the work into something other than units of value-providing functionality.

There is something wrong, here.

You COULD define your user stories at a higher level. They could be the epic adventures, already. Sure. But what would you do with the user story that addresses one small piece of functionality, providing an important requirement of the system? You NEED to be able to capture those fine-grained requirements, but you also NEED to be able to capture and express the process flows. Agile tools, today, don’t really meet the product owner’s needs in that regard.

If Only…

If only there was a tool that understood this need. What would that tool be like?

Well, first of all, it would allow the user to create a hierarchical grouping that maps to stories in a 1:N relationship, and it would ship with one such grouping already defined, and called a ‘Feature Group’. It would also allow hierarchical groupings that map to stories in an N:M relationship, where a story could belong to multiple groups. It would ship with at least one such grouping: Epics, or Process Flows, or Use Cases, and maybe another, called ‘Theme’ that allows one Epic to be a part of multiple Themes. Two other groupings that would exist would be one for grouping stories by the Role, the person whose perspective the story is told from, and another that lets stories (or epics) be categorized by their impact on the bottom-line of the business. I’ll talk more about these other types of groupings, and how existing tools can or can not allow you to accomplish them, in a future installment of this series.

But here’s the important part: The ideal tool will understand the difference between a 1:N hierarchy and an N:M hierarchy, and will let the user create the one that the user needs. It will not impose upon the user by only allowing one such hierarchy to exist. After all, if you have created the code to allow such data relationships, why limit the user’s creativity by only letting them use that ability in one narrowly defined way?

Okay, sure, if you try to be all things to all people, chances are that you will suck equally to everybody. The reason that happens is because you reflect that generality in your user interface. So, you don’t provide the guidance and focus people need to be successful with your tool. So don’t do that!

Instead of building a single user interface for relating objects, you create a user interface that is optimized to the use case of creating feature groups in a 1:N relationship. Then you let the user rename the relationship type to whatever they want it to be called, AND you let them create ANOTHER relationship type, called whatever they want, that also describes a 1:N relationship. You let them define what the components are called, and how they aggregate, and all that fun stuff.

Then, instead of reusing the 1:N user interface for the N:M user interface, build a custom one, one that is more applicable to that use case. One that lets the user view the candidate objects (story cards or something else) in their 1:N hierarchy, or in some other N:M relationship, and drag and drop (for example) onto the hierarchy to assign membership. Then, again, you come pre-configured for certain useful N:M relationship types, but you give the user the ability to create their own.

Of all of the tools I evaluated, the only tool that comes close to this vision is Mingle. It is a totally generic, but very powerful tool that lets you define your own card types, and your own relationships between them. Unfortunately, they do not support the ability to define relationships where a particular card type (like a Feature Group) can have a hierarchical relationship, such as a feature-group containing other feature-groups. And it lacks the ability to make N:M relationships. Add to that the fact that they are a ‘generic’ tool, and the fact that the generic nature of the tool comes out in its user interface, and you find that Mingle still has a ways to go before it meets my idea of the ‘perfect’ tool.