How can I close an Epic with open defects?

Question

I have an Epic. Some defects are closed, but one defect is still opened and deferred until the next release. How can I close the current Epic since one ticket is still not closed?

Answer 1

TL;DR

If the Scrum Team's Definition of Done for the epic requires this defect to be fixed before the epic can be considered fully complete, then the epic isn't really done until the defect is fixed. In that case, it should remain open. However, if the defect isn't on the critical path for your epic, you can work with the Product Owner to reassign the defect to a different epic, issue, story, bug, or chore (or whatever your particular tool allows you to call this particular unit of work) so that it no longer blocks your epic's status change.

You should never do this simply to close out an incomplete work item. You should only do this if:

1. the defect is deemed non-essential to the successful delivery of a working increment within the current iteration; or
2. the defect isn't really part of the Definition of Done for the current iteration, and deferring it won't endanger the current Sprint Goal.

Outside of those two key constraints, work items can be freely moved in or out of scope with the collaboration and support of the Product Owner.

Epics Aren't Required by Scrum; When Used, They Can Span Multiple Sprints

Regardless of your tool, it's important to understand that epics are a concept from "user stories," which are a way of representing and communicating about work contextually rather than as a set of detailed, fixed specifications. While user stories and epics are commonly used in agile frameworks, they are not a formal requirement of Scrum. That said, in a Scrum sense epics are a related list of Product Backlog items that may take multiple Sprints or even releases to completely deliver the features or full functionality they are meant to represent. A user story (or more formally, a Product Backlog item tied to the Sprint Goal that has been accepted for Sprint Planning) must fit within a single Sprint, but a theme or epic don't usually have the same rigor (such as INVEST) applied to them.

Your team may be conflating epics with features. Sometimes this is driven by tools, as ticketing systems like JIRA are (by definition) ticketing systems and not inherently designed for Scrum Product or Sprint Backlogs. Whether or not this is the case for you, it's worth asking the following question:

If you ship the feature(s) defined as an "epic" without fixing the known defect, have you met the Definition of Done for the epic?

If the answer is "yes," then the defect can simply be divorced from the current epic and treated as future work tied to a different epic, feature, or Sprint Goal. If the answer is "no," then the epic, feature, or story is simply not yet done, and should not be closed out until it satisfies the Definition of Done. In Scrum, as well as in other agile frameworks, work is either done or not-done; you can't treat unfinished work as "done."

On the other hand, the Developers or the Product Owner are certainly free to de-scope something that is not material to the current Sprint Goal, and the Product Owner can de-scope work that isn't needed for the current Product Goal. Whether that means deferring the work item for a future Sprint or removing it from the Product Backlog altogether is a decision for the Scrum Team to discuss together, although only the Product Owner can actually remove items from the Product Backlog.

Answer 2

What is an Epic to you, your team, and your organization?

Since there is no universally (or even widely) accepted definition of what an Epic is, there's no universally or widely accepted way for what it means for an Epic to be open or closed.

To some organizations, an Epic is a transient artifact. It's large and nebulous. Eventually, it will be broken down into smaller Stories that are valuable and the Epic will go away.

To other organizations, an Epic is a container for work. It provides a higher-level view over smaller work that a team (or teams) take on. In this case, an Epic is opened when the first unit of work under it is started and is closed after the last unit of work is finished. In this model, you may freely move work into and out of the Epic as you determine what is truly necessary to satisfy the stakeholders. An Epic may even spawn additional Epics of work for later on.

In the model for containers for work, there are even variations within that model. In some models, everything in an Epic is expected to be completed within an iteration. In other models, the work is expected to be bundled in a single release. In others, it's just a visualization and the work may be released at one or multiple points in time.

You need to understand who uses Epics and what they mean to various stakeholders to best understand how to use them to track and visualize the related work.

Answer 3

I know its tempting to close the Epic for the sake of momentum but I would suggest your backlog should reflect reality and the Epic not be closed until it is actually done.

Having open Epics with defects is also a good reminder when you create your release notes so you can easily find which defects are outstanding.