4

Background

I'm working for a web development agency. I take responsibility for managing the work that the developers in our company do for our client. We're using JIRA for task management.

Epics with Unlimited Scope

Agile methodologies suggest using epics for user stories that can be decomposed into smaller ones. The problem is that the work with the client is probably going to be a long-lasting partnership, so there's always feature creep. My point is that that epics should be finite, but in my case they tend to never be finished because there are always new features that get added to the system.

Examples of epics that I use include:

  • Contract list

    As a user, I must be able to list and filter contracts, so that...

  • Contract editor

    As a user, I must be able to edit contracts, so that..

These epics seem like they'd last for years. How can we manage the scope of these epics?

1
  • 2
    I think this is a great question, partly because a lot of people have it, and partly because it highlights the problem of letting the tool drive the process. :)
    – Todd A. Jacobs
    Commented May 26, 2017 at 5:21

2 Answers 2

4

TL;DR

Whenever possible, think of epics as placeholders for more detailed product backlog items, not as evergreen stories. It's better to add new stories to the Product Backlog as they are discovered or requested, rather than invite scope creep by misusing epics as permanent Product Backlog work-generators.

Deliver Stories, Not Epics

In agile methodologies, you don't deliver epics or themes; you deliver stories and tasks. In Scrum you should also be working in well-defined iterations where the work is small enough to fit into a single Sprint.

When you have an epic like:

As a user, I must be able to list and filter contracts, so that...

it isn't really actionable, since it meets exactly none of the INVEST criteria. Instead, you should be using your Backlog Refinement and Sprint Planning ceremonies to decompose specific features into discrete user stories.

Even if your epic is an evergreen item where you're always adding new functionality to lists and filters, each story within the epic should be clearly scoped and well-defined before being accepted into the Sprint. For example, during Backlog Refinement, you might look at some recent requests related to your epic and add a story like:

As a user,
I want to list all non-expired contracts by expiration date
so that I can see which ones are about to expire.

or:

As a user,
I want to filter out all expired contracts from the to-do list
so that I only see contracts that are still valid.

While both of these stories could conceivably fit within your epic, they are probably small enough to fit within a single Sprint, are likely to be testable, and describe a concrete value proposition.

The Product Owner should be actively involved in getting stakeholders to identify work as discrete features. The entire Scrum Team should be involved in helping to decompose the larger epics and stories so that the PO can prioritize them.

Focus on delivering small, functional slices rather than on unestimatable or open-ended work items. If you change your focus, you'll find that you're delivering features and value every Sprint instead of wearing an epic-shaped albatross around your neck.

0

If you are having too many Epic problems, I would suggest looking at your stories and examine them again.

The root cause seems to be due to the fact that you are not delivering values by working on user stories but only by delivering epics. (I'm assuming this)

If that's the case, you need to work with your client to make valuable and small user stories, which is brutally hard to do. Otherwise, you will be in this infinite loop for on and on and on and ...

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.