Come gestisci una richiesta di cambio dello scope a metà Sprint?

Question

Accepted Answer

L'impostazione predefinita in Scrum è **proteggere lo Sprint Goal**: nessun cambiamento dovrebbe essere aggiunto che lo metta in pericolo. Ma Scrum non è rigido — lo scope può essere *rinegoziato con il Product Owner*, e un cambiamento veramente urgente può essere gestito, con trade-off resi espliciti.

## Perché è importante

```text
1. Does the new request threaten the Sprint Goal?
     NO  → can it wait for the next Sprint? Usually yes → backlog it.
     YES → talk to the Product Owner about trade-offs.
2. Is it a genuine emergency (prod down, legal, security)?
     YES → the PO may cancel/replace work; something must drop.
3. Make the trade-off visible: pulling X in means Y comes out.
```

## Esempio concreto

A metà Sprint, il reparto vendite vuole un "piccolo" nuovo report. Lo Scrum Master aiuta il team e il Product Owner a comprendere che non è urgente, quindi va in cima al backlog del prossimo Sprint invece di disturbare l'obiettivo attuale.

## Insidie comuni

- Assorbire silenziosamente lavoro extra, compromettendo lo Sprint Goal e nascondendolo.
- Dire un secco "no" senza un percorso — il Product Owner può sempre rinegoziare.
- Lasciare che ogni stakeholder inietti lavoro direttamente, bypassando il Product Owner.

## Perché è importante

Protéggere lo Sprint Goal è ciò che rende Scrum prevedibile; l'iniezione costante trasforma gli Sprint in liste di cose da fare caotiche.

Gestire il cambiamento attraverso il Product Owner con trade-off espliciti mantiene il team focalizzato rimanendo reattivi alle vere emergenze.