Just like stories, you should prioritize your epics. Is epic X more important than epic Y? Reorder your epics to communicate their relative priority to your team and stakeholders. It’s good to review this order every once in a while. Maybe a new API endpoint has become unblocked and it’s more important to work on that epic than the next prioritized epic.
An epic milestone is just another epic, but using markdown syntax gives it a way to standout in the epics list (e.g., 3.0 release). This is Tracker hacking but I think it’s a good way to give visual distinction the same way release markers work for stories.
Besides the visual distinction, you can now prioritize which epics go above or below this confidence line. Tie an epic milestone to a version of the app, a release date, or a financial quarter depending upon how you plan. You can link releases that fall into this epic milestone by adding the epic label to the release.
Not only is it satisfying to ship stories, it’s awesome to put an epic to bed. Yet, if you have forever epics, you and your team will be missing out on that feeling of completion. It may also be a sign that you’ve taken on too much.
Breaking up an epic by version is a natural way to still keep the theme but allow the Product Manager to manage scope. We’ve also used the visual hierarchy to break up an epic. This can have the added benefit of parallel development tracks.
When an epic turns green, it’s a good reminder that it’s time to celebrate! If icebox stories remain in the done epic, you’ve got a few choices:
Prior to a retrospective, take the time to review stories in the epic to see what went well and what could be improved.
We hope these tips help you get more from your epics. To find out more, please see our FAQ.