La documentazione è una User Story? [chiuso]

Dobbiamo fare della documentazione per l'utente per un prodotto su cui abbiamo lavorato negli ultimi sprint. Ora stiamo iniziando un nuovo progetto nel prossimo sprint e l'OP sta realizzando la documentazione per il prodotto precedentemente prodotto come User story per questo sprint.

Mi sto solo chiedendo la tua opinione su questo approccio. Personalmente, non sono d'accordo sul fatto che la documentazione sia una User Story all'interno di Scrum perché non produce alcun codice.

EDIT: Grazie per le vostre opinioni ragazzi. Avevo pensato che uno sprint consistesse nell'implementare un incremento del software funzionante, ma le tue opinioni hanno cambiato la mia prospettiva. Grazie per tutte le tue risposte.

"Come utente di X, ho bisogno di sapere come funziona X" mi sembra una storia utente legittima. Ciò potrebbe comportare documentazione scritta o guida in linea.

Il punto non è solo il codice, ma soddisfa i requisiti degli utenti.

Idealmente, la documentazione fa parte di ogni user story e non si accumula mai. Ma, nel mondo reale, ciò spesso non accade. In tal caso, è necessario creare una user story per recuperare uno specifico documento mancante.

Hai ragione, non produce alcun codice. Ma soddisfa un requisito dell'utente e dovrebbe essere prioritario rispetto ad altri requisiti dell'utente.

Se questo significa che non viene mai fatto, perché questa e quella funzionalità sono in fase di elaborazione, probabilmente non hai bisogno della documentazione così male.

Concordo con la valutazione della documentazione di pdr se si tratta di requisiti, documentazione tecnica o di progetto. Idealmente dovrebbe essere incorporato nel lavoro di sprint.

Ritengo che la documentazione del prodotto sia molto diversa in quanto si tratta di un prodotto effettivo richiesto e fornisce direttamente valore all'utente. Ciò dovrebbe ovviamente comprendere che la Documentazione del prodotto non è essenzialmente un'attività tecnica ma un'attività funzionale e può o meno essere un'attività adatta per una risorsa tecnica sul progetto.

Penso che dovrebbe essere una storia utente, tuttavia ritengo che a queste attività dovrebbe essere assegnata una risorsa di progetto che abbia una solida comprensione dei requisiti aziendali, della prospettiva dell'utente e di buone capacità tecniche di scrittura. Idealmente, questo sarebbe un analista aziendale se disponibile, o forse un tester QA di ordine superiore con una solida conoscenza dei requisiti, delle storie degli utenti e buone capacità di scrittura tecnica. Questo potrebbe anche essere uno sviluppatore, tuttavia la documentazione del prodotto scritta dagli sviluppatori tende a non essere di alta qualità o utile poiché gli sviluppatori di solito sono troppo vicini ai dettagli tecnici.

Nella nostra organizzazione, il team di strumenti, incaricato di mantenere e migliorare il nostro sistema di integrazione continua, utilizza Scrum per aiutarli a gestire il loro lavoro. Non stanno scrivendo codice ma stanno comunque praticando Scrum.

Per rispondere in modo specifico alla tua domanda, vorrei chiedere se il team ritiene che la documentazione faccia parte o meno della "Definizione del fatto".

Se il team ritiene che la documentazione sia parte della "definizione di fatto", non è necessario aggiungere una storia aggiuntiva e la storia non può essere accettata se la documentazione non è scritta e convalidata.

Se il team ritiene che la documentazione non faccia parte della "definizione di fatto", creerei una storia separata in modo che il Product Owner possa gestire il proprio lavoro.