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
Struttura di Scrum
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)
Perché 3-9 Persone?
👥 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).
Sprint Planning - 2 Parti
🔵 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
Esempio Demo Script
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)
Tecniche di Retrospective
🎯 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
Esempio Product Backlog
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!
Esempio Definition of Done
📋 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
Timeline Sprint 2 Settimane (Esempio)
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.