Epic Life Cycle

This document provides the metric regarding the concept of Epic Lifecycle time in Ebury.

Problem Description

As part of OKRs for the Financial Year 21/22 the Tech department wants to increase agility by reducing the time that it takes for new products, features and improvements from approval until they are available to customers. One of the ways to reach this objective is trout the Epic life cycle.

The proposed goal is to have a 90th percentile of Epic Cycle time (time that it takes for an epic to be delivered) within less than 3 months.

Background

The Epic life cycle is composed mainly of two steps.

  • The first one is the Analysis phase that will contain the features or requirements discussions with stakeholders / product team, the tech analysis to have a high level view about the requirements to know if the Epic is achievable and the correspondent RFC or 3-Point Estimation.

  • The second phase will be the Delivery phase that will correspondent form the team start working in the Epic actively developing code until the Epic is close with the corresponding monitoring plan

Considering that the Analysis phase could happen several weeks/months before the team starts working actively on it, we are not going to include this one in the Epic life cycle, moving the focus on the Delivery Phase.

An Epic will be considered opened when the first task (No spikes or analysis) is moved to the developing step.

An Epic will be considered closed when the last task is released.

To keep the quality level demanded by the tech department in any development, a warranty period will be defined. This concept consists of providing a period of time after an epic is released where any bug related to this Epic is considered as part of the Epic delivery time increasing the life cycle. The warranty period is defined as 2 sprints.

Pre-Requirements

In order to have a clean start point to automated the process, several actions need to be in place:

  • Close Old Epics.

  • Review Active Epics for all quarters in the Financial Year 21/22.

  • Define the guidelines to be aligned with the JIRA usage across teams.

  • In case that is needed, on Jira will be defined new status

Solution

Using the status changes of the tasks associated with the epic, rather than the status of the epic itself. Additionally, It's going to be excluded the issues that are not Task, Story and Bugs, as well as those issues that are marked as “epic_analysis“, just to indicate that are part of the analysis step, and not development.

Taking into account the following picture, when the first task/story or bug is moved to Developing, It's considered that the Epic is in the WIP stage, and when the last task of an epic is closed, It's considered that the Epic is Done.

img

Phase 1: Manual Process

This spreadsheet must be processed in order to maintain the data updated.

Phase 2: Automatic Process

Add to ProcessLab this functionality to pull out the report data from there, instead of the spreadsheet used on phase 1.

Alternative

Using Start Date and End Date

Use the current JIRA fields “start date” and “end date” to determine the start point and the end point through the status themself.

Phase 1: Manual Process

The correspondent team lead will change the “start date” and “end date” manually taking into account the scope considerations

Phase 2: Automatic Process

EA team will create a trigger when a task (no included tasks related to the analysis phase like Spikes or RFC) is moved to developing, the “start date” will be filled with the current timestamp and when the final task is released, It will trigger an event to fill the “end date” field with the current timestamp. If a bug is opened in the warranty period, the “end date” will be removed and be filled again with the new timestamp when the bug is fixed, extending this period of time.