Vincoli temporali della storia utente

Innanzitutto, la Guida Scrum è abbastanza chiara su questo comportamento che è sbagliato. Il team di sviluppo e solo il team di sviluppo lo possiede. (Dal momento che ti riferisci a SAFe nel tuo tag, suppongo che tu stia usando anche la Scrum Guide). È improbabile che lo scoraggi, ma è qualcosa da guardare se ritiene che questo sia seguendo le regole (che è completamente possibile Potrebbe avere solo un malinteso.

Passato questo, potresti voler provare a vedere perché lo sta facendo. È un malinteso? C'è pressione da qualche altra parte? Forse sta cercando di aiutare la squadra a realizzare qualcosa, ma questo non sta arrivando nel suo messaggio. Ad esempio, potrebbe provare a introdurre un vincolo per far sì che la squadra abbatta il lavoro più piccolo.

Una volta compreso il suo punto di vista, i prossimi passi saranno più facili da identificare. Personalmente, di solito condivido con i leader che devono stare attenti a regole e metriche. Se un membro del team crede che il proprio successo sia servito meglio incontrando una metrica a scapito di qualcos'altro, come la qualità del codice, il leader potrebbe creare accidentalmente un grosso problema, anche se le sue intenzioni sono buone.

La parte centrale dello sviluppo del software agile è il team auto-organizzante .

Il team di sviluppo, e solo il team di sviluppo , determina il modo in cui il lavoro di sprint è completato. Nessun membro del team di sviluppo deve riferire a un altro membro del team.

Qualsiasi interferenza da parte di estranei (un manager nel tuo caso) dovrebbe essere bloccata dal mischia master o dal proprietario del prodotto. Se il gestore è uno stakeholder nel prodotto, allora c'è un processo ben definito per aggiungere storie al backlog e rivedere il lavoro completato.

Non puoi dire di essere "agile" quando devi lavorare all'interno di vincoli artificiali. Se il tuo manager non ha familiarità con la guida di Scrum, quindi pubblicheremo alcuni dei punti chiave sul muro come promemoria costante di ciò a cui ti stai sforzando e perché.

Mi sembra che tu abbia bisogno di uno Scrum Master. I team agili sono auto-organizzati e qualsiasi stima deve essere concordata dal team e non da una sola persona, specialmente da un "project manager".

Ricorda che l'idea non è fare stime "buone", ma fare stime "coerenti". Ciò significa che se assegni ad una certa storia il valore di 3, altre storie simili dovrebbero avere un valore simile. E tieni presente che questi valori non hanno correlazione con il tempo; quindi se per una squadra 1 è uguale a un giorno (o 8 ore), questo stesso valore potrebbe significare 16 o 4 ore per le altre squadre. Man mano che i tuoi sprint vanno e vengono, queste stime dovrebbero diventare sempre più "precise".

Le stime sono sempre state difficili nello sviluppo del software, e penso che il tuo manager sia privo di (buona) esperienza in questa particolare area, o pensa che pressione e rimproveri funzionino per migliorare i tempi di sviluppo (suggerimento: non lo fanno).

Sull'argomento su come comunicarlo: probabilmente in una cerimonia retrospettiva, inizia sempre con qualcosa di positivo.

PD: Ecco alcune informazioni sulla pianificazione del poker: link

Ci sono già molte risposte interessanti qui, che si riferiscono alla mischia e all'agile.

Tuttavia, non ti stai riferendo al proprietario del prodotto, né a uno scrum master, ma a un project manager. Quindi ti fornirò alcuni argomenti complementari.

• Il successo di un progetto dipende interamente dalle prestazioni di una squadra nel suo insieme. Incolpare le persone non migliorerà la coesione della squadra. Cosa succederà con la colpa e la vergogna? Ognuno inizierà a preoccuparsi della propria agenda per non essere incolpato, e quindi tutti i vantaggi di un dinamico team costruttivo andranno persi.

• Il tuo manager può garantire che tutte le storie degli utenti siano attuabili entro 1-2 giorni? Se lui / lei non può, come potrebbe incolpare lo sviluppatore per impiegare più tempo?

• Intuitivamente, direi che il tuo project manager dovrebbe prima seguire un addestramento agile e fare un mantra del manifesto agile prima di affermare di essere agile . Ma non si può dire così chiaramente se non si ha già un altro lavoro in vista ;-). Quindi chiedi al tuo manager di organizzare un incontro per l'ultimo dei 12 principi:

  At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

  Prima dell'evento, concorda con i tuoi compagni di squadra che la stima collaborativa delle storie è LA cosa da mettere in atto. Durante l'evento, proponi la via della mischia. Ma sii aperto: non isolare il manager; suggerire che PM assiste alla stima in modo che lui / lei possa consigliare la squadra se necessario. Questo dovrebbe riassicurarlo. Forse persino chiedergli di spiegare la pianificazione del poker o metodi simili nella prima sessione (beh, ovviamente lui / lei non lo sa, ma questo costringerà il tuo manager ad apprenderlo). Se il tuo manager è riluttante, proponi il nuovo approccio come esperimento, per il prossimo paio di sprint. Sono abbastanza sicuro che assistere il tuo team a fare stime collaborative, scambiare argomenti tecnici fondati per pianificare lo sprint aiuterà il project manager a realizzare il beneficio dell'approccio.