Scrum Framework: Sprint, Ruoli e Cerimonie
Scrum è il framework Agile più popolare al mondo, utilizzato dal 70% dei team che adottano metodologie agili. Creato da Ken Schwaber e Jeff Sutherland nei primi anni '90, Scrum fornisce una struttura leggera per gestire progetti complessi in modo iterativo e incrementale.
🎯 Cosa Imparerai
- I 3 ruoli di Scrum: Product Owner, Scrum Master, Development Team
- Le 5 cerimonie (eventi) di Scrum in dettaglio
- I 3 artifact: Product Backlog, Sprint Backlog, Increment
- Il ciclo Sprint completo con timeline
- Definition of Done e Acceptance Criteria
- Anti-pattern comuni e come evitarli
- Scrum at Scale: SAFe, LeSS, Nexus
Cos'è Scrum?
Scrum è un framework empirico basato su tre pilastri:
🏛️ I 3 Pilastri di Scrum
- Trasparenza (Transparency): Tutti gli aspetti del processo sono visibili a tutti
- Ispezione (Inspection): Frequente verifica del progresso verso gli obiettivi
- Adattamento (Adaptation): Aggiustamenti del processo basati sui risultati
SCRUM FRAMEWORK
├── 3 RUOLI
│ ├── Product Owner
│ ├── Scrum Master
│ └── Development Team
├── 5 EVENTI (Cerimonie)
│ ├── Sprint
│ ├── Sprint Planning
│ ├── Daily Scrum
│ ├── Sprint Review
│ └── Sprint Retrospective
└── 3 ARTIFACT
├── Product Backlog
├── Sprint Backlog
└── IncrementI 3 Ruoli di Scrum
1. Product Owner (PO)
Il Product Owner è il "proprietario del prodotto", responsabile di massimizzare il valore del lavoro del team.
🎯 Responsabilità del Product Owner
- Visione del prodotto: Definire e comunicare la product vision
- Gestione Product Backlog: Creare, ordinare e mantenere il backlog
- Prioritizzazione: Decidere cosa è più importante (ROI-driven)
- Accettazione lavoro: Approvare/rifiutare le user stories completate
- Stakeholder engagement: Interfaccia tra team e cliente/business
- Decision maker: Ha l'ultima parola su "cosa" costruire (non "come")
✅ PO Efficace
- Disponibile al team quotidianamente
- Decisioni rapide
- Visione chiara del prodotto
- Conosce il dominio business
- Empowered (ha authority)
- Collaborativo con il team
❌ PO Inefficace
- Assente/indisponibile
- Decisioni lente o indecise
- PO "by committee"
- Non conosce business
- Solo proxy, no authority
- Micromanage il team
2. Scrum Master
Lo Scrum Master è il servant leader che aiuta il team e l'organizzazione ad adottare Scrum in modo efficace.
🛡️ Responsabilità dello Scrum Master
Servizio al Development Team:
- Coaching su self-organization e cross-functionality
- Rimozione impedimenti (blockers)
- Facilitare eventi Scrum
- Proteggere il team da distrazioni esterne
Servizio al Product Owner:
- Aiutare a gestire efficacemente il Product Backlog
- Facilitare la collaborazione con il team
- Coaching su pratiche Agile
Servizio all'Organizzazione:
- Guidare l'adozione di Scrum nell'org
- Aumentare la produttività del team
- Lavorare con altri Scrum Master
⚠️ Scrum Master NON è:
- ❌ Project Manager (Scrum non ha PM!)
- ❌ Team Lead o Manager
- ❌ Segretario del team
- ❌ Responsabile del delivery
- ❌ Technical lead
Lo Scrum Master è un facilitatore e coach, non un manager con authority sul team.
3. Development Team
Il Development Team è un gruppo di professionisti che lavorano insieme per consegnare un incremento "Done" del prodotto alla fine di ogni Sprint.
👥 Caratteristiche del Development Team
- Self-organizing: Decide autonomamente come realizzare il lavoro
- Cross-functional: Ha tutte le skill necessarie (dev, test, design, etc.)
- No sub-team: Non ci sono team "frontend" o "backend" separati
- No titoli: Tutti sono "Developer" (no gerarchie interne)
- Accountable come team: Success e failure sono collettivi
- Dimensione ottimale: 3-9 persone (ideale: 5-7)
👥 TEAM SIZE ANALYSIS
< 3 persone
├─ ❌ Troppo piccolo
├─ Mancano skill necessarie
├─ Vulnerabilità (assenze impattano molto)
└─ Poco scambio di conoscenze
3-5 persone
├─ ✅ Comunicazione facile
├─ ✅ Velocità decisionale alta
└─ ⚠️ Skill coverage limitata
6-9 persone
├─ ✅ Balance ottimale
├─ ✅ Competenze diversificate
├─ ✅ Resilienza ad assenze
└─ ⚠️ Comunicazione richiede più effort
> 9 persone
├─ ❌ Troppo grande
├─ Comunicazione complessa (N*(N-1)/2)
├─ Coordinating overhead alto
└─ Considera split in 2 teamLe 5 Cerimonie di Scrum
1. Sprint (Timeboxed Container)
Lo Sprint è il cuore di Scrum: un ciclo time-boxed di 1-4 settimane (più comune: 2 settimane) durante il quale viene creato un incremento "Done" del prodotto.
📅 Regole dello Sprint
- Durata fissa: Sempre la stessa lunghezza per tutti gli sprint
- Sprint Goal: Obiettivo chiaro e condiviso
- No cambiamenti: Scope non cambia durante lo sprint (focus)
- Quality: Definition of Done non viene compromessa
- Cancellazione: Solo il PO può cancellare uno sprint (raro!)
2. Sprint Planning
Time-box: Massimo 8 ore per sprint di 1 mese (proporzionale per sprint più brevi).
Partecipanti: Tutto lo Scrum Team (PO, SM, Dev Team).
🔵 PARTE 1: WHAT? (Cosa faremo?)
Durata: ~50% del tempo (es: 2 ore per sprint 2 settimane)
1. Product Owner presenta top priority backlog items
2. Team fa domande per capire requisiti
3. Team seleziona items per lo sprint (pull, non push!)
4. Sprint Goal viene definito
└─ Es: "Implementare checkout flow completo"
Output: Sprint Backlog (lista user stories selezionate)
---
🔵 PARTE 2: HOW? (Come lo realizzeremo?)
Durata: ~50% del tempo
1. Team scompone ogni user story in task tecnici
2. Stima effort in ore per ogni task
3. Identifica dipendenze e rischi
4. Valida capacità (velocity storica)
5. Commitment del team
Output: Sprint Backlog dettagliato con task
---
📊 CAPACITY PLANNING
Team di 5 persone, sprint 2 settimane:
- 5 persone × 10 giorni = 50 giorni-uomo teorici
- -20% per meeting, supporto, imprevisti = 40 giorni effettivi
- Velocity storica: 30 story points
- → Commitment: ~25-30 story points (conservative)3. Daily Scrum (Standup)
Time-box: 15 minuti (fissi!).
Partecipanti: Development Team (obbligatorio), SM facilità, PO opzionale.
Quando: Stesso orario, stesso luogo, ogni giorno.
🗣️ Le 3 Domande Classiche
Ogni membro del team risponde:
- Cosa ho fatto ieri che ha aiutato il team verso lo Sprint Goal?
- Cosa farò oggi per aiutare il team verso lo Sprint Goal?
- Ho impedimenti che bloccano me o il team?
❌ Daily Scrum Anti-Patterns
- Status report al manager: Non è un reporting gerarchico!
- Problem-solving esteso: Daily è per sync, non per risolvere problemi (after meeting)
- Durata > 15 min: Time-box è sacro, discussioni fuori dal daily
- Solo chi parla è Scrum Master: Deve essere conversazione del team
- People standing/sitting: Standing meeting aiuta a essere brevi
4. Sprint Review
Time-box: Massimo 4 ore per sprint 1 mese (es: 2 ore per sprint 2 settimane).
Partecipanti: Scrum Team + Stakeholder + Cliente.
🎬 Agenda Sprint Review
- Apertura (5 min): PO ricorda Sprint Goal e cosa era pianificato
- Demo (60%): Team mostra working software (live demo, no slides!)
- Solo features "Done" secondo DoD
- Ambiente staging/production-like
- Interattivo: stakeholder provano il prodotto
- Feedback (30%): Stakeholder forniscono input
- Cosa funziona bene?
- Cosa manca o va cambiato?
- Nuove idee emerse
- Product Backlog update (10%): PO aggiorna backlog con insights
Sprint Review - Sprint 14 - E-commerce Checkout
✅ COMPLETED (Demo order):
1. User Story: "Add payment method selection"
└─ Demo: Credit card, PayPal, Apple Pay
2. User Story: "Implement address autocomplete"
└─ Demo: Google Places API integration
3. User Story: "Order confirmation email"
└─ Demo: Email template with order details
❌ NOT COMPLETED (transparenza!):
4. User Story: "Coupon code validation"
└─ Reason: API integrazione more complex, rollover to next sprint
🔄 FEEDBACK RACCOLTO:
- Stakeholder: "Aggiungere shipping estimation prima del checkout"
- PO: Added to backlog, high priority
- Marketing: "Email template needs company branding"
- PO: Created new story for next sprint5. Sprint Retrospective
Time-box: Massimo 3 ore per sprint 1 mese (es: 1.5 ore per sprint 2 settimane).
Partecipanti: Solo Scrum Team (PO, SM, Dev Team). No external stakeholder!
Quando: Dopo Sprint Review, prima del prossimo Planning.
🔄 Obiettivo Retrospective
Inspect & Adapt del processo di lavoro (non del prodotto). Focus su:
- Cosa è andato bene? (Keep doing)
- Cosa è andato male? (Stop doing)
- Cosa possiamo migliorare? (Start doing)
🎯 TECNICA 1: Start-Stop-Continue
┌─────────────┬─────────────┬─────────────┐
│ START │ STOP │ CONTINUE │
├─────────────┼─────────────┼─────────────┤
│ Pair │ Working │ Code │
│ programming │ overtime │ reviews │
│ │ │ │
│ Automated │ Skipping │ Daily │
│ tests │ retrospect. │ standups │
└─────────────┴─────────────┴─────────────┘
🎯 TECNICA 2: Happiness Radar
Team rate (1-5) diverse categorie:
- Collaboration: ⭐⭐⭐⭐⭐ (Excellent!)
- Technical quality: ⭐⭐⭐ (Needs improvement)
- Work-life balance: ⭐⭐ (RED FLAG!)
- Sprint goal clarity: ⭐⭐⭐⭐
🎯 TECNICA 3: Sailboat Retrospective
⛵ Goal (island): Dove vogliamo arrivare?
🌊 Winds: Cosa ci spinge avanti?
⚓ Anchors: Cosa ci trattiene?
🪨 Rocks: Rischi da evitare?
OUTPUT: 1-3 ACTION ITEMS concreti
✅ Action: "Introdurre TDD da prossimo sprint"
Owner: Tutta il team
Due: Sprint 15
Success: 50% new code has tests first🛡️ Regole della Retrospective
- Safe space: Ciò che si dice in retro, resta in retro
- No blame: Focus su processo, non su persone
- Onestà: Speak up! È il momento per migliorare
- Action-oriented: Non solo lamentele, anche soluzioni
- Follow-up: Review action items dello sprint precedente
I 3 Artifact di Scrum
1. Product Backlog
Lista ordinata e dinamica di tutto il lavoro necessario per il prodotto. Owned dal Product Owner.
📚 Caratteristiche Product Backlog
- Ordered (non prioritized): Singola sequenza, top = prossimo sprint
- Emergent: Evolve continuamente, mai "completo"
- Detailed appropriately: Top items dettagliati, bottom vaghi
- Estimated: Story points o altra metrica relativa
- Transparent: Visibile a tutti
PRODUCT BACKLOG - E-commerce Platform
Ordered by value/priority (top = next)
Pos | ID | User Story | Points | Status
----|-----|---------------------------------------|--------|--------
1 | 123 | Guest checkout without registration | 8 | Ready
2 | 124 | Save payment methods for future | 5 | Ready
3 | 125 | Product recommendations AI | 13 | Ready
4 | 126 | Multi-currency support | 20 | Refining
5 | 127 | Wishlist sharing social | 8 | Refining
6 | 128 | Advanced search filters | 13 | Refining
...
20 | 145 | Dark mode UI | ? | Idea
21 | 146 | Voice search | ? | Idea
READY = Acceptance criteria defined, DoD clear, impedimenti removed
REFINING = In discussion, needs more details
IDEA = High-level, da elaborare in futuro2. Sprint Backlog
Subset del Product Backlog selezionato per lo Sprint corrente + piano per consegnarlo. Owned dal Development Team.
📋 Contenuto Sprint Backlog
- User stories selezionate
- Task tecnici dettagliati
- Sprint Goal
- Piano di implementazione
- Stato real-time di ogni task
🔄 Aggiornamento
- Aggiornato dal team quotidianamente
- Nuovi task possono emergere
- Solo team può modificarlo
- Visibile su board (fisico/digitale)
- Burndown chart deriva da esso
3. Increment
La somma di tutti i Product Backlog items completati durante uno Sprint + valore degli increment di tutti gli Sprint precedenti. Deve essere "Done" secondo la Definition of Done.
✅ Definition of Done (DoD)
Criteri condivisi e chiari per quando un lavoro è considerato completo. Non negoziabile!
📋 DEFINITION OF DONE (Team Level)
Una user story è "DONE" quando:
✅ DEVELOPMENT
├─ Codice scritto seguendo coding standards
├─ Codice committed su feature branch
├─ Code review approvata (2+ reviewers)
└─ Merged su main branch
✅ TESTING
├─ Unit tests scritti (coverage ≥ 80%)
├─ Integration tests passati
├─ Regression tests passati
├─ Manual exploratory testing completato
└─ Nessun bug P0/P1 aperto
✅ DOCUMENTATION
├─ Inline code comments per logica complessa
├─ API documentation aggiornata
├─ README updated (se necessario)
└─ User documentation scritta (se feature user-facing)
✅ QUALITY
├─ Linter passed (zero warnings)
├─ Security scan passed
├─ Performance benchmarks ok
└─ Accessibility checks passed (WCAG 2.1 AA)
✅ DEPLOYMENT
├─ Deployed su staging environment
├─ Smoke tests su staging passati
├─ Product Owner ha accettato (demo)
└─ Ready for production deployment
---
DoD può avere 3 livelli:
1. Task DoD: Singolo task completato
2. Story DoD: User story completata (sopra)
3. Release DoD: Incremento rilasciabile in produzioneIl Flusso Sprint Completo
SPRINT 14 - Goal: "Implement complete checkout flow"
📅 LUNEDÌ SETTIMANA 1 (Giorno 1)
├─ 09:00-13:00: Sprint Planning
│ ├─ Part 1 (WHAT): PO presenta, team seleziona stories (20 pts)
│ └─ Part 2 (HOW): Breakdown in task, capacity planning
└─ 14:00-18:00: Development inizia
📅 MAR-VEN SETTIMANA 1 (Giorni 2-5)
├─ 09:00-09:15: Daily Scrum (ogni giorno)
├─ 09:15-18:00: Development + Testing
└─ Continuous: Code review, pair programming
📅 MERCOLEDÌ SETTIMANA 1 (Mid-Sprint)
└─ 15:00-16:00: Backlog Refinement (opzionale)
└─ Preparare stories per prossimo sprint
📅 LUN-GIO SETTIMANA 2 (Giorni 6-9)
├─ 09:00-09:15: Daily Scrum
├─ Development + Integration
└─ Bug fixing e polish
📅 VENERDÌ SETTIMANA 2 (Giorno 10)
├─ 09:00-09:15: Daily Scrum (ultimo!)
├─ 09:15-13:00: Final testing e demo prep
├─ 14:00-16:00: Sprint Review
│ └─ Demo a stakeholder, raccolta feedback
├─ 16:15-17:45: Sprint Retrospective
│ └─ Inspect & adapt del processo
└─ 17:45-18:00: Celebrazione! 🎉
🔵 LUNEDÌ SETTIMANA 3
└─ Inizia Sprint 15...Anti-Pattern Scrum Comuni
🚫 Errori da Evitare
1. Scrum Ma (Scrum But)
Sintomo: "Facciamo Scrum ma... [eccezione]"
- "Scrum ma senza Daily Scrum" → Non è Scrum
- "Scrum ma senza Retrospective" → Non migliorerete mai
- "Scrum ma PO non disponibile" → Team bloccato continuamente
2. Sprint come Mini-Waterfall
Problema: Tutte le fasi in sequenza nello sprint
❌ BAD: Sprint = Design → Dev → Test → Deploy (waterfall!)
✅ GOOD: Sprint = Iterate su features, ogni feature Done completamente3. Sprint Goal Assente o Vago
Problema: Sprint è solo "lista di task" senza obiettivo coerente
- ❌ BAD: "Completare stories 45, 46, 47, 48"
- ✅ GOOD: "Enable users to complete purchase without registration"
4. Velocity come Commitment Fisso
Problema: Management usa velocity per pressare il team
- Velocity è una metrica per planning, non un target da raggiungere!
- Team sotto pressione gonfia stime → velocity perde significato
5. Product Owner Proxy
Problema: PO non ha authority, deve sempre "chiedere"
- Decisioni lente
- Team bloccato
- Soluzione: Empower il PO o cambiare persona
Scrum at Scale
Quando l'organizzazione ha molti team Scrum, servono framework per coordinare. I 3 principali:
🏢 SAFe (Scaled Agile Framework)
- Framework più popolare per enterprise
- 4 livelli: Team, Program, Large Solution, Portfolio
- Program Increment (PI) di 8-12 settimane
- Agile Release Train (ART): 50-125 persone
- Pro: Strutturato, documentato, adatto a grandi org
- Contro: Pesante, meno agile di Scrum puro
🪜 LeSS (Large-Scale Scrum)
- Scrum esteso a più team (2-8 team)
- 1 Product Owner per tutti i team
- 1 Product Backlog condiviso
- Sprint sincronizzati
- Overall Retrospective cross-team
- Pro: Mantiene semplicità di Scrum
- Contro: Richiede alta maturità Agile
🔗 Nexus
- Framework Scrum.org per 3-9 team
- Nexus Integration Team coordina
- Nexus Sprint Planning, Review, Retrospective
- Focus su integrazione continua
- Pro: Ufficiale da Scrum.org
- Contro: Limitato a ~100 persone
Metriche Scrum Utili
📊 Metriche di Processo
- Velocity: Story points/sprint
- Sprint Burndown: Lavoro rimanente
- Release Burnup: Progresso verso release
- Cycle Time: Tempo story → done
🎯 Metriche di Qualità
- Defect Rate: Bug per sprint
- Code Coverage: % codice testato
- Technical Debt: Effort per refactoring
- Team Happiness: Survey trimestrale
Conclusioni
Scrum fornisce una struttura semplice ma potente per sviluppo Agile. La chiave del successo è l'adozione rigorosa del framework (no Scrum But!) combinata con ispezione e adattamento continui.
💡 Punti Chiave
- Scrum ha 3 ruoli, 5 eventi, 3 artifact - tutti essenziali
- Product Owner massimizza valore, Scrum Master facilità, Dev Team consegna
- Sprint è ciclo time-boxed (1-4 settimane) con obiettivo chiaro
- Definition of Done è criterio non negoziabile per qualità
- Retrospective è il motore del miglioramento continuo
- Trasparenza, Ispezione, Adattamento sono i 3 pilastri
- Scrum at Scale richiede framework addizionali (SAFe, LeSS, Nexus)
📚 Prossimo Articolo
Nel prossimo articolo esploreremo Kanban Method: il sistema a flusso continuo con WIP limits, board Kanban, metriche di flow (Lead Time, Cycle Time) e confronto con Scrum.
Domande frequenti
Cos'è lo Sprint in Scrum?
Lo Sprint è un ciclo time-boxed di 1-4 settimane durante il quale viene creato un incremento "Done" del prodotto.
Chi sono i ruoli principali in Scrum?
I tre ruoli principali in Scrum sono il Product Owner, lo Scrum Master e il Development Team.
Quali sono le cinque cerimonie di Scrum?
Le cinque cerimonie di Scrum sono lo Sprint, la Sprint Planning, il Daily Scrum, la Sprint Review e la Sprint Retrospective.
Cos'è l'Increment in Scrum?
L'Increment è la somma di tutti i Product Backlog items completati durante uno Sprint più il valore degli incrementi di tutti gli Sprint precedenti. Deve essere "Done" secondo la Definition of Done.
Commenti
Caricamento commenti...
Accedi per commentare