Gestire le modifiche alle User story complete

Capisco che:

• hai consegnato una versione con un paio di storie utente fatte e in modo che corrisponda alla definizione di fatto.
• la tua relazione con il cliente potrebbe tuttavia essere meno interattiva e agile di quanto mi aspetterei (ad esempio, l'utente descrive le storie in modo molto dettagliato e le accetta in base a tale dettaglio, senza beneficiare dell'interazione con il team).
• una configurazione contrattuale formalizza questa relazione (prezzo fisso per storia?)
• il cliente si aspetta certamente benefici dallo sviluppo agile nonostante il gusto basato sul prezzo del design contrattuale (perché altrimenti concordare su un modello di erogazione basato sulla trama?).

Ora l'utente cambia idea. Questo è normale in un contesto agile in cui risponde al cambiamento anziché seguire ciecamente un piano .

Devi controllare cosa è previsto nel contratto. Ma a prima vista sembra una nuova storia per me: la vecchia storia è stata consegnata e accettata, e ora è prevista una nuova consegna basata su un nuovo input.

Credo che il cliente sia certamente pronto a pagare per il cambiamento (o almeno comprenderà che lui / lei deve): non esiste alcuna ragione obiettiva per cui il venditore deve sostenere il costo del cambiamento in mente del cliente .

Tuttavia, il cliente non accetterà certamente di pagare di più del costo incrementale e presumerà che riutilizzerai le parti vecchie che sono riutilizzabili. Quindi, se non è previsto nulla nel contratto, la difficoltà è di valutare la SP tenendo conto che si tratta di un cambiamento e non di una funzionalità totalmente nuova sviluppata da zero. Per evitare ambiguità, potrebbe aiutare il fatto che la storia rivista si riferisca alla funzione già implementata (vale a dire, ciò che deve essere cambiato, invece di descrivere la storia completa come se fosse totalmente nuova).