Esistono diversi modi per gestire le prestazioni (e, in realtà, tutti i requisiti non funzionali).
Se il requisito è noto all'inizio dello sviluppo, rendilo parte dei tuoi criteri di accettazione o Definizione di Fatto e assicurati che rimanga lì. Se si dispone di un requisito di prestazioni specifico, sviluppare test (preferibilmente test automatizzati) per garantire che si stia raggiungendo le metriche di prestazione. Se è un requisito di affidabilità specifico, sviluppare alcuni test che è possibile eseguire su un normale è più difficile farlo perché è più difficile testarli in modo automatico. Ad esempio, i requisiti di usabilità che stabiliscono una particolare classe utente devono essere in grado di eseguire una funzione in un determinato periodo di tempo. I requisiti di testabilità e modificabilità sono anche più difficili da testare, ma possono essere analizzati.
Se stai apportando una modifica al sistema, trattalo come una storia utente. Questo è perfettamente valido per le nuove storie e per le istanze in cui è stata fornita la funzionalità, ma deve essere migliorata. "Come {user class}, voglio {function} in {time}" è una storia utente valida, così come storie simili. È importante rendere le tue esigenze specifiche e misurabili, in modo che tu sappia quando le hai raggiunte. Puoi dare loro la priorità nel backlog del prodotto, valutarli e inserirli nell'iterazione come qualsiasi altra storia.
Una volta implementato, puoi condividere i risultati dei tuoi test alla Sprint Demo, proprio come qualsiasi altra storia. Se le tue esigenze sono più difficili da dimostrare (ad esempio, determinati tempi di attività), puoi utilizzare i risultati del test. Altri attributi possono essere dimostrati, usando il software o gli script che possono guidare la funzionalità.
Se è necessario, puoi utilizzare uno Spike per affrontare queste storie o requisiti. Se hai bisogno di fare prima la ricerca, allora l'avvio di un Spike timebox è la cosa giusta da fare. Ciò è utile quando non si sa se è possibile raggiungere un particolare requisito o se le informazioni da valutare e implementare sono insufficienti. In realtà non è possibile risolvere il problema in Spike, ma puoi almeno impegnarti a comprendere il problema dopo un certo periodo di tempo e avere una conversazione con lo stakeholder.