Sono d'accordo con te sulla stima. Nella mia azienda, abbiamo un processo di requisiti molto formalizzato (dettato dal nostro cliente) e vengono generate molte storie di utenti. Gli analisti aziendali come me stanno scrivendo queste storie e, in molti casi, non disponiamo delle conoscenze tecniche per valutarle realisticamente. Per noi, la fase di stima si verifica dopo che un team di mischia ha deciso di raccogliere una storia dal backlog. A quel punto, teniamo una rapida sessione di pianificazione / grooming in cui i nostri leader tecnologici e noi BAs possiamo parlare delle storie su cui lavoreremo, e gli sviluppatori useranno "pianificazione del poker" o qualunque metodo abbia senso per una determinata mischia squadra per dare una storia una stima delle dimensioni. Faccio un punto (come un BA) per NON votare nel poker di pianificazione anche se sono incorporato in una squadra di mischia.
Sono anche d'accordo che gli AC dovrebbero essere parte della storia prima è stimata. È completamente possibile per uno sviluppatore guardare solo la dichiarazione di valore e non vedere completamente tutte le necessità logiche che ne derivano immediatamente e stimare in modo impreciso una storia. Per me, una storia non è "fatta" a meno che non siano stati definiti i criteri di accettazione. Per ovvie ragioni, sono anche estremamente attento se dovrò mai toccare AC per una storia "in volo" (già accettata da una squadra), perché è come scherzare con i pali della porta durante una partita di calcio. Se mai dovessi cambiare un AC, è d'accordo con lo sviluppatore che possiede quella storia e dopo aver attentamente valutato se creare o meno una nuova storia nel backlog (idealmente, dovremmo sempre farlo, ma non lo facciamo t vivere in un mondo da manuale ideale-agile).
Per quanto riguarda il miglior formato di scrittura a scopo di test, puoi andare in entrambi i modi. Trovo che il classico "Come una X, ho bisogno di Y, così che io possa Z" funzioni meglio perché è immediatamente comprensibile a qualsiasi membro del team o stakeholder che lo incontra. Se lo scrivi correttamente , dovrebbe essere sempre abbastanza facile derivare i casi di test. Molto spesso, mentre sto scrivendo una user story, mi trovo a pensare "come potrei testarlo?". Trovo anche molto istruttivo come un ragazzo dei requisiti per andare a trovare i nostri tester e scegliere il loro cervello ogni volta che posso. Si scopre che spesso hanno una visione diversa della nostra applicazione rispetto a una BA e "pensare come un tester" ci aiuta a chiudere il circuito logico quando scriviamo una buona user story.
Abbiamo recensioni tra pari di storie di utenti tra i BAs sul mio progetto, che ritengo sia una buona pratica, e finiamo per avere un modo abbastanza classico e standardizzato di scriverle. Questa è una buona cosa per un progetto grande come il nostro perché il nostro cliente (o chiunque) può passare attraverso le storie degli utenti e non deve cimentarsi con più tipi di formati di storie di utenti.
Per quanto riguarda le attività, questa è davvero una domanda specifica per l'organizzazione. Per noi, le attività sono più utili quando più sviluppatori finiscono per lavorare su una singola storia utente. Le attività ci aiutano a tenere traccia di ciò che ogni dev sta facendo. Il nostro Scrum Master come gli sviluppatori per rompere storie in compiti perché dà loro una visione più granulare di ciò che sta accadendo e li aiuta a stimare la velocità. Nel nostro progetto, monitoriamo anche le attività per ora, ma storie per punto. Penso che non sia al 100% agile-scrum "kosher", ma aiuta il team di gestione del progetto. In realtà, ciò che fai o non fai con le attività dipende molto da cosa stai cercando di tenere traccia di, da come lo vuoi fare e da come sei organizzato.