Creating an ideal epic

What I like most about managing projects with Jira is the level of organization and filtering I can achieve by tagging tickets. As someone who used to keep his CD collection in alphabetical order by artist (with secondary ordering done by year), the tagging options help me structure projects in a deeply satisfying way—except for labels, which totally bite.

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. And more over, everyone ought to use epics optimally. I know without a doubt that when I first started using Jira, I leveraged epics embarrassingly poorly. 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 get how those explanations are arrived at—comparison is one of the easiest ways to grasp new concepts—but not moving beyond these distorting definitions can greatly hobble a Jira project.

Agency agile

My use of agile is within a web agency, My product owners are (typically) my clients, and many do not have substantive experience with scrum practices. What’s more, the product owner and the client are often one and the same. While good product owners keep stakeholder expectation inline with reality, clients (or humans as a whole) have tough times saying no, or not right now, to themselves.

Here’s where effective use of epics can pay serious dividends. Rather viewing an epic like a supersized user story, I think of epics as all the things the client wants at the end of the project, laid out like a grocery list. While you won’t have all the epics you will need to get to done at the beginning of the engagement, the bulk of the epics can be plucked right from the SOW deliverables. These come in handy during backlog refinements, since it paints a clearer idea for the client the steps necessary to complete a request fully. And once you have a slew of tickets, being able to visually show the breakdown of what work is needed to complete which deliverable is hugely beneficial. We may refine backlogs at the ticket level, but stepping back to assess at the epic level can put priorities in perspective.

Not so epic epics

When I first started using epics, I would create groupings that made sense to me, but not so much to my clients. I still wince when I think back to epics like CPTs or TinyMCE. Using jargon that works for the dev team but not the client is 100% backwards.

Another mistake I made was having epics that were too large or ambiguous. I would make epics like Templates for front-end markup, or Platform for things related to the admin, database, or hosting environment. Again, this was me drawing lines of demarcation that would help me sort tasks, but to my clients the distinctions were irrelevant at best, confounding at worst.

Instead, when I am fleshing out a new website project in Jira, I add epics for all the stuff the client already knows they want. Homepage and Forms tend to make it into all of my project epic lists. From there, I create epics around any deliverable clearly laid out by the client that isn’t too broad. While Responsive design isn’t epic material, any cool feature (new or refreshed) described in the SOW will definitely be an epic.

The above are all the wizzbang epics within a project. But, without foundational work, a website would just be a seldom visited killer homepage surrounded by search engine trafficked inner pages that act like ugly cul-de-sacs. I always have an epic called Global elements as a catchall for things like the site header, navigation, and footer. It isn’t helpful to have a Header epic and a Footer epic, because there’s no point in prioritizing these against one another. Both are needed, so can share an epic and rely on story summaries to separate the work.

Anyone who is working with a CMS also needs an epic called Standard pages or something similar. The benefit of a CMS is the use of a single, cohesive templating theme across the majority of the site’s pages—for more than just blog posts. A large percentage of any site’s pages are basically the same template, so highlight this fact with a nice, shiny epic.

Often with CMS templates, a template is created that offers myriad options for layouts and other unique elements. This utility template helps site owners make visually and functionally distinct pages on their site with little to no technical know-how. There are lots of ways to name this epic, but some of my favorites are Premium page, Über page, and Super page. These names let the client know that this page does a lot, so might be worth prioritizing highly.

More than a name

While I do love naming my epics, I really get mileage out of them by adding clear summaries to the epic ticket, detailing what it is meant to accomplish. Yes, calling an epic the Awesomeness page might be fun, but without intelligible acceptance criteria documented within Jira, something will get missed. Or, something will be assumed as included that can throw a wrench in the gears down the road.

Epic descriptions are easily reviewed and understood when added in list form. I tend to have these tickets reviewed and approved by every member of the project team during kickoff or sprint 0, so any misaligned expectations are remedied very early on.

The 1-2-3s of epics

When all’s said and done, epics are most useful when they are:

  1. Based on a single project deliverable;
  2. Readily understood by all team members, regardless of their technical or business prowess, and;
  3. Given documentation inside Jira that the team all reviews and agrees upon.

All that being said, no project has all its epics on day one. It’s the nature (and benefit) of agile to allow the 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.

Hide on Mobile: A display: none; allegory

Once upon a time, a traveler entered a nondescript pizza palace. On each of the red-and-white clothed tables were squat shakers of parmesan cheese and crushed red pepper. The air smelled of garlic, oregano, and all the trappings of traditional East Coast pizzerias.

The traveler approached the counter, surveying the options available. Pepperoni sounded good. “Shopkeep! I’d like a pepperoni slice, if you will.”

A mustachioed man, wiping his hands on a stained, white apron, waddled out from the kitchen. His name tag read: Sal. “You want that to go?”

Debating opinions is bad communication

Two safe words in web development are “user error.” Something doesn’t work? Not my problem—it’s user error. And while this does happen, it’s also kind of a cop-out.

I have been the user in many “user error” stories, when a website feature did not work as I expected. I reported the issue to those who could fix it, and was told I was “doing it wrong” and my difficult was simply user error. When you’re having issues, being told you’re wrong isn’t helpful. Undercutting my experience as flawed isn’t a proper fix.

Should you apply to WordCamp US?

For the next two months, the organizers of WordCamp US will be accepting speaker applications for their second annual event. Taking place December 2-4, 2016, in Philadelphia, it’s being billed as the largest WordCamp in the world (that is, until I finally get funding for WorldPress). To put it another way, it’s kind of a big deal.

Which begs the question: should you apply to speak at WordCamp US 2016? And before I tell you the answer—SPOILER ALERT IT’S YES – I mean seriously, why would I write a whole blog post just to dissuade you from applying. It’s not like you not applying would improve my chances of being accepted to speak…unless—

Where was I? Ah yes, so as I was saying, before I tell you the obvious truth that, yes, you SHOULD apply to speak at WordCamp US, let’s review some 2015 schedule stats which may inspire you to apply.


WordPress: In crisis

One of the selling points for (the free software that is) WordPress is its user friendliness. Intuitive, accessible, open—all of these words are at the root of what WordPress is and why it is of such benefit to the publishing world. I largely agree with this.

That said, I know I am an insider (albeit peripherally) to the WordPress community, so need to remember that I am an unreliable narrator of WP’s story. I’ve taken a critical eye to WordPress before, and I’m inspired to do so again from the wonderful book “Design for Real Life” by Sara Wachter-Boettcher and Eric Meyer. Comprised of examples of developer choices in language and quirkiness that hurt people in real-life, the book’s thesis aims to shift design thinking toward creating technology that is less assumptive, less witty, and therefore, less alienating.

In choosing to examine WordPress—specifically its onboarding process—I’m not out to indict the product in any way. I know WP well, make my living from it, and honestly, when something powers 26% of the internet, there exists the most potential to influence the web dev industry through leading by example.


Managing internal projects

As a project manager, being assigned an internal project can be a breath of fresh air, albeit one with caveats. Perhaps you’re overseeing work on an internal productivity tool, or migrating a business process from a legacy system to a new one. Regardless of the circumstances, when your colleague suddenly becomes your client, there are steps you need to take to ensure the project is a success.


Battery Status API: Empowering Device Batteries to Be In Charge of UX

Let me set the scene: you’re in an unfamiliar city and you’re on the move. Through a series of travel delays and general unpreparedness, you are about to be late to interview for your dream job. Frantically, you try to continue to make progress on foot while not knowing the actual address of the place. Your phone’s map app doesn’t recognize the business’s name, so you need to search for their address in your smartphone’s browser.

Ixnay on the “you guys,” yous guys

Word choice is important, a fact not lost on famed Norse explorer Eric the Red. When he discovered a semi-inhabitable landmass northwest of his native Iceland, he knew he needed a snappy name to attract settlers. How else would you get people to move to a giant, rocky ice slab roughly the size of the midwestern United States?

And so he dubbed it “Greenland” and tapped into the verdant dreams of his people, thereby successfully pulling off the greatest bait-and-switch ever.

And while some word choices can birth a nation, others have the power to elevate (a Subway “sandwich artist”) or deride (literally any racial slur). But many words are more nuanced in how we use them and how they affect both people, or an environment. I’ve written before about seven words you can’t say to client, but there’s one phrase that I constantly hear that just plain bothers me: “you guys.” Continue…

Being Bitten By Bytes: You May Have an Image Issue

Collective nouns are single words for a group of things and I love them all (except for “guys”—that’s a bad one). I especially enjoy animal group names. Get three or more bears together, and it’s known as a sleuth. Same with a pride of lions, a bale of turtles, or a romp of otters. Bird collectives have the best names: a murder of crows, a chain of bobolinks, a deceit of lapwings.

Group terminology goes further than animals. A collective of houses could be a town. Words group together to form sentences. And a website is nothing more that a collective of files. A pile of files.