La Changeability è un attributo di qualità dei requisiti enfatizzato in alcune pubblicazioni classiche. Per ottenere la variabilità dei requisiti, non devono essere ridondanti.
Tuttavia, quando si gestiscono i requisiti in Scrum, alcune pratiche porteranno inevitabilmente a storie utente ridondanti. Ad esempio, se un software deve avere caratteristiche numeriche simili dal punto di vista tecnico, ma l'utente ha un percorso diverso nell'interfaccia utente per ciascuna caratteristica: per mantenere le storie piccole (INVEST), vorrei creare storie diverse che sono solo leggermente diversi, o forse addirittura uguali solo con diversi criteri di accettazione. Ora, quando cambiano i requisiti aziendali, devo assicurarmi di aggiornare di conseguenza tutte le storie ridondanti.
Normalmente, questo sarebbe gestibile. Dopotutto, non ci dovrebbe essere un gran numero di storie aperte, ma quanto basta per riempire un piccolo numero di sprint imminenti. In pratica ("Scrum, ma ..."), i clienti possono insistere sulla suddivisione di un gran numero di requisiti per la planabilità. Ma anche Scrum su larga scala può portare a una situazione in cui ci sono molte storie aperte.
È possibile gestire un lungo elenco di storie aperte senza perdere i vantaggi di Scrum?