A chi appartiene il backlog di Nexus Sprint?

2

La Guida al Nexus afferma che:

A Nexus Sprint Backlog is the composite of Product Backlog items from the Sprint Backlogs of the individual Scrum Teams.

Tuttavia, cercando di costruire un'analogia tra il normale Sprint Backlog e il Nexus Sprint Backlog, mi sono confuso sui seguenti aspetti di questo artefatto:

  • appartiene al team di integrazione di Nexus o è un artefatto condiviso tra tutti i team all'interno di un Nexus?
  • Se si tratta di un artefatto condiviso, il team di integrazione di Nexus ha il proprio Sprint Backlog? Ha un nome speciale?
  • Chi può cambiare il Nexus Sprint Backlog durante lo Sprint? (di nuovo come un'analogia con lo Sprint Backlog).
posta Andremoniy 18.12.2018 - 08:45
fonte

2 risposte

2

Nexus è solo una parola d'ordine per una metodologia per ridimensionare un singolo team di scrum in più team. Il "Nexus Sprint Backlog" deve essere gestito dal Nexus Integration Team (Product Owner, Scrum Master, membri di altri team di scrum).

Dalla sezione "Nexus Sprint Planning":

The purpose of Nexus Sprint Planning is to coordinate the activities of all Scrum Teams in a Nexus for a single Sprint. The Product Owner provides domain knowledge and guides selection and priority decisions. The Product Backlog should be adequately refined with dependencies identified and removed or minimized prior to Nexus Sprint Planning.

During Nexus Sprint Planning, appropriate representatives from each Scrum Team validate and make adjustments to the ordering of the work as created during Refinement events. All members of the Scrum Teams should participate to minimize communication issues.

(enfasi, mia)

Uno sprint di backlog è di proprietà, piuttosto è controllato dalla cooperazione tra il proprietario del prodotto e i team che creano il software. All'interno del sapore Nexus di Scrum, il Nexus Sprint Backlog è la cosa che aiuta a coordinare la consegna del software da parte di più team in un singolo sprint.

Come esempio forzato, non ha senso costruire un micro servizio che invii un messaggio al "micro servizio di notifica" per inviare un messaggio di testo, quando il micro servizio di notifica non supporta i messaggi di testo SMS. Il backlog di Nexus Sprint dovrebbe coordinare il lavoro richiesto per questi due servizi per garantire che il servizio A possa infine inviare un messaggio di testo tramite il servizio di notifica al rilascio.

    
risposta data 18.12.2018 - 13:33
fonte
0

La Guida Nexus dice alcune cose importanti.

The outcome is a set of Sprint Goals that align with the overarching Nexus Sprint Goal, each Scrum Team's Sprint Backlog and a single Nexus Sprint Backlog. The Nexus Sprint Backlog makes the work of all Scrum Team's selected Product Backlog items and any dependencies transparent.

...

All Product Backlog items selected for the Sprint and their dependencies should be made transparent on the Nexus Sprint Backlog.

...

A Nexus Sprint Backlog is the composite of Product Backlog items from the Sprint Backlogs of the individual Scrum Teams. It is used to highlight dependencies and the flow of work during the Sprint. It is updated at least daily, often as part of the Nexus Daily Scrum.

I singoli Scrum Teams conservano i loro Sprint Backlogs, che consistono negli Articoli del Product Backlog e nel lavoro che lo Scrum Team ha decomposto in Product Backlog Items. Si consideri che la Guida Scrum afferma che lo Sprint Backlog "rende visibile tutto il lavoro che il team di sviluppo identifica come necessario per soddisfare l'obiettivo di Sprint". Ciò significa che uno Sprint Backlog contiene non solo gli elementi del Product Backlog, ma funziona con una granularità più fine rispetto agli elementi del Product Backlog.

Nexus Sprint Backlog contiene gli articoli del Product Backlog su cui lavora uno dei team più il sottoinsieme di lavoro che identifica le dipendenze tra i team. Come gli Sprint Backlog per i team rendono visibile il lavoro del team, il Nexus Sprint Backlog rende visibile il lavoro interfunzionale. Il lavoro trasversale è il Product Backlog Items che deve essere consegnato e pienamente integrato alla fine dello Sprint, ma anche qualsiasi lavoro che richieda consapevolezza tra i singoli team per garantire che il lavoro sia consegnato e pienamente integrato.

Direi che il proprietario principale è il team di integrazione di Nexus. Tuttavia, se qualcuno su uno dei team Scrum identifica un nuovo lavoro che si estenderebbe attraverso due o più team nel Nexus, sarebbe in grado di aggiungerlo al Nexus Sprint Backlog tramite il rappresentante del team nel Team di integrazione di Nexus. Considera che i membri del team di integrazione di Nexus "sono spesso membri dei singoli Scrum Team nel Nexus" e che la loro appartenenza al team di integrazione di Nexus "ha la precedenza sull'iscrizione individuale al team Scrum". Ciò significa che i membri del team di integrazione di Nexus sono responsabili e responsabili di assicurare che gli elementi di lavoro intergruppo aggiunti al backlog di Nexus Sprint siano completi.

    
risposta data 19.12.2018 - 03:01
fonte

Leggi altre domande sui tag