by John Ragozzine
What I like most about managing projects with Jira is the level of organization and filtering I can achieve by tagging stories. As someone who used to keep his CD collection in alphabetical order by artist (with secondary ordering by year), I am deeply satisfied by how the tagging options help me structure projects. I am a Jira nerd and proud of it!
While not everyone uses components or fix versions (though you should), just about everyone who manages projects in Jira ought to make use of epics. Moreover, everyone ought to use epics optimally. I know without a doubt that when I first started using Jira, I poorly leveraged epics to an embarrassing degree. But I don’t blame my past self (or anyone) for “misusing” epics in Jira. Have you ever read Atlassian’s definition of an epic?
An epic captures a large body of work. It is essentially a large user story that can be broken down into a number of smaller stories.
Saying an epic is a large user story is akin to people explaining sprints as “little waterfalls.” I understand how those explanations come about — comparison is one of the easiest ways to grasp new concepts — but not moving beyond these limited definitions can hobble teams using Jira for their projects.
Since we’re using agile in an agency setting, client product owners are often the main priority-setting stakeholders, collaborating as our partners in creating a product. It’s important that they’re able to convey clear expectations through Jira stories and epics. The backlog of stories and epics we build together needs to help with this — especially when difficult choices have to be made about what features make it into our launch product.
Here’s where effective use of epics can pay serious dividends. Rather than viewing epics as high-level categorization (design is over here, dev is down the hall, and…), I think of the list of epics as a way of conceptualizing all the major features the client wants at the end of the project. Jira lets you see all of these in the sidebar of a project’s backlog view, just like a grocery list. A grocery list can certainly be added to, as requirements change or the product owner realizes something else is needed, but viewing it this way can really put priorities in perspective. We may refine backlogs at the story level, to be able to work incrementally, but stepping back to assess things at the epic level is how we can better conceive of an entire project.
Epics also provide a framework for what needs to be done, facilitating the creation of the stories needed to complete each list item, like ingredients you might pick up at the store. That way, rather than creating a slew of stories, then adding them into epics, you can steer work toward what is needed. Work can be visually broken down by viewing the stories that compose an epic. Being able to see the trees and the forest is hugely beneficial.
When I first started using epics, I would create groupings that made sense to me, but whose value wasn’t clear to my clients. I still wince when I think back to dev-focused epics such as “CPTs” or “TinyMCE.” An epic should encompass a part of the project that delivers value in and of itself, such as all the stories needed to deliver a working article page, not just units of development work that make sense to group together from a technical perspective. The wording of the epic should also help make its value clear to stakeholders who might not have a developer’s technical understanding of the project.
Another mistake I made was having epics that were too large or ambiguous — such as “Templates” for front-end display items or “Platform” for back-end setup. Epics this large might trivially help with sorting tasks, but would mean little to nothing to clients. Instead, now when I’m fleshing out a new website project in Jira, I add epics for all the things the client already knows they want. For example, some common epics might include “Homepage” and “Forms.” I’ll generally create epics around any discrete, actionable deliverable clearly laid out by the client. While “Responsive Design” isn’t epic material, because the features that make a website responsive will be part of many other epics for developing specific parts of the site, any individual feature described in a statement of work will likely become an epic.
That approach will lead to creating many of the whizbang epics within a project for new features. From there, we’ll often create epics for features that are repeated or common to many areas of the site, such as navigation or recirculation modules. These can be encompassed within a larger epic such as “Global Elements,” covering work on repeated elements like a site’s header, navigation, menus, and footer.
Alternately, creating more specific epics such as “Header” and “Footer” can be useful, if it helps establish portions of work that can more easily be sliced into stories, or if it would help the team be able to prioritize one portion of this work at a time. That said, product owners and the development team should collaborate to organize the work in a way that is both efficient and facilitates delivering valuable increments of work for stakeholders. It may benefit the project to combine similar features, such as a header and footer.
Of course, the definitions and examples above are from the particular types of projects I’ve worked on using Jira. Your projects will likely have their own necessary (and unnecessary) epics. But you can still use this approach for any kind of project in Jira, making use of specific, readable, actionable epics to effectively deliver valuable increments of work.
More Than a Name
While I do revel in epic naming, just as important is adding a clear summary to each epic in Jira, detailing what it is meant to accomplish. Yes, calling an epic the Awesomeness Page might be fun, but without intelligible acceptance criteria, something will get missed, and it won’t be all that awesome. Don’t assume everyone has a shared understanding of what might be needed to get from point A to point B — write it out. Otherwise it may throw a wrench in the gears down the road.
When you’re writing up an epic’s description, I suggest making liberal use of Jira’s bulleted and numbered list formatting options. This helps make requirements clear — and can make it easier to spot when something’s missing, too. This way, when it’s time to break the epic out into individual stories, everything is straightforward, and any misaligned expectations can be discussed by the team and remedied.
The 1–2–3’s of Epics
When all is said and done, epics are most useful when they satisfy the following requirements:
- They’re specific, based on a single project deliverable.
- They’re readable, written in a way that can be readily understood by all team members, regardless of their technical or business acumen.
- They’re actionable, clearly documented in Jira and able to be sliced into manageable stories.
No scrum project has all its epics on day one, and indeed, scrum practices often suggest that epics really just need to be ready at the last responsible moment, at the point when a product owner and the team are ready to create and refine stories to prioritize work for a sprint. It’s the nature (and benefit) of agile to allow space for a project to evolve into the best solution that time, money, and scope will allow. To work best within project constraints, use epics to your and your team’s advantage — and get ready for epic results.
Originally published at alley.co on September 26, 2018.