SHIFT Agile Framework

1. Define your ACN clearly. Write the capability domain in a single sentence. If it takes two sentences, the scope is too broad. Everything else depends on this agreement.
2. Score your backlog with SEMI. Take the top 15 to 20 items and score them using the four dimensions. Do not aim for precision in the first round — aim for surfacing disagreement. When two people give the same item very different scores, that conversation needs to happen before work begins.
3. Start tracking throughput from sprint one. Count the number of items marked Done at the end of each sprint. Not story points, not hours — items completed and meeting acceptance criteria. Eight sprints of throughput data will transform your planning conversations.

Everything else — IIS, DOI, LGP, Monte Carlo — layers on top of these three. Teams that skip the foundation and go straight to the advanced mechanisms fail consistently.

1. Replace standup format. Move to three signals: a progress signal against a measurable criterion, an AI workflow note (even if it is 'no AI involvement today'), and a blocker flag. Blockers are addressed after standup, not during it.
2. Add SEMI scoring to refinement. Before any item enters the sprint, it gets a SEMI score. Items scoring 9 or above do not enter the sprint. Items scoring 7 to 8 enter only with a named mitigation on the highest-risk dimension.
3. Replace your retrospective with the 3-track structure. Track 1: delivery system. Track 2: collaboration and AI. Track 3: learning and growth. Do not combine tracks or skip one.

IIS, DOI, LGP, and Monte Carlo are introduced in subsequent sprints per the phased adoption plan in Chapter 21. Do not add them in sprint 1.

1. Roles: one person combines Anchor and Governance Steward. One person combines Delivery Lead and primary Contributor. One person is a contributor.
2. Ceremonies: AI-first standup, Spec Review at sprint start, Sprint Review, 3-track Retrospective. Drop IIS (suspend below 4 people), drop LGP (replace with a weekly 30-minute alignment meeting with one external stakeholder), drop the formal Cycle Portfolio Review.
3. Metrics: throughput and SEMI scoring. Skip Monte Carlo until sprint 8.
4. DOI: one or two cycle objectives with sprint contributions tagged Green, Amber, or Red. Review at the mid-sprint check.

1. Sprints 1-2: process friction increases temporarily. Teams naming spec gaps they previously ignored. Standup taking slightly longer. SEMI scores causing disagreements. This is the framework surfacing problems that already existed invisibly.
2. Sprints 3-4: SEMI calibration stabilises. Mid-sprint surprises decrease noticeably. Planning conversations become shorter and more honest.
3. Sprint 6-8: throughput data becomes reliable enough to use for planning. The first Cycle Portfolio Review is when most teams feel the framework operating at altitude.
4. Cycle 2 onwards: IIS begins producing Learning Cards worth promoting. Monte Carlo forecasts carry credibility. DOI health scores give the team and leadership a shared, objective view of alignment.

The failure mode to avoid: abandoning SHIFT in sprint 2 or 3 because it feels like overhead. Teams that stay with it past sprint 4 uniformly report that the overhead inverts into a net reduction in wasted coordination time.

1. Yes, with a clear separation of purpose. Use story points exclusively for external reporting or contractual commitments where they are required. Use SEMI and throughput for internal planning, sprint readiness, and forecasting. Do not mix them in the same conversation.
2. The practical approach: score SEMI, track throughput, run Monte Carlo from throughput data. If someone external asks for a story point count, derive it from throughput after the sprint using your historical average points per item.

Warn your team explicitly: SEMI scores and story points answer different questions. SEMI answers 'is this item ready and how complex is it?' Story points attempt to answer 'how much effort will this take?' Conflating them is the most common estimation failure in Agile teams.

1. Throughput (items per sprint): count of work items moved to Done per sprint that meet all acceptance criteria, passed their review step, and are deployed to at least staging. Record as a single number per sprint. Build a rolling 10-sprint dataset.
2. SEMI Score (4-12 per item): score every item at sprint entry. Log the four individual dimension scores, not just the composite. After each sprint, review which dimension scores were wrong. This calibration is how SEMI improves over time.
3. DOI Health Score (0-100): track at sprint start, mid-sprint, and sprint end. Formula: (Green Sprint Contributions ÷ Total Sprint Contributions) × 100. Record the score and the trend — trend matters more than any single score.
4. IIS Capacity (%): track at sprint planning. Record whether IIS ran, what theme was explored, how many Learning Cards were produced, and whether any were promoted.
5. Monte Carlo P70/P85: from sprint 8 onwards, for any active work thread with more than three items remaining. Record the P70 date (internal planning) and P85 date (stakeholder commitment).

1. At sprint planning, tag every sprint backlog item against a Cycle Objective as Green, Amber, or Red. Most will be Green at planning.
2. Update tags at the mid-sprint check (Day 6-7) and at sprint end.
3. Formula: DOI Health Score = (count of Green Sprint Contributions ÷ total Sprint Contributions) × 100.
4. Example: 12 Sprint Contributions. At mid-sprint: 8 Green, 3 Amber, 1 Red. Score = (8 ÷ 12) × 100 = 67 — Moderate. The 1 Red item triggers the Red Item Protocol immediately.

The common mistake: teams tag items Green at planning and never update them. A DOI Health Score of 100 at sprint end that was not updated mid-sprint is a fiction. The value of DOI is the mid-sprint signal.

1. Manual approach (early sprints): record throughput per sprint in a spreadsheet. Use a random number generator to sample throughput values from your historical data. Repeat 500 times. The percentage of simulations completing within each timeframe gives you probability bands.
2. Spreadsheet approach: use RANDBETWEEN or random sample formulas, set up 1,000 simulation rows. P50, P70, P85, and P95 emerge from the distribution. Free templates for this are easy to adapt.
3. ActionableAgile Analytics (actionableagile.com): the recommended tool for SHIFT teams. Connects directly to Jira and Azure DevOps, produces Monte Carlo 'How Many' and 'When' simulations out of the box.
4. Nave (nave.app): similar capability, strong Jira integration.
5. Azure DevOps Analytics: built-in throughput and cycle time reports. Monte Carlo requires a third-party extension (ActionableAgile for ADO) or a connected spreadsheet.

Minimum viable setup: a shared spreadsheet with one row per sprint and one column for items completed. Five minutes to maintain per sprint, provides everything needed for manual P70/P85 calculations.

1. SEMI score distribution at sprint entry: a sprint where 40% of items entered Amber or Red is a leading indicator of mid-sprint blockers and incomplete work at sprint end. Check this at Spec Review, before delivery begins.
2. Amber item age in the DOI map: an Amber item on Day 3 that has not moved to Green by Day 5 will almost certainly become Red. Track Amber item age daily.
3. Throughput trend (last 3 sprints): a declining trend across three consecutive sprints is a leading indicator of a systemic delivery problem. A single low-throughput sprint is noise. Three consecutive is a signal.
4. IIS Learning Card signals: a cycle where all IIS Learning Cards are Neutral or Negative is a leading indicator that themes are poorly chosen or IIS capacity is too low.
5. Spec Review duration: if it consistently runs over 45 minutes, items are arriving at sprint planning underspecified. Spec Review duration is a leading indicator of sprint predictability.

1. SEMI Score fields: add a custom Number field named 'SEMI Score' (range 1-12) and four sub-fields S, E, M, I (range 1-3 each). Display them on the issue create and edit screens. This is the single most impactful change — it forces SEMI scoring at issue creation, not as a separate process.
2. DOI Status field: add a custom Single-select field with options Green, Amber, Red, and Not Tagged. Display it on the sprint board card face. Create a Jira dashboard gadget filtered by sprint showing counts of each status.
3. IIS work: create a dedicated Epic named 'IIS [Cycle Number]' or use a label 'IIS' on all innovation sprint issues. This separates IIS throughput from delivery throughput in your Monte Carlo baseline.
4. Throughput tracking: use the Jira Velocity Chart in Issue Count mode, not Story Points. Export this data to a spreadsheet every sprint end and maintain a rolling 10-sprint throughput dataset.
5. ActionableAgile for Jira: install from the Atlassian Marketplace. Adds Monte Carlo simulator, throughput run chart, cycle time scatterplot, and WIP ageing directly inside Jira. Recommended from sprint 8 onwards.
6. Node Health Card: maintain as a Confluence page linked from the Jira project. Update the four fields (throughput trend, DOI Health Score, IIS status, open dependencies) at sprint end.

1. SEMI Score fields: in Process customisation (Organisation Settings > Boards > Process), add custom integer fields to your work item type — 'SEMI Score' plus 'S-Score', 'E-Score', 'M-Score', 'I-Score'. Add them to the work item form under a 'SHIFT' section.
2. DOI Status field: add a custom picklist field named 'DOI Status' with values Green, Amber, Red, Not Tagged. Create a query in Azure Boards grouping by DOI Status filtered to the current sprint. Pin this as a dashboard widget.
3. IIS work items: use a tag 'IIS' or a dedicated Area Path/Feature named 'IIS'. Use this to produce a separate throughput chart for IIS items, keeping it out of your delivery baseline.
4. Throughput tracking: navigate to Boards > Analytics > Throughput. Switch granularity to Sprint, set window to last 10 sprints. Export to Excel for your Monte Carlo spreadsheet.
5. Monte Carlo in ADO: use ActionableAgile for Azure DevOps, Nave, or export throughput data to an Excel Monte Carlo template.
6. LGP pre-read and Node Health Card: use Azure DevOps Wiki. Create a wiki page per ACN with a standard template, linked from the team dashboard. The Governance Steward updates the decision log as a separate wiki page after each LGP session.

1. SEMI scoring: add four custom properties to your issue type — S, E, M, I as number fields (1-3), plus a computed SEMI Score. Linear supports custom properties natively. Add these to your issue template so they are prompted at creation.
2. DOI Status: add a custom select property (Green, Amber, Red). Use Linear's filter and grouping to view DOI distribution across active cycle issues.
3. Throughput tracking: Linear's built-in cycle analytics show issue completion counts per cycle. Export to a spreadsheet for Monte Carlo inputs.
4. IIS work: use a dedicated Label ('IIS') or a separate Linear project for IIS work within each cycle.
5. Monte Carlo: Linear has no native Monte Carlo tool. Export throughput data and use ActionableAgile (which supports CSV import) or a spreadsheet template.

Linear is well-suited to teams of 3 to 7 people. For teams above 7 to 8 people or multi-node coordination, Jira or ADO is the better choice.

1. Minimum viable toolset: a shared spreadsheet with two tabs — (1) Sprint throughput log, one row per sprint; (2) SEMI backlog, listing each item with S, E, M, I scores and composite.
2. A shared document (Google Docs, Notion, or Confluence) per sprint for the Sprint DOI Map, tagged Green/Amber/Red, updated mid-sprint.
3. A shared document per ACN for the Node Health Card (updated each sprint end) and per IIS sprint for Learning Cards.
4. Notion: good for documentation artefacts (Node Health Cards, Learning Cards, Pattern Library, AI Responsibility Map, LGP pre-reads and decision log). Weak for sprint tracking and throughput analytics. Use Notion for documentation alongside a dedicated board tool for sprint management.
5. Trello: usable for 3 to 5 person teams. Add SEMI Score as a custom field on cards, DOI Status as a label, IIS as a separate list. Not recommended above 5 people.

The tool matters far less than the discipline of updating it. A team that maintains a clean shared spreadsheet will get more value from SHIFT than a team that configures a full Jira setup and never updates the DOI Status field.

1. In teams of 5 or fewer people, yes, with caution. Two conditions must be met: (1) the LGP pre-read is compiled and distributed 24 hours in advance without exception, and (2) the decision log is maintained and visible to all ACNs.
2. If either condition is not being met consistently, the Governance Steward function is being neglected and must be given to someone else.
3. The risk: the Delivery Lead's primary loyalty is to sprint delivery. When the two roles conflict, governance gets deprioritised. The most common failure mode is the LGP pre-read arriving the morning of the session — participants have no context and the session becomes a status report.

In teams above 5 people, do not combine these roles. The authority concentration creates a single point of failure for both operations and governance.

1. Rotating the Delivery Lead is encouraged. Rotating the Anchor is not recommended for ACNs in active delivery.
2. The Anchor role requires deep familiarity with the capability domain's history, decisions made, trade-offs accepted, and strategic direction. This context cannot be effectively transferred in a single handover session.
3. The appropriate version of role development: a future Anchor candidate shadows the current Anchor for a full cycle, participates in LGP sessions, and takes on specific Anchor accountabilities before formally rotating in. This is a development pathway, not a rotation schedule.

1. This is a governance issue, not a personality issue. Resolve it at the LGP, not informally.
2. Persistent disagreement usually means either the capability domain is not clearly enough defined (both roles are working from different mental models of what the ACN owns), or sprint capacity is being managed without shared understanding.
3. Resolution path: bring the specific disagreement to the LGP as an Unblock item. The Governance Steward facilitates a decision that documents the explicit scope and capacity boundary.

Once the boundary is written down and ratified, the disagreement usually resolves because both parties are now working from the same explicit constraint rather than implicit assumptions.

1. Yes, and this is one of the most common adoption patterns. The Anchor participates in SAFe's PO Sync and ART events as the team's representative. PI objectives map directly to SHIFT Cycle Objectives. The DOI map is maintained internally.
2. The team uses SEMI scoring internally and derives story point counts from historical throughput averages for external PI Planning reporting. These roles are kept cleanly separate.
3. The LGP operates entirely internally. SAFe's ART Sync serves as the external governance input; the LGP handles internal cross-node decisions.
4. After two or three cycles of demonstrably better throughput predictability, the evidence base for expanding SHIFT to other teams is significantly stronger.

Risk: SAFe PI Planning items arrive without SEMI scores. Introduce a Spec Review session immediately after PI Planning to score incoming PI objectives before they enter the sprint backlog.

1. DOI is not a replacement for OKRs. It is the connection between your OKR system and sprint work.
2. Mapping: Company OKRs → Alignment layer input. Team OKR (or the Key Result your team owns) → Cycle Objective in the DOI map. Sprint Contributions → the specific deliverables each sprint is committing to in service of that Key Result. DOI Health Score → mid-cycle, sprint-by-sprint view of whether delivery is contributing to the Key Result as planned.
3. What SHIFT adds that OKRs alone do not: a continuous, sprint-level signal of whether execution matches intent, surfaced during the sprint when it can still be corrected — not at quarter end when it cannot.

1. Most stakeholders do not need to understand Monte Carlo. They need a confident, honest answer to 'when will it be done?'
2. Communication formula: 'Based on our delivery data from the last N sprints, we have 85% confidence this will be complete by [date]. Our most likely completion, based on current throughput, is [earlier date].'
3. This gives two numbers: a planning date (P85, for roadmap commitments) and an optimistic date (P50 or P70, the team's working target).
4. For stakeholders who push back on probabilistic language: 'It is the same logic as a weather forecast. We are saying that based on our actual delivery patterns, 85 times out of 100 it would be done by then. We will give you a heads-up the moment we see signals that put that date at risk.'

1. Failure mode 1: introducing too much at once. Teams attempt to run IIS, DOI, LGP, Monte Carlo, SEMI, AI-first standup, and 3-track retrospective in sprint 1. The cognitive overhead is too high. Sprint 1 becomes a meta-conversation about SHIFT instead of a delivery sprint. Follow the phased adoption plan strictly.
2. Failure mode 2: SEMI scoring without honest disagreement. Teams go through the motions of scoring but socially align on scores rather than surfacing real disagreement. When two people give the same item S=1 and S=3, explore why — do not average. The value of SEMI is in the forced clarification. If SEMI scores are not causing any disagreement, the scoring is being done dishonestly.
3. Failure mode 3: LGP pre-read not enforced. The pre-read is not ready, the session goes ahead anyway as a verbal status update, and the pattern sets in. Once LGP becomes a status report forum, it is very difficult to recover without an explicit reset. The Governance Steward must enforce the pre-read rule from the very first session. If it is not ready, postpone the session — do not hold it without it.