So you believe in the benefits of grouping things. But how do you make sure you’re grouping the right things, in the right way, in the right groups?
Because failure is the best teacher, let’s look at how to write some terrible, bad, no-fun, horrible epics and note the strategies to avoid them.
The catch-all grouping
Our brains love to categorize. But sometimes the first, seemingly obvious, category is not the best one.
🍔 Let’s revisit our friends at thoughtburgers (home to the tastiest and most thought-provoking burgers!), who need to change their payment provider.
Take the following set of stories:
- Make payment using new provider
- Use saved payment method
- Refund orders from Admin
- Save payment method (during payment)
- Payment reliability metrics
It is very easy, almost natural, to group them like so:
- Front-end
- Make payment using new provider
- Save payment method (during payment)
- Use saved payment method
- Back-end
- Refund orders from Admin
- Payment reliability metrics
But this is a mistake. Grouping horizontally, in this case by technology layer, prevents most of the benefits we expect from epics.
These horizontal-black-holes suck everything into them. What seems reasonable at first slowly grows until they become meaningless. Let’s demonstrate by introducing a few more stories:
- Remove saved payment method
- Save payment method (standalone, from account area)
- Automated refunds
- Notify on Chargeback
And now we group:
- Front-end
- Make payment using new provider
- Save payment method (during payment)
- Use saved payment method
- Remove saved payment method
- Save payment method (standalone, from account area)
- Back-end
- Refund orders from Admin
- Payment reliability metrics
- Automated refunds
- Notify on Chargeback
Everything naturally fell into the existing epics, so they must be the right groups, right!? Multiply this scenario by the size of a real project and it should be obvious how this approach is far from ideal.
Special shoutout for the Admin
Another classic example is the “Admin” epic. The admin area is a separate vertical slice, but it’s not a function or an outcome. What’s the actual problem or feature?
It’s fair to say that the Admin area typically serves a different user and so there is probably an epic that represents these users lurking somewhere. But the trouble with a generic “Admin” epic is
- It becomes a catch-all blackhole, as discussed above
- It restricts our ability to discuss launch milestones. If everything to do with the Admin is in the Admin epic, at what point can you launch?
As an example, Refund orders from Admin
triggers our pattern matching for “Admin” but the better grouping is around refunds.
Once an epic, always an epic
Once created and communicated publicly, there can be an inertia to epics. A resistance to change. A feeling perhaps that the cost is too high to change it now.
But as we learn more about a project, the domain, user needs and requirements, our understanding and the impact to priorities evolves. Epics should be no exception. Nothing is set in stone and everything can change!
Stories can become epics. Epics can become projects. Orphan stories can identify new epics and we can shuffle things about!
This is especially true of smaller projects. A project that feels like one feature and therefore one epic. After all, we only want to group vertically! Let’s look at an example:
🍔 thoughtburgers want to display the nutritional information for each of its menu items in its app
- Project: Nutritional information
- Stories
- Nutritional information per menu item
- Detailed nutritional info on-tap
- Nutritional guide in account area
Seems simple enough. But then, someone asks, what about when you customise a burger? Like when, heaven forbid, someone removes cheese! Should the nutritional information dynamically update? Well let’s just add another story:
- Project: Nutritional information
- Stories
- Nutritional information per menu item
- Detailed nutritional info on-tap
- Nutritional guide in account area
- Dynamic nutritional info based on customizations
But as the team looks into it they discover it’s more complicated than first thought. The data for nutritional information per customization doesn’t exist and isn’t easily integrated. Now the scope has greatly increased and it’s blocking the team’s ability to launch.
Epics to the rescue!
- Fixed Nutritional information
- Nutritional information per menu item
- Detailed nutritional info on-tap
- Nutritional guide in account area
- Dynamic Nutritional information
- Dynamic nutritional info based on customizations
This doesn’t really change anything but it allows the team to talk in clear terms about what they’re focusing on and going to launch, while also being clear on what can come later.
The epic epic
Sometimes you create an epic, or are given one, that as you start to plan out the work, you realise is too big.
You feel this when you start reaching for some groupings between your epic and stories.
But you may feel restricted because you already have an epic and an epic groups stories. Bah! As the great Curtis Mayfield says:
Move on up!
If you need another grouping between what you already have, do it! It will help you plan better and it will make communication easier.
If the tool is getting in the way and won’t let you create the hierarchy you need, you can even just prepend the name.
Do what you need to do to create those groups!
Unnecessary indirection
Sometimes, the adherence to creating epics can make a project worse.
A 1-1 mapping of epic to story is a smell worth sniffing. Occasionally the story can be so different that it makes sense to have an epic for a single story. But oftentimes it might hint that things are amiss.
If a project is small enough to be solved with just a few stories, forget the middle management of epics. The layers and groups only matter when they help not hinder.
If the shoe don’t fit, don’t force it!
Group well, fare well
It’s easy to group things, but it’s not always easy to group well. Take lessons from our collective history to avoid the pain of poor groups. Trust me, it will feel epic.