Your experience: handling Epics?

Lalo Martins
Yesterday’s Cool, Today’s Lean
1 min readNov 27, 2015

The term “epic” came into use in the Agile world, borrowing from the “user story” metaphor, to refer to a subproject, a larger-scale aggregation of work that needs to be split into smaller work items in order to be executed. Even Jeff Sutherland recommends you “further down in the backlog, write coarser items, which will get refined as they approach the top”.

How does your organization handle them, especially if your process looks more like Kanban than Scrum?

Here are mine:

Ableton

At the time I was a ScrumMaster there, we were using Pivotal Tracker, which treated epics as glorified tags. There’s no relative ordering of epics, or Sutherland-style listing them as items until they’re close enough to break down.

In parallel to that, we maintained a higher-level “epic backlog”, which worked in conjunction with a 8-week “meta-sprint”.

LimeMakers

In LimeMakers, where the process was more Kanban-like, epics weren’t real work items tracked in the backlog. We borrowed the same “Epic Backlog” idea for higher-level planning, but being a smaller, earlier stage team, we would use it more to discuss what we were going to do and whether we wanted to, review strategies and adjust plans as our hypotheses were validated or discarded. When it came to actual work items, we didn’t even take our “epics” in consideration.

You?

--

--