Epic planning

Epic planning2017-10-12T22:05:27+00:00

Epic Planning Workflow

Context

Summary

Provide a summary of this practice.
This practice explains how to convert an Epic into a deliverable story.

Purpose

What is the overall goal or intention of this practice?

Epic Planning is the practice of translating an Epic into a set of manageable stories.

SLA

What are the schedule, cost, quality, frequency, performance or other expectations for completing this practice?

Epic planning may happen as part of the process of planning for any story if it cannot be realistically implemented in a single release.

Decomposing the epic into stories should be completed before the final status of the story and its allocation to an iteration or release can be agreed.

Exit conditions

What must have happened or been delivered for this practice to be considered complete?

Epic planning is complete when:

  1. The epic has been decomposed into stories and the team is confident they can:
    • estimate all the stories reliably.
    • implement all the stories within a normal story development timescale.
  2. The schedule for delivering the epic as a whole is accepted by the Product Owner.

Entry conditions

What pre-conditions must be met before this practice is used?

N/a.

Epic Planning can be applied to any story the team regards as too large or complex to estimate reliably or develop within a predictable timescale.

Outline process

This view shows a simplified version of this process. For full details, explanation and advice, click on the ‘Detailed process’ tab. For background such as entry and exit conditions, click on the ‘Context’ tab.

#StepInstructions
1Identify epic.
  1. In the current backlog, identify any Story that is too large or complex to:
    • Estimate with confidence; or
    • Implement within the expected timeframe for an individual Story.
  2. These stories are treated as epics.
2Identify user stories.
  1. Break each epic into individual user stories.
  2. Re-apply this step recursively until all stories meet the standards for Stories.
3Define user stories.
  1. Define the resulting stories, using the standard Story process.
  2. Add the new stories to backlog.
4Validate epic decomposition.
  1. Map the resulting stories back to the original epic.
  2. Confirm that:
    • The full scope of the epic has been covered.
    • All areas of the epic are defined at story level.
    • At least one end-to-end story is included that shows how the final epic works as a whole.
5Assign epic stories.
  1. Assign all the user stories associated with the original epic to iterations (or later releases).
  2. Confirm that the delivery schedule of the final story (and so of the epic as a whole) is acceptable.

Detailed process

#StepByOutputInstructionsNotes
1Identify epic.Team.

Iteration Lead.

Product Owner.

Epic list.
  1. For each Story in the current backlog, identify each story that is too large or complex to:
    • Estimate with confidence; or
    • Implement within the expected timeframe for an individual Story.
  2. These stories are treated as epics.
See here for indicators that a story may be an epic.
2Identify user stories.Team.

Iteration Lead.

Product Owner.

Updated backlog.
  1. Break each epic into individual user stories.
  2. Re-apply this step recursively until all stories meet the standards for Agile Stories.
  • Some stories are too small to be worth doing, and need to be aggregated into a larger story.
  • If it’s not clear what the epic contains, consider creating a spike.
  • An alternative to user stories is to divide the epic into features.
3Define user stories.Team.

Iteration Lead.

Product Owner.

Updated backlog.
  1. Define the resulting stories, using the standard Story process.
  2. Add the new stories to backlog.
4Validate epic decomposition.Team.

Iteration Lead.

Product Owner.

  1. Map the resulting stories back to the original epic.
  2. Confirm that:
    • The full scope of the epic has been covered.
    • All areas of the epic are defined at story level.
    • At least one end-to-end story is included that shows how the final epic works as a whole.
An epic is typically the unit in terms of which many of it stakeholders will continue to think of it – decomposing it into smaller stories is helpful to the developers, but not necessarily meaningful to the story’s owners, for example. So it is important that its overall purpose and structure be maintained. So:

  • What is the specific value of the end-to-end epic as a whole – as a complete workflow, as a complete service, and so on?
  • Is this made explicit in at least one end-to-end story (e.g., with an epic-level story that invokes lower-level user stories).
  • Are the information, decisions and materials created in one story properly passed on to the next?
  • Is the overall aim of the epic achieved?
5Assign epic stories.Product Owner.

Iteration Lead.

Team.

Updated backlog.
  1. Assign all the user stories associated with the original epic to iterations (or later releases).
  2. Confirm that the delivery schedule of the final story (and so of the epic as a whole) is acceptable.
  • As a complete epic often adds more value than the sum of its individual user stories, it may be critical to the value of the epic that it should be delivered within a specific timeframe.
  • However, an epic should be cut short if enough value has been delivered or the users’ needs or situation have changed.

Issues and risks

 

What are the key concerns in making a success of this practice?

  1. Click here for more on epics.

Leave A Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Want to do more than just build systems?