Sets
- Review the Epic Backlog
- Groom an Epic
- Review Acceptance Criteria
- Address Epic Dependencies
- Address Epic Risks
- Shift to Phase 2
- Finalize Proposed Epics List
Review the Epic Backlog
Agile Release Manager, in each release planning meeting:
- Show the group the Release Epic Backlog (list of epics proposed for the release).
- Ask if there are questions about the rank order, and negotiate consensus on the changes.
- Confirm that all epics are “must haves” for the next version of the product, and remove any from the release that are not.
Details: “ID the MRP.” - Check whether any blocked epics can be unblocked.
- If at any point during grooming, a blocker is identified:
- Mark the epic as blocked, with the reason, and if possible add an action item to clear the blocker.
- Stop grooming it and move on to the next one, unless grooming will provide information needed for an action item.
- Continue to the next set.
Groom an Epic
Release Planners:
- Open the top ungroomed and unblocked epic in the backlog.
- If the end user is not named as the user, try to find a way to make them the user, or another role as close as possible to the end user.
Tip: Ask: “What will this do for the user?”
Details: “Who is the Real User?” (the guidance is the same for epics). - Review and revise the “what” part of the epic until everyone’s questions have been answered.
Details: “What’s the Real Story?” - Review and revise the “so” statement until participants agree on the purpose.
Details: “Why Do the Story?” - Ask if the epic can be completed in one release.
- If not, break it into new, smaller epics resulting in releasable products that can be completely done in one release each.
Tip: As questions get answered, record the agreements in short bullet points (only enough information to serve as reminders). - Continue to the next set.
Details: “Epic Grooming.”
Review Acceptance Criteria
Release Planners:
- Review and revise the Acceptance Criteria until you have:
- A tangible deliverable (e.g., a working feature or documented agreements).
- Consensus it is valuable.
- Consensus it can be completed in one release.
- Approval from the requester.
- Continue to the next set.
Details: “The Power of Acceptance.”
Tips:
- For criteria common to all epics of a type, create a “Definition of Done.”
- If people want more detailed criteria, list those items in a separate “Notes” section below the AC; make the AC a summary or bottom-line statement of the deliverable.
- Prevent “solutioning” beyond the minimum the PO says the development team requires to draft stories for the epic.
Address Epic Dependencies
Release Planners:
- Ask:
- “Is this epic dependent on another of our epics?”
- “Are we dependent on anyone outside of the program to complete the epic?”
- If so:
- Add the dependency to the epic.
- Decide if the epic you’re discussing needs to be blocked.
- Ask what steps should be taken to address the dependency.
- Create an action item to do so.
- Continue to the next set.
Tips:
- Use your tracker’s link function, if it has one, to show the relationship between dependent epics.
- If equipment such as a shared machine or computer system is mentioned, convert that name into the team or person responsible for it.
Details: “Caring for Dependents.”
Address Epic Risks
Agile Release Manager:
- Ask:
- “What could go wrong that would affect our ability to complete the epic within one release?”
- “What might go wrong if we complete this epic—in other words, what could we break?”
Note: If the answer is “nothing,” skip to the next steps set.
- Add a list of possible answers (“risks”) to the epic card.
- For each complex risk:
- Ask and rate: “How much of an impact would the risk have?”
Note: Use a 0–3 scale, with 3 highest. - Using the same scale, ask and rate: “How likely is the risk?”
Note: Delete any risk with a zero for either rating. - Add together the numbers.
- For each scoring a total of at least 4, determine whether to “Avoid,” “Transfer,” “Mitigate,” or “Accept” the risk.
- Ask and rate: “How much of an impact would the risk have?”
- Determine whether any or all of these are true:
- The epic should be blocked due to the risk.
- Action items are needed to address the risk before it is committed into a release.
- Stories are needed to address the risk during the release, in which case create an action item for someone to add them to the epic.
- Continue to the next set of steps.
Details: “Projects are a Risky Business.”
Shift to Phase 2
Agile Release Manager, if POs have not been participating (if they have, skip to Step 2 in the next steps set):
- During meetings later in the current release, start asking the Review Planners if they think there are enough epics to keep the teams fully busy in the next one.
- When the answer is “Yes,” or there are four meetings remaining (whichever comes first), forward remaining meeting invitations to the Product Owners as mandatory participants.
Details: “Plan Continuously.”
Finalize Proposed Epics List
Agile Release Manager:
- Repeat the grooming steps sets above with the Product Owners for all unblocked epics, working from the top down.
- When consensus is reached that an epic is groomed, ask the POs which team or teams want to work on it.
- Mark tentative choices, and ask the POs to double-check with their teams.
- As choices are finalized, ask whether the selected epics meet the rest of the “Definition of ‘Ready’”:
- Rank order
- Story card content (statement, Acceptance Criteria, etc.)
- Size—Can be finished in one release
- Technical details are sufficient for story drafting
Tip: Print out the table in the section linked below and refer to it during grooming.
- When “yes,” mark the epic as “Ready.”
- If you are concerned about having enough epics ready by the end of the current release to keep teams busy, schedule additional meetings as needed to meet that goal.
Details: “Epic Grooming.”
Share this page