Procedura per pianificare e chiudere uno sprint in Azure Boards, fino al punto in cui è il codice a cambiare lo stato delle storie.

Occorre: un'organizzazione di Azure DevOps, un progetto creato con il processo Agile (quello che prevede Epic, Feature, User Story e Task) e un repository dentro il progetto. Durata: circa trenta minuti. Costo: zero. Azure Boards è gratuito fino a cinque utenti.

Il portale delle schermate è in inglese: i nomi dei comandi sono riportati come appaiono a schermo.

Il materiale

1. Accendi il livello Epic

Project settings > Team configuration > Backlogs, e spunta Epics.

Nel processo Agile il livello Epic è spento di partenza: senza questo passo, nel backlog si vedono solo le User Story.

2. Scrivi il backlog

Boards > Backlogs, livello Epics nel menu in alto a destra. Con New Work Item si crea l'Epic; dalla riga dell'Epic si aggiungono le Feature, e da quelle le User Story.

• Epic: Customer portal
• Feature: Catalog, con le storie Product list (5 punti), Search by name (3), Product page (3)
• Feature: Cart, con le storie Add to cart (8) e Login (5)

I punti si scrivono nel campo Story Points della storia. Per vederli in elenco: Column Options > Add a column > Story Points. I due bottoni + e − sopra la griglia aprono e chiudono un livello alla volta.

3. Metti le date allo sprint

Project settings > Project configuration > Iterations. Seleziona Sprint 1 e scrivi Start Date e End Date: qui, 2 e 13 novembre 2026.

Dieci giorni lavorativi. Senza date lo sprint non ha né capacità né burndown.

4. Dichiara la capacità

Boards > Sprints > Capacity. Per ogni persona: Activity e Capacity per day. Qui una persona sola, Development, 3 ore al giorno.

Tre ore per dieci giorni fanno 30 ore disponibili.

Lo sprint

5. Porta le storie nello sprint e scomponile

Nel backlog, con il pannello Planning aperto, si trascinano le storie su Sprint 1. Qui ci vanno le tre del catalogo: 5 + 3 + 3, cioè 11 punti.

Da Sprints > Backlog ogni storia si apre e prende i suoi task, con le ore in Remaining Work:

• Product list: Products API 8 ore, List page 6
• Search by name: Search filter 6, Search field 4
• Product page: Detail page 8, Link to detail 2

Totale 34 ore contro 30 di capacità: lo sprint è già pieno.

6. Muovi le card

Sprints > Taskboard. Le colonne sono New, Active, Resolved, Closed, e in testa a ognuna ci sono le ore che contiene. Si trascina Products API in Active e List page in Closed.

Chiudendo List page le sue 6 ore spariscono dal conto: da 34 si passa a 28, divise fra New 20 e Active 8.

7. Guarda il burndown

Sprints > Analytics.

Riporta Remaining Work 28, Completed 0%, e due linee di riferimento: Ideal Trend, la discesa teorica fino a zero il 13 novembre, e Remaining Capacity, le ore che restano alla squadra. La linea blu parte dal giorno in cui le attività sono state inserite.

Il codice che muove la lavagna

8. La commit che si aggancia alla storia

Basta citare il numero della storia nel messaggio della commit:

Product list: first endpoint #500

Sulla storia #500 compare un collegamento Fixed in Commit. Lo stato però non cambia: resta New. La commit aggancia, non chiude.

9. La pull request che la chiude

Dal ramo di lavoro si apre una pull request. Se la storia non si aggancia da sola, si aggiunge con il + della sezione Work items.

Premi Complete. Nel pannello, sotto Post-completion options, la casella Complete associated work items after merging è già spuntata: è quella che chiude la storia.

Premi Complete merge.

10. La storia si chiude da sola

La storia #502 è Closed, con Reason Acceptance tests pass. Nella sezione Development ci sono la pull request e le due commit, e nel messaggio della commit di unione Azure DevOps ha scritto Related work items: #502.

Pulire

Il progetto si cancella da Project settings > Overview, bottone Delete, riscrivendo il nome del progetto per conferma. Resta recuperabile per 28 giorni.

Nomi dei comandi, schermate e numeri rilevati su Azure DevOps il 6 novembre 2026, con il processo Agile.