I have often thought it would be a good idea to have a strict limit on the number of epics that each person can own. So I’ve been doing some analysis to see if that might make sense. TL;DR: probably not.
I looked at numbers from August and September. I know those may not be particularly representative of our company over the long term, but they were the most recent complete months.
Here are all the active epics we worked on as a team in August. By “active”, I mean that in Jira they were in the “In Development” or “Recurring” columns.
A few things I noticed right away while working on this:
The size of an epic varies hugely - the biggest epic (SE-3311) had the same number of hours as the 47 smallest epics (220 hours).
Half of our work came from seven large epics, the other half from 67 smaller epics.
None of our epics are really that big. A single full time person nominally works 40 hours week x 4 weeks = 160 hours/month, and we only had two epics that went over 160 hrs/month in Aug or Sept: SE-3311 and BB-1218. I think that in the past we’ve had epics that had way more hours per month.
Falcon did not have many big epics, just FAL-37 in August. In September, Falcon did not have a single epic with more than 64 hours. Put another way, no single epic took up more than 16 hours per week for Falcon in September. EDIT: Due to the way LabXchange tasks were grouped into “Sub-epics”, they aren’t really showing up on here. That’s why Falcon’s hours looked low and seemingly had no big projects. Really there were 285h in August and 270h in September.
Nobody had more than one “big” epic. The epic owners of the “big” epics (defined as > 80 hours/month) tend to be pretty involved in those epics. Here the “%” refers to what % of the work was done by the epic owner.
SE-311 Daniel 41%
SE-3741 Adolfo 33%
SE-3311 Pooja 41%
FAL-37 Geoffrey 24%
BB-1254 Demid 78%
BB-3481 Farhaan 27%
BB-3564 Giovanni 27%
BB-1218 Kshitij 63%
BB-2761 Paulo 64%
BB-334 Piotr 64%
Many epics seem essentially dead, and had almost no hours logged in Aug nor Sept, but are still “In Development”. I think we should try to close those out? (SE-1693, SE-239, SE-4568, FAL-41, FAL-42, FAL-57, FAL-47, BB-4789, BB-499, BB-681, BB-2493, BB-1496)
So given the way that epics currently work, I don’t think a per-person epic limit makes sense. Epics are too diverse. However, I do think we should find ways to avoid having so many small epics as they add a lot of process overhead despite relatively little work happening on them.
I thought there might be some obvious next steps after looking at the data, but I’m not really sure. So I wanted to just post what I’ve found so far and see what you think. What do you think?
Ticket for this thread: MNG-2437. The Jira ticket also contains a link to the spreadsheet if you want to see more charts or details on the numbers.
I think one example of merging epics is what I did with McKinsey. There was a time when there were as many as 4-5 epics just for them at the same time: Support, SSO, data deletion, DND v4, Cohorting, problem reports, API performance, manager dashboard etc.
I think some of these projects were small enough that we could/should have kept it all in the support epic. Especially stuff like DND v4, which was just about review support with no real development, and was also my epic. Similarly, for SSO, I owned that epic as well, so it didn’t really need to be separate, and I eventually merged them.
Here are a few ideas for tracking epic commitment by tracking epic points just the way we track story points:
Give epics and epic size based on volume of hours, just like we have ticket sizes.
Track the hours reserved for an epic since that’s what the epic owner thinks of the load an epic puts on them, and use this to derive epic points.
Track the hours spent on meta-work tickets for an epic (hours logged on the meeting tickets, on the epic and other such metawork tickets). Use these hours to derive epic points.
We can track the number of epic points a person has taken up, and that gets us to a closer place where we can have epic limits.
However, I think the epic limit is also something that can’t be a fixed number. Just like people have varying weekly-hour commitments, from 30 to 40 hours based on their own factors, they can have different tolerances for how many epics they would like to take up. Some people will be OK with a much higher proportion of epic work than others. But as a tool to understand your own epic burden it would be useful to have this info.
@braden Thanks for looking into this and for the stats – it’s useful to have a clearer picture of this
@kshitij I like your idea of epic points – bigger epics definitely require more work, smaller ones less, and that would allow to detect and measure more easily cases of “epic overcommitment”. We could maybe then see if we can figure out an equivalence between weekly hours commitments and max epics points that are reasonable to take?
As for closing the smaller inactive epics, that is indeed a good idea if they are useless. That said, we need to make sure that they are actually useless – regrouping epics together means making the epics bigger, which isn’t necessarily a good idea, just like with bigger tickets vs smaller ones… Small epics have the merit of allowing to track goals, deadlines and scope for different projects independently. There might be a bit of additional overhead on each from having to do multiple epic updates, but it’s not like regrouping them removed the need to check and track deadlines and progress from each of the projects anyway – it can end up being tarding 2 small epic updates for one larger one… So there is going to be a tradeoff, and a balance to find.
FAL-57 is an instance maintenance epic. Now it’s closed even though we still maintain the instance. If new tasks need to be created, will they be using this epic?
Adding open tasks to a closed epic seems counterintuitive: we don’t usually change the scope of a closed epic.
But an epic is a good way to group all tasks related to that client’s instance, so it makes sense to use it in new tasks.
SE-239: is a support epic and it’s only active when there are support requests, so the low activity is normal. But it still needs budget checks (epic updates) from time to time. It’s not a useless epic.
I think it can stay open, because we usually post epic updates at the epic instead of at a task. CC @braden
The other option is to close the epic, post epic updates at a related task (SE-164), and add support tasks to the closed epic when necessary. But this is complex and I don’t know what problem it solves.
See comment on FAL-57: I updated SE-1690 Hosted Sites Maintenance to indicate that new maintenance issues should be logged against the client’s account. Most of the other hosted sites use that epic to group their tickets too – is that sufficient?
That covers which account to use. But it takes some time to see which epic to use.
It looks like it should be SE-1690 for all clients, with a few exceptions documented there.
I find it’s good enough for me, but I’d encourage others to take a look at SE-1690 and see whether they find this epic/task arrangement confusing.
In particular it says:
Some big instances have their own epic, since they have lots of stories and need their own epic owner:
Isn’t it the case with FAL-57? (Big instance with lots of tasks). Or has FAL-57 reached a point where there won’t be lots of new tasks? This could be made explicit at FAL-57.
Good point – I’ve updated that comment to explain some more. Essentially, they’re on AWS using managed services, so there’s less maintenance overhead than there was for the dedicated OVH instances.
The limit of epics also varies depending on the developer preferences. Example: for me, development epics (new features, new themes, etc) are less stressing than client maintenance/support epics.
I’m not sure that is the case for others as well, but adding a hard limit to epics doesn’t seem like a good idea, but maybe adding a client limit is? At least a “big client” limit?
Same here! I think this is just showing that the current number of epics isn’t what’s causing the problems we’re facing (stress, over-commitment, etc).
This is a good conclusion anyway, we can investigate other places.
The main follow-up from this thread is that we need to reassess the current epics (in the queue + ones marked as “ongoing”/“recurring” in Jira) and see which ones makes sense to keep? Sort of a cleanup + reassessment of the future developments.
Django 3 dependencies upgrade: also depends on Grove’s development speed: if we end up moving to another codebase for the Ocim backend, we don’t need to do this. This is already happening on Log in - OpenCraft (CC @gabor).
+1, I don’t think we’ll need those. Although keep in mind, the grove approach is still somewhat experimental, we aren’t 100% sure it’s the right architecture. But if it works well then yes, we can cancel those.
@giovannicimolin Regardless the amount of code will be kept in the code base, we still need the Django 3 dependencies upgrade epic, but should be blocked until we are done with cleaning up after implementing Console Backend & Client Console epic successfully.
Based on the conversation above I agree that it wouldn’t make sense to set a hard limit for the number of epics that someone may take (at least not without taking epic size into account as well).
But going back to the question of why we would want to introduce an epic limit in the first place, I think there’s an aspect that would still be worth following up on:
Is there another way to make sure people don’t overcommit on epics?
The “epic points” system that @kshitij brought up would probably help here. But even if we set an epic limit based on epic points, there is still the system of rotating DD roles; coupled with the rule of discovery assignee must take ownership of resulting epics, this system may interfere with people’s ability to keep the number of epics (and clients) that they own below a certain threshold.
Curious to hear your thoughts – should we consider modifying this system (e.g. by relaxing the discovery assignee must take ownership of resulting epics rule)? Or are there other options that would help keep over-commitment on epic ownership in check?
We already relax this from time to time. We’ve removed people from rotation when they felt overburdened with epics and couldn’t take any more. Having some way to know your burden might help further understand when we should do this.
That’s a great approach to balancing the epic load, @kshitij. And if there’s no one left on the DD roster, then we can take that to mean that the cell doesn’t have capacity for more new projects. It still might require a conversation, e.g. if we are “epic full” but not sustainable or producing enough work for all the people in the cell, but it’s a good way to flag this.
That approach sounds pretty good yes – getting people out of the roster when reaching the maximum number of epic “points”, to make sure that the people who are on discovery duty are actually able to take on more. It might even make sense to have an epic point estimation as the first step before taking on a discovery task as discovery duty assignee, just like we have with point estimation before taking on tasks in a given sprint? That could help inform which cell’s discovery duty assignee takes on specific new prospects?
That sounds like a great idea! This might be a little complicated to estimate accurately, though. For instance, a large part of the “epic points” for the certain projects might come from the nature of the client, how understanding or demanding they are. We should definitely start with some estimate though, and keep in mind that the estimate is a range like anything else.
