ELM - Step 5 of 6: Implementing

The fifth of six (5 of 6) steps in Epic Lifecycle Management identifies Solution Epics currently authorized for change.  When combined with Epics in the 'Portfolio Backlog', these form a current Epic Map.

An Epic Map allows stakeholders to view all, or a portion, of the Solution Portfolio.  Through each Epic's relationship attributes, stakeholders can quickly identify Business Segments, processes, enablers, or any other enterprise Content for which change is occurring.  Indeed, stakeholders can map any Business Perspective or Technology Perspective Content.  Moreover, this state indicates change to such Content may occur in a current Solution Phase.

In fact, the TMO should maintain a current Epic Map for use during Portfolio Tasks.  It provides a quick reference of whether a new or an existing Epic is appropriate to fulfill a Request for Change.

Epic Lifecycle - Step 5 of 6: Implementing

On This Page
    Add a header to begin generating the table of contents
    Epic Lifecycle - Step 5 of 6

    What's Before

    During ELM - Step 4 of 6: Portfolio Backlog, the TMO replaced any placeholder Portfolio Epic with one or more Solution Epics.  Additionally,  Architects created, or updated, the Solution's Strategy & Architecture materials for the pending Solution Phase.

    When applicable, Teams updated the Process Definition for any process in-scope for the pending Solution Phase.  Using these inputs, participants conducted a Phase Inception during which Solution Definition concluded, and Solution Delivery began.

    What's Happening Now

    At this point, a Solution Phase is in progress.  Each Solution Epic approved for work during this Phase appears in this state.  Overall, the Epic Map summarizes where potential change may occur.

    While here Features and Stories which relate to the Epic may appear in Releases and Sprints.  Of course, there is no requirement that work which relates to an active Epic must occur in every Sprint or Release.  However, any work which does relate to an active Epic, if and when a Solution Owner prioritizes it, requires no additional approval.

    Scope Management

    Significantly, an Epic's scope and objectives should not change during Solution Delivery.  Rather, changes to an Epic's definition only occur during Solution Definition.  Adhering to the defined objectives is an important means to manage scope.  Allowing an Epic's objectives to change during delivery removes the Epic's scope management function.  If a change is warranted, then begin a new Phase, with an updated Solution Definition.  This approach helps maintain control over the Epic Map, an important consideration in managing the overall Portfolio.

    Epics may stay in this state as long as there is approval for more work.  Specifically, by appearing in this state, there is:

    • A desire for additional change.
    • Funding for such change; and
    • Other resources available to affect such change.

    As long as these conditions exist, an Epic may remain active from one Solution Phase to the next.

    Conversely, an Epic may regress back to Portfolio Backlog when it is not in-scope for a Phase.  To clarify, prior to each new Phase, leadership may (or may not) approve change for certain Epics.  Those without approval, return to the backlog.  To be sure, an Epic is still active within the Portfolio.  However, there is no authorization for change at this time.  Backlog Epics may return to this state any time a new Solution Phase involves more work on the Epic.  Accordingly, these shifts allow the Epic Map to convey areas where change may, and may not, occur at any given time.

    Shifting States

    A Solution Epic may shift back and forth between 'Implementing' and 'Portfolio Backlog' states.  In both states, the Epic represents current functionality, supporting some operations, for designated Business Segments.  During a Phase when there is approval for work on the Epic, it appears in the 'Implementing' column.  When there is no approval for work, yet the Epic is still an active part of the Solution, the Epic regresses back to 'Portfolio Backlog'. In that case, an Epic is currently out-of-scope.  That is, the organization is choosing not to expend any additional resources on the Epic, for the time being.

    In due time, the Solution to which the Epic relates is retired.  At that point, the Epic will progress to 'Retired'.  Alternatively, it is possible for the Solution to remain active, while something else replaces the functionality and Business Segment the Epic represents.  Similarly, it is possible to discontinue, rather than replace, the functionality.  In these cases, again the organization 'Retires' the Epic, even though the corresponding Solution remains active.  'Retire' indicates the organization chooses not to expend any more resources upon the Epic, ever again.

    Step-by-Step

    To Gain this State

    While in this State

    To Attain the Next State

    • The TMO will progress a Solution Epic to this state whenever there is approval for change which relates to the Epic during a current Solution Phase.  In other words, the Epic is in-scope, and the organization approves expending resources to achieve the Epic's objectives.

    ______________________________

    • Although unusual, a Solution Epic may regress to this state.  In that case, a previously 'Retired' Solution would need to un-retire, and additional work on the Epic would require approval.
    • A Solution Phase is in progress.
    • The organization approves resources to achieve the Epic's objectives during the Phase.  That is, changes to the Epic are in scope.
    • Features and Stories related to the Epic may appear in Releases and Sprints.
    • The Epic's scope and objectives may not change until definition of a subsequent Solution Phase.  This helps minimize uncontrolled change to the Epic Map.
    • At some point, an organization will decide not to expend any further resources on the Epic.  Thereafter, the Epic will progress on to 'Retire'.

    ______________________________

    • If the Epic remains active, yet there is no current approval for change, then a Solution Epic may regress to 'Portfolio Backlog'.

    Participation & Updates to the WMS

    In general, Epics on this board summarize the progress of a Customer Request for Change to Sponsors, Epic Owners and other stakeholders.  Indeed, these steps do not manage work.  Rather, Solution leadership becomes responsible to plan and implement any change.  Accordingly, there is rarely additional work here, beyond that which updates to the WMS as follows.

    Initially, the TMO will move the Solution Epic from 'Portfolio Backlog' to 'Implementing' when they progress the related Feature (Request) from 'Inception' to 'Done'.  Thereafter, the TMO will move a Solution Epic from 'Portfolio Backlog' to 'Implementing' any time Phase Inception places the Epic in-scope for the long-term period.  This minor shifting allows for flexibility in the Epic Map, while maintaining consistency within the Portfolio.

    What's Next

    At the end of a Solution Phase, an Epic may return to 'Portfolio Backlog' if there is no approval for further work on it during the next Phase.

    Similarly, if there is no pending or active Solution Phase, then all Solution Epics return to 'Portfolio Backlog'.  This indicates the Epic is still active.  However, the organization is not currently approving expenditures upon achieving additional Epic objectives.

     

    Eventually, the organization will choose to either replace or remove the defined functionality for the designated Business Segment(s).  As a result, the TMO will progress a Solution Epic from this state on to retirement.

    At that time, proceed to the next step, ELM - Step 6 of 6: Retire.

    Scroll to Top