È comune per gli analisti di business (o altri membri del team non di sviluppo) avere storie tracciate insieme agli sviluppatori?

I Business Analysts sono parte del team? Se è così, considera che la Guida Scrum è abbastanza chiara sul fatto di non dividere il team in ruoli:

• Scrum non riconosce titoli per membri del team di sviluppo diversi da Sviluppatore, indipendentemente dal lavoro svolto dalla persona; non ci sono eccezioni a questa regola;
• I membri del team di sviluppo individuale possono avere competenze specialistiche e aree di interesse, ma la responsabilità appartiene al team di sviluppo come un'intera; e,
• I team di sviluppo non contengono sottogruppi dedicati a particolari domini come test o analisi aziendale.

Come tale, i BA sono membri uguali della squadra, e quindi anche il loro lavoro è o non lo sono e non lo è. Se fanno parte del team, e c'è un compito con un obiettivo misurabile (sai quando è "finito"), allora è un compito valido nello Sprint Backlog.

Inoltre, una User Story è una storia sulla funzionalità che l'utente sta chiedendo. Non è una lista di lavori da fare, in quanto tale. Quindi, di nuovo, quello di cui stai parlando non è davvero una "storia".

Quindi, dal punto di vista pratico, ti suggerirei di includere persone con abilità di analista aziendale nel tuo team e usarle per completare le tue storie. Il team non saprà tutto di una storia prima di iniziare una storia: sanno solo che c'è qualcosa di cui hanno bisogno per imparare e risolvere. Quelli con competenze di analista di business saranno davvero utili nell'elaborazione delle storie e nella traduzione degli affari per parlare di qualcosa che può essere codificato e testato. Se, durante la pianificazione dello sprint, determinate che ci sono attività di analisi da fare, aggiungetele al backlog dello sprint e fate intervenire qualcuno su di esse.

Nella mia esperienza ...

Pro:

• Dà agli sviluppatori la sensazione di non essere gli unici a essere trasparenti.
• Aiuta il proprietario del prodotto a comprendere il processo.

Contro:

• Fornisce ai proprietari dei prodotti la convinzione che ciò che fanno è comparabile in qualche modo a ciò che fanno gli sviluppatori.
• Compensa inutilmente la scheda di lavoro.
• Offre pochissime informazioni veramente utili a chiunque.

Personalmente, penso che i professionisti possano essere raggiunti in altri modi. Ma i contro non sono inaccettabili, quindi se il Product Owner lo desidera VERAMENTE, falli avere fino a quando non si rivelerà una perdita di tempo.