Scrum: chiarimenti sui requisiti rispetto al cambiamento dell'ambito [duplicato]

Question

Scrum: chiarimenti sui requisiti rispetto al cambiamento dell'ambito [duplicato]

#1 da (8 voti)
#2 da (2 voti)
#3 da (0 voti)

5

Quindi stimiamo la storia e mettiamo i compiti alla lavagna. Quindi durante lo Sprint, il ragazzo UX presenta un'esperienza utente per la storia che è più complicata di quanto inizialmente pensavamo. Quindi, da un lato, vogliamo implementare la funzionalità giusta per l'utente, dall'altro, se avessimo saputo della complessità dell'UX durante la pianificazione di Sprint, probabilmente non ci saremmo mai impegnati nella storia.

Quindi cosa fare in casi come questo?

La stessa domanda si applica ai casi in cui un test di usabilità o un feedback degli utenti durante lo Sprint ci mostra che dovremmo cambiare la funzionalità.

In generale, dove traccia la linea tra chiarimento dei requisiti o adattamenti e il cambiamento di scopo?

scrum

posta Eugene 16.02.2014 - 17:49

fonte

3 risposte

Leggi altre domande sui tag scrum

A cosa si riferisce "estremo" in "programmazione estrema" (XP)? Va bene avere molte dipendenze in una classe che solo delega funziona?

score 8 · Answer 1

Bene, la prima cosa che emerge è che lo sforzo UX dovrebbe far parte della stima del tuo story point.

Ma a parte questo punto, quando ho avuto a che fare con una storia che non era quella che sembrava originaria, di solito faccio le seguenti domande:

La nuova versione della storia invalida la stima della complessità?
- Se sì, tira la storia dallo sprint.
- In caso contrario, potresti ancora essere in grado di fornire la nuova versione.
Può essere scomposto in storie più piccole (almeno una delle quali sarà consegnata in questo sprint)?
- Se sì, puoi provare a fornire lo stesso numero di punti storia senza consegnare l'intera serie di storie.
- In caso contrario, tira la storia dallo sprint.
La nuova versione della storia invalida lo sprint?
- Con questo intendo "l'obiettivo dello sprint è cambiato?" In tal caso, annulla lo sprint.

Normalmente questo è un compromesso accettabile dato che l'ordine di acquisto continua a ricevere alcuni del valore aziendale promesso e in realtà non stai introducendo il creep dell'ambito nello sprint.

score 2 · Answer 2

Alla fine della giornata, UX è parte della storia e, come sottolinea MetaFight, la tua persona UX dovrebbe essere coinvolta nella stima.

Detto questo, non ti preoccupare troppo. Se questo tipo di sorprese è un evento normale, la tua velocità lo renderà automaticamente conto.

Se ciò è insolito, il proprietario della tua azienda dovrebbe essere messo a conoscenza e dovrebbe essere a posto lasciando cadere le storie con priorità inferiore (che possono o meno includere questo) da questo sprint. Se non lo sono, hai un altro problema.

score 0 · Answer 3

Mi piace molto la risposta di MetaFight, solo un'aggiunta, se è normale che in ogni sprint ci siano storie con enormi cambiamenti di complessità durante lo sprint (e forse costringendoti a interrompere lo sprint!), questo è qualcosa di importante per discutere nella retrospettiva.

È molto importante trovare le cause principali, forse è necessaria una maggiore collaborazione delle persone UX nella definizione della cronologia iniziale ?, forse hai bisogno di storie più piccole ?, non lo so, ma probabilmente il tuo team ha una risposta migliore di StackOverflow .