A municipal-fiber operations team spends most of its capacity on interrupt-driven outage tickets, with only a small enhancement backlog. Leadership still wants every ticket committed as a Scrum story at Iteration Planning. What should the SM/TC coach?
Select an answer to reveal the explanation.
Short Explanation
Putting fiber outages on an Iteration commitment list is like putting fire trucks on a bus timetable. Interrupt-driven work needs a Kanban-style pull with classes of service so incidents and enhancements share one visible workflow. Fake Scrum commitments just hide how the work actually arrives.
Full Explanation
When fiber or network ops teams face a mix of unplanned outages and planned enhancements, the SM/TC should coach SAFe Team Kanban with explicit classes of service so incidents and enhancements share a visible workflow instead of fake Iteration commitments. Putting outages into Iteration Planning as if they were known Sprint Goals creates theater; classes of service make urgent restoration visible without pretending the interrupt load was planned. The team stays honest about capacity residents feel as uptime.
Keeping every outage forced into Iteration Planning so the team resembles standard SAFe Scrum fails because resemblance is not fit for interrupt-driven work. Splitting incidents and enhancements onto two ARTs so unplanned work never shares capacity fails because it hides the real capacity trade-off instead of managing it. Freezing enhancements until the next PI so Scrum commitments stay clean fails because deferring all improvement for ceremonial cleanliness harms both network health and flow learning.
Exam caveat: Team Kanban with classes of service is how SAFe teams hold planned and unplanned work in one system without fake Sprint certainty. Operational check: define expedite/standard policies for outages versus enhancements, visualize both on one board with WIP limits, keep ART cadence, and stop stuffing unknown incidents into Iteration commitments.