Scrum newbie: storie interne

La risposta breve è "No, there should be no stories created for tasks which deal with managing the SCRUM process itself" .

Le User Story servono esclusivamente a descrivere le funzioni orientate all'utente (o anche "orientate al proprietario") che saranno implementate nel prodotto.
Penso che il motivo principale per cui non si mischiano questi compiti con meta compiti (come creare storie di utenti, valutarli ecc.) È che i meta task implicano in genere una particolare sequenza relativa ad altre attività , in cui le storie degli utenti possono essere implementato in qualsiasi ordine, nel primo sprint o nell'ultimo. Certamente, il modo in cui le storie sono valutate e le priorità del Team e del Product Master influenzano l'ordine in cui sono introdotte nel prodotto, ma idealmente sono indipendenti l'uno dall'altro e quindi intercambiabili rispetto alla pianificazione .

Spesso è abbastanza difficile selezionare un buon set di storie per uno sprint dato senza aggiungere ulteriore confusione con le meta-attività.

Le attività Meta (come la creazione di storie, la pianificazione di uno Sprint, la pianificazione di SCRUM giornalieri e varie attività amministrative) fanno quindi parte del processo SCRUM. Sono integrati nel framework e non sono tracciati esplicitamente.

Per ottenere requisiti e scrivere storie di utenti non sono attività . Sono un lavoro a tempo pieno. Il lavoro product owner .

Quello che descrivi nella tua domanda è "Iterazione 0" quando vengono scoperti i requisiti e vengono scritte le storie degli utenti. Quindi il team va al lavoro e li implementa in Iterations da 1 a N.

Ma la scoperta dei requisiti non si ferma mai. Il proprietario del prodotto può in qualsiasi momento aggiungere o eliminare requisiti, unire o suddividere le storie degli utenti e riordinarle di nuovo. Ecco come agile pianificazione adattiva ("risposta al cambiamento dopo aver seguito un piano").

Scrum è per i costruttori (sviluppatori). Le cose di cui parli sono fatte dai proprietari dei prodotti. I proprietari dei prodotti fanno parte di Scrum in quanto facilitano il processo, ma nel loro lavoro non fanno do Scrum.

Ho lavorato per un'azienda che ha provato a fare in modo che il gruppo Product Management (in realtà, ogni gruppo tranne Sales) eseguisse Scrum. Ogni gruppo, ma gli sviluppatori l'hanno abbandonato in pochi mesi.

Alcuni dei principi come la suddivisione e l'assegnazione delle attività sono stati mantenuti, ma la velocità e gli sprint erano alcune delle cose che in realtà non funzionavano.

Come sidenote, raccomando anche che il proprietario di Porduct dia priorità a ciascuna User-Story. La storia con la priorità più alta viene eseguita per prima, lo stesso per le attività della storia.

In particolare, i "requisiti di raccolta" sono parte del processo di sviluppo per ogni singolo articolo del backlog di Sprint. Quindi qualsiasi stima per un oggetto dell'SB deve essere "da zuppa ai noccioli", dal sedersi con l'utente per discutere quello che vogliono veramente fino al test finale di accettazione.

Gli elementi del Backlog del prodotto, d'altro canto, devono avere solo un numero sufficiente di dettagli in modo che tutti capiscano che stanno parlando della stessa cosa quando si riferiscono ad esso. Quindi un oggetto PB con una sola parola, "Bagel!" va bene finché tutti sanno cosa significa. Ecco perché le User Story sono popolari, perché danno una descrizione di una frase che dice a tutti tutto ciò di cui hanno bisogno per fare la pianificazione. Come accennato in precedenza, passare da quella semplice descrizione a specifiche dettagliate è parte del lavoro di sviluppo svolto in Sprint.

Quindi il sovraccarico per il team nel mantenere il PB è minimo, e accade continuamente in piccoli pezzi di sforzo per tutto il progetto. Quando ti avvicini alla pianificazione di Sprint, gli sviluppatori potrebbero dover fornire stime molto approssimative per gli articoli PB con priorità più alta, ma in realtà non è necessario impiegare più di qualche minuto ciascuno.