스크럼 프레임워크: 스프린트, 역할 및 행사
스크럼 팀의 70%가 사용하는 세계에서 가장 인기 있는 Agile 프레임워크입니다. 민첩한 방법론을 채택하는 기업입니다. 1990년대 초 Ken Schwaber와 Jeff Sutherland가 만든 스크럼은 가벼운 구조 복잡한 프로젝트를 효율적으로 관리하기 위해 반복적이고 점진적입니다.
🎯 무엇을 배울 것인가
- 스크럼의 3가지 역할: 제품 소유자, 스크럼 마스터, 개발팀
- 5가지 스크럼 행사(이벤트) 세부정보
- 3가지 아티팩트: 제품 백로그, 스프린트 백로그, 증분
- 타임라인이 포함된 전체 스프린트 주기
- 완료 및 수락 기준의 정의
- 일반적인 안티 패턴과 이를 방지하는 방법
- 대규모 스크럼: SAFe, LeSS, Nexus
스크럼이란 무엇입니까?
스크럼은 경험적 틀 세 가지 기둥을 기반으로:
🏛️ 스크럼의 3가지 기둥
- 투명도: 프로세스의 모든 측면이 모든 사람에게 표시됩니다.
- 점검: 목표를 향한 진행 상황을 자주 확인합니다.
- 적응: 결과 기반 프로세스 조정
스크럼 구조
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
└── Increment스크럼의 3가지 역할
1. 제품 소유자(PO)
Il 제품 소유자 책임이 있는 "제품 소유자"입니다. 가치를 극대화하다 팀의 작업 중.
🎯 제품 소유자의 책임
- 제품 비전: 제품 비전 정의 및 전달
- 제품 백로그 관리: 백로그 생성, 주문 및 유지 관리
- 우선순위: 가장 중요한 것이 무엇인지 결정(ROI 기반)
- 채용 수락: 완료된 사용자 스토리 승인/거부
- 이해관계자 참여: 팀과 고객/비즈니스 간의 인터페이스
- 의사결정자: 구축할 '무엇'('어떻게'가 아님)에 대한 최종 결정권이 있습니다.
✅ PO 유효
- 매일 팀에서 사용 가능
- 빠른 결정
- 제품의 명확한 보기
- 비즈니스 도메인을 알고 있습니다.
- 권한이 있는(권한이 있는)
- 팀과 협력
❌ PO 무효
- 부재/불가
- 느리거나 우유부단한 결정
- PO "위원회 별"
- 그는 사업을 모른다
- 대리인만 있고 권한은 없음
- 팀을 세세하게 관리하기
2. 스크럼 마스터
Lo 스크럼 마스터 è il 하인 리더 그것이 팀에 도움이 된다 스크럼을 효과적으로 채택하는 조직.
🛡️ 스크럼 마스터의 책임
개발팀에 대한 서비스:
- 자기 조직화 및 교차 기능에 대한 코칭
- 장애물 제거(차단제)
- 스크럼 이벤트 촉진
- 외부 방해 요소로부터 팀을 보호하세요
제품 소유자에 대한 서비스:
- 제품 백로그를 효과적으로 관리하도록 지원
- 팀과의 협업 촉진
- 애자일 관행에 대한 코칭
조직에 대한 서비스:
- 조직에서 스크럼 채택 추진
- 팀 생산성 향상
- 다른 스크럼 마스터와 협력
⚠️ 스크럼 마스터는 다음이 아닙니다:
- ❌ 프로젝트 관리자(스크럼에는 PM이 없습니다!)
- ❌ 팀장 또는 관리자
- ❌ 팀비서
- ❌ 배송관리자
- ❌ 기술 리드
스크럼 마스터는 진행자 e 코치, 관리자가 아닙니다 팀에 대한 권한을 가지고 있습니다.
3. 개발팀
Il 개발팀 위해 함께 일하는 전문가 그룹입니다. 각 스프린트가 끝날 때마다 제품의 "완료" 증분을 제공합니다.
👥 개발팀의 특징
- 자기 조직화: 그는 작업 수행 방법을 독립적으로 결정합니다.
- 다기능: 필요한 모든 기술(개발, 테스트, 디자인 등)을 보유하고 있습니다.
- 하위 팀 없음: 별도의 "프런트엔드" 또는 "백엔드" 팀이 없습니다.
- 제목 없음: 모든 사람은 "개발자"입니다(내부 계층 없음).
- 팀으로서 책임: 성공과 실패는 종합적이다
- 최적의 크기: 3~9명(적정: 5~7명)
왜 3~9명인가요?
👥 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 team5개의 스크럼 행사
1. 스프린트(타임박스 컨테이너)
Lo 스프린트 스크럼의 핵심은 시간이 제한된 주기입니다. 1~4주 (가장 일반적: 2주) 이 기간 동안 제품의 "완료" 증분이 생성됩니다.
📅 스프린트 규칙
- 고정 기간: 모든 스프린트에 대해 항상 동일한 길이
- 스프린트 목표: 명확하고 공유된 목표
- 변경사항 없음: 스프린트(포커스) 중에는 범위가 변경되지 않습니다.
- 품질: 완료의 정의는 손상되지 않습니다.
- 해제: PO만이 스프린트를 취소할 수 있습니다(드물게!)
2. 스프린트 계획
시간 상자: 1개월 스프린트당 최대 8시간(더 짧은 스프린트의 경우 비례 배분)
참가자들: 전체 스크럼 팀(PO, SM, Dev Team).
스프린트 계획 - 2파트
🔵 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. 일일 스크럼(스탠드업)
시간 상자: 15분(고정!)
참가자들: 개발팀(필수), SM시설, PO는 선택사항입니다.
언제: 매일 같은 시간, 같은 장소.
🗣️ 3가지 고전적인 질문
각 팀원은 다음과 같이 응답합니다.
- 내가 어제 한 일 그것이 팀의 스프린트 목표 달성에 도움이 되었나요?
- 오늘은 무엇을 할 것인가? 스프린트 목표를 향해 팀을 돕기 위해?
- 나에겐 장애물이 있다 그게 나 아니면 팀을 막나요?
❌ 일일 스크럼 안티 패턴
- 관리자에게 상태 보고: 계층적 보고가 아닙니다!
- 확장된 문제 해결: 매일은 문제 해결을 위한 것이 아니라 동기화를 위한 것입니다(회의 후)
- 지속 시간 > 15분: 시간 상자는 신성하고, 일상 밖의 토론
- 발표자만 스크럼 마스터입니다. 팀 대화여야 합니다.
- 서 있거나 앉아 있는 사람: 서서 하는 회의는 짧게 하는 데 도움이 된다
4. 스프린트 검토
시간 상자: 1개월 스프린트의 경우 최대 4시간(예: 2주 스프린트의 경우 2시간).
참가자들: 스크럼 팀 + 이해관계자 + 고객.
🎬 스프린트 일정 검토
- 오프닝(5분): PO는 스프린트 목표와 계획을 기억합니다.
- 데모(60%): 팀에서 작동하는 소프트웨어를 보여줍니다(라이브 데모, 슬라이드 없음!)
- DoD에 따르면 "완료" 기능만 제공됩니다.
- 스테이징/프로덕션과 유사한 환경
- 대화형: 이해관계자가 제품을 사용해 봅니다.
- 피드백(30%): 이해관계자가 의견을 제공합니다.
- 무엇이 잘 작동합니까?
- 무엇이 빠졌거나 변경해야 합니까?
- 새로운 아이디어가 떠올랐다
- 제품 백로그 업데이트(10%): 통찰력으로 PO 업데이트 백로그
데모 스크립트 예
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. 스프린트 회고전
시간 상자: 1개월 스프린트의 경우 최대 3시간(예: 2주 스프린트의 경우 1.5시간)
참가자들: 스크럼 팀만 해당(PO, SM, 개발 팀). 외부 이해관계자 없음!
언제: 스프린트 검토 후, 다음 계획 전.
🔄 회고적 목표
델 검사 및 조정 작업 과정 (제품이 아닙니다.) 초점:
- 무엇이 잘 되었나요? (계속하세요)
- 무엇이 잘못되었나요? (그만해)
- 무엇을 개선할 수 있나요? (하기 시작하다)
회고적 기법
🎯 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🛡️ 소급 규칙
- 안전한 공간: 뒤에서 한 말은 뒤에 남는다
- 비난하지 마세요: 사람이 아닌 프로세스에 집중
- 정직: 말해보세요! 이제 개선할 시간이다
- 행동 지향: 불만뿐만 아니라 솔루션도
- 후속 조치: 이전 스프린트의 작업 항목 검토
스크럼의 3가지 아티팩트
1. 제품 백로그
목록 질서있고 역동적인 제품에 필요한 모든 작업을 수행합니다. 제품 소유자가 소유합니다.
📚 제품 백로그 기능
- 주문됨(우선순위 아님): 단일 시퀀스, 상단 = 다음 스프린트
- 나타나는: 지속적으로 발전하지만 결코 '완전'하지 않습니다.
- 적절하게 자세히 설명: 디테일한 상의 아이템, 애매한 하의
- 추정된: 스토리 포인트 또는 기타 관련 지표
- 투명한: 모든 사람에게 공개
제품 백로그 예
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. 스프린트 백로그
현재 스프린트에 대해 선택된 제품 백로그의 하위 집합 + 이를 제공할 계획입니다. 개발팀이 소유합니다.
📋 스프린트 백로그 콘텐츠
- 선택된 사용자 스토리
- 세부기술과제
- 스프린트 목표
- 시행계획
- 각 작업의 실시간 상태
🔄 업데이트
- 매일 팀에서 업데이트
- 새로운 임무가 나타날 수도 있다
- 팀만 편집할 수 있습니다.
- 기내에서 볼 수 있음(물리적/디지털)
- 번다운 차트는 여기에서 나옵니다.
3. 증분
스프린트 동안 완료된 모든 제품 백로그 항목의 합계 + 값 모든 이전 스프린트의 증가. 그래야만 해 "완료" 완료의 정의에 따르면.
✅ 완료(DoD)의 정의
작업이 완료된 것으로 간주되는 시기에 대한 공유되고 명확한 기준. 협상 불가능!
완료의 정의 예
📋 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 produzione완전한 스프린트 흐름
스프린트 일정 2주(예)
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...일반적인 스크럼 안티 패턴
🚫 피해야 할 실수
1. 스크럼 버(Scrum But)
징후: "우리는 스크럼을 수행하지만... [예외]"
- “스크럼이지만 데일리 스크럼은 없습니다” → 스크럼이 아닙니다
- “스크럼이지만 회고 없이” → 절대 개선되지 않습니다
- “Scrum but PO not available” → 팀이 지속적으로 차단됨
2. 미니 폭포로 스프린트
문제: 스프린트의 모든 단계가 순차적으로 이루어짐
❌ BAD: Sprint = Design → Dev → Test → Deploy (waterfall!)
✅ GOOD: Sprint = Iterate su features, ogni feature Done completamente3. 스프린트 목표가 없거나 모호함
문제: 스프린트는 일관된 목표가 없는 "작업 목록"일 뿐입니다.
- ❌ 나쁨: "스토리 45, 46, 47, 48을 완료하세요."
- ✅ 좋음: "사용자가 등록 없이 구매를 완료할 수 있습니다."
4. 고정 약속으로서의 속도
문제: 경영진은 팀에 압력을 가하기 위해 속도를 사용합니다.
- 속도는 도달 목표가 아니라 계획을 위한 척도입니다!
- 압력을 받고 있는 팀은 추정치를 부풀려 → 속도가 의미를 잃음
5. 제품 소유자 대리인
문제: PO에는 권한이 없으며 항상 "질문"해야 합니다.
- 느린 결정
- 팀이 차단됨
- 해결책: PO에 권한을 부여하거나 사람을 바꾸십시오.
대규모 스크럼
조직에 스크럼 팀이 많으면 조정을 위한 프레임워크가 필요합니다. 3가지 주요 항목:
🏢 SAFe(확장형 애자일 프레임워크)
- 기업용으로 가장 널리 사용되는 프레임워크
- 4가지 레벨: 팀, 프로그램, 대규모 솔루션, 포트폴리오
- 8~12주의 프로그램 증분(PI)
- Agile Release Train(ART): 50~125명
- 장점: 구조화되어 있고 문서화되어 있으며 대규모 조직에 적합합니다.
- 단점: 순수 스크럼보다 무겁고 덜 민첩함
🪜 LeSS(대규모 스크럼)
- 다중 팀 스크럼(2~8개 팀)
- 모든 팀에 제품 소유자 1명
- 1 공유 제품 백로그
- 동기화된 스프린트
- 전체 회고적 팀 간
- 장점: 스크럼을 단순하게 유지합니다.
- 단점: 높은 Agile 성숙도가 필요함
🔗 넥서스
- 3~9개 팀을 위한 Scrum.org 프레임워크
- Nexus 통합팀 좌표
- Nexus Sprint 계획, 검토, 회고
- 지속적인 통합에 집중
- 찬성: Scrum.org 공식
- 단점: 최대 100명으로 제한
유용한 스크럼 측정항목
📊 프로세스 측정항목
- 속도: 스토리 포인트/스프린트
- 스프린트 번다운: 남은 작업
- 릴리스 번업: 출시 진행 상황
- 주기 시간: 타임스토리 → 완료
🎯 품질 지표
- 결함률: 스프린트 관련 버그
- 코드 적용 범위: % 코드 테스트됨
- 기술 부채: 리팩토링 노력
- 팀 행복: 분기별 조사
결론
스크럼은 단순하지만 강력한 구조 민첩한 개발을 위해. 성공의 열쇠는엄격한 채택 프레임워크의 (스크럼은 아니지만!) 와 결합 지속적인 점검과 적응.
💡 핵심 포인트
- 스크럼에는 3가지 역할, 5가지 이벤트, 3가지 아티팩트가 있으며 모두 필수입니다.
- 제품 소유자는 가치를 극대화하고, 스크럼 마스터는 용이하게 하고, 개발팀은 제공합니다.
- 스프린트는 명확한 목표가 있는 정해진 주기(1~4주)입니다.
- 완료의 정의는 협상할 수 없는 품질 기준입니다.
- 회고는 지속적인 개선의 원동력입니다
- 투명성, 검사, 적응은 3대 기둥입니다.
- Scrum at Scale에는 추가 프레임워크(SAFe, LeSS, Nexus)가 필요합니다.
📚 다음 기사
다음 기사에서는 살펴보겠습니다. 칸반 방법: 연속 흐름 시스템 WIP 제한, 칸반 보드, 흐름 지표(리드 타임, 주기 시간) 및 스크럼과의 비교.