In the recent months, I’ve taken up a lot of epics and was overcommited for a good number of sprints.
This forum post is just a recap and possible improvements that we can to do make epic management easier and avoid some pitfalls.
Near June, I’ve ended up with 3 edX projects (LTI, LTI Advantage and ORA) and new client, on top of the sprint management roles, Ocim UX rework epic and OSPR prioritization (plus one that edX decided to postpone). While not all epics kicked off at the same time, they’ve added a significant burden on stress, mostly due to having to do a lot of context switching.
At the worst point (when all epics were running at full speed) I barely did any development work, and my sprints was mostly about meetings, reviews, epic management & planning and helping people get onboarded in the project.
I didn’t exactly expect this, and I hoped I would be able to still do some development work. This was something our handbook and onboarding course didn’t prepare me for. To be fair, there’s a tip: Don’t take too many epics at a time, but it didn’t really apply as the discoveries were done way earlier in the year and suddenly the clients wanted to get the work going.
I’ve had to brush up my somewhat forgotten project management skills and also looked at what everyone else in both cells were doing to be able to do the best possible given the situation. With that, and after doing some research on project management, I’ve learned a few things that helped me, and hopefully will help others when taking up epics in the future:
#1 When estimating for an epic, add estimates to onboard developers into the project, and after kicking off the epic, take some time to write what’s needed to get set up and working.
I can’t stress how much this one helped me with the ORA v3 epic, and it definitively saved me a lot of time. People who had issues and managed to fix them contributed to the ticket and made future onboardings easier (see https://tasks.opencraft.com/browse/BB-2501).
Also consider the technologies you’re dealing with (React, Terraform, etc), and add some more onboarding to cover that too. In the Ocim UX epic, I missed considering that a portion of the team didn’t have React knowledge and that I needed to spare some time for learning. That ended up inflating the budget usage in a few tasks, and left me with limited assignee options for each sprint. This is something that should be dealt with in the discovery phase, before coming up with estimate numbers.
I feel like having a template or checklist (just as a guide to epic owners) would help.
#2 If the discovery just provided ballpark estimates, take a good chunk of time when the epic is kicking off to sort things out.
In the LTI 1.3 epic, the discovery just provided ballpark estimates, and didn’t cover a lot of ground in the implementation side. Out of the 100 hours of the epic, I took 20 in the first sprint to get everything sorted out: reading our the full spec and related documents, trying to get the edX side of things working, building a ugly PoC implementation to define architectural decisions and figure out what would be the proper implementation and delivery plan.
Also, when just a few items in an estimate were ballparks, schedule a discovery to flesh out proper implementation plans earlier in the epic.
So for this point:
- If estimating in ballpark estimates, go for overestimation, and consider that the work in the epic will have to cover a full estimation of every requirement.
- Schedule technical (internal) discoveries to get rid of uncertainty in the project early in the epic run.
#3 Preparing before delegate things
This was something that @antoviaque hammered on early in the edX epics (when the entire team was kinda overcommited): delegate work to newcomers. It has hard requirements to work properly:
- The work needs to be easy to be onboarded to work on (with an onboarding guide) - covered by #1
- Tasks need to be well estimated and have a clear implementation approach - also covered by #1 and the adoption of the new task template.
The ORA epic fit that criteria well (easy onboarding + well defined tasks), and so most of the work was done by newcomers without previous context.
#4 Don’t assume client expectations, set them clear early on
This happened in the LTI 1.3 implementation epic. Until 70% done, I’ve though that edX wanted us to implement LTI 1.3 core support, and that was what was estimated in the discovery document.
After working on the project and getting to know well LTI, I’ve figured out that LTI 1.3 didn’t include any mechanism to pass back grades into the platform (LTI 1.1 and 1.3 don’t have feature parity). They assumed LTI 1.3 was just a refresh of the previous version and that it would offer the same features.
I had to clear that out with edX, and we ended up creating a new project to handle the extra LTI extensions, but this definitively led to some disappointment from their side.
This was one risk we took by doing just a ballpark discovery.
#5 Allow the epic owner to be a different person than the one that did the discovery
There’s pros and cons that we discussed before, but looking back I should’ve tried to pass some of the epics to other assignees and stay as reviewer.
Aside those points from the epic management side:
- Adjust committed hours: I’ve had to go from 80h/sprint to 70h/sprint to accommodate for the extra stress and context switching.
- Take time off: still pending on my list, but taking a sprint off will help a lot to ease up the stress built up over the projects.
- Pass on epics if overcommited, learn to say to no new work when already have hands full (this is pretty much a note to self
)
I have a feeling I’m forgetting something, but I’ll post as soon as I remember it