Sets
- Review the Release Backlog
- Groom an Epic
- Review Acceptance Criteria
- Address Epic Dependencies
- Address Epic Risks
- Shift to Phase 2
- Finalize Proposed Epics List
Review the Release Backlog
Agile Release Manager, in each release planning meeting:
- Show the group the Release 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 (until the last release for that version, when you can fill remaining capacity with “nice to have” epics).
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 TG 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 step set.
- Add a list of possible answers (“risks”) to the epic card.
- For each risk that seems significant:
- 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 TGs have not been participating (if they have, skip to Step 2 in the next step 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 Team Guides as mandatory participants.
Details: “Plan Continuously.”
Finalize Proposed Epics List
Agile Release Manager:
- Repeat the grooming step sets above with the Team Guides for all unblocked epics, working from the top down.
- When consensus is reached that an epic is groomed, ask the TGs which team or teams want to work on it.
- Mark tentative choices, and ask the TGs 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.”