betting-analytics/docs/04-fase-backlog/DEFINITION-OF-READY.md
rckrdmrd 094493625c feat: Documentation and orchestration updates
🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-07 05:35:34 -06:00

228 lines
5.4 KiB
Markdown

---
id: "DOR-BA"
title: "Definition of Ready - Betting Analytics"
type: "Process"
status: "Approved"
version: "1.0.0"
created_date: "2026-01-04"
updated_date: "2026-01-04"
---
# Definition of Ready (DoR) - Betting Analytics
---
## 1. PROPOSITO
La Definition of Ready establece los criterios que un item del backlog debe cumplir ANTES de poder ser incluido en un Sprint. Garantiza que el equipo tenga toda la informacion necesaria para estimar y ejecutar el trabajo.
---
## 2. CRITERIOS GENERALES
### 2.1 Claridad
| Criterio | Descripcion | Obligatorio |
|----------|-------------|-------------|
| **Titulo descriptivo** | El titulo refleja claramente el objetivo | Si |
| **Descripcion completa** | Problema y solucion documentados | Si |
| **Sin ambiguedades** | Sin preguntas abiertas bloqueantes | Si |
| **Lenguaje entendible** | Cualquier agente puede entenderlo | Si |
### 2.2 Criterios de Aceptacion
| Criterio | Descripcion | Obligatorio |
|----------|-------------|-------------|
| **Definidos** | Al menos 2 criterios de aceptacion | Si |
| **Medibles** | Pueden ser verificados objetivamente | Si |
| **Completos** | Cubren el alcance del item | Si |
### 2.3 Alcance
| Criterio | Descripcion | Obligatorio |
|----------|-------------|-------------|
| **Scope delimitado** | Bordes claros del trabajo | Si |
| **Tamano adecuado** | Completable en 1 Sprint | Si |
| **Independiente** | Minimas dependencias externas | Deseable |
### 2.4 Dependencias
| Criterio | Descripcion | Obligatorio |
|----------|-------------|-------------|
| **Identificadas** | Todas las dependencias listadas | Si |
| **Resueltas** | Dependencias bloqueantes resueltas | Si |
| **Ordenadas** | Secuencia de trabajo clara | Deseable |
### 2.5 Estimacion
| Criterio | Descripcion | Obligatorio |
|----------|-------------|-------------|
| **Story Points** | Estimacion en SP asignada | Si |
| **Complejidad** | Complejidad evaluada (baja/media/alta) | Si |
| **Riesgos** | Riesgos identificados | Deseable |
---
## 3. CRITERIOS POR TIPO
### 3.1 User Story (US)
```markdown
## Checklist DoR - User Story
### Claridad
- [ ] Tiene formato "Como [rol], quiero [accion], para [beneficio]"
- [ ] Contexto de negocio documentado
- [ ] Sin preguntas abiertas
### Criterios de Aceptacion
- [ ] Minimo 2 criterios de aceptacion
- [ ] Criterios verificables y medibles
- [ ] Escenarios edge-case considerados
### Alcance
- [ ] Scope claramente delimitado
- [ ] Tamano <= 13 SP (o dividir)
- [ ] Puede completarse en 1 Sprint
### Dependencias
- [ ] US dependientes identificadas
- [ ] APIs/servicios externos disponibles
- [ ] Datos de prueba disponibles
### Estimacion
- [ ] Story Points asignados
- [ ] Complejidad evaluada
- [ ] Tareas tecnicas identificadas
### Documentacion
- [ ] YAML front-matter completo
- [ ] Epic asignada
- [ ] Labels apropiados
```
### 3.2 Task (TASK)
```markdown
## Checklist DoR - Task
- [ ] Descripcion clara del trabajo tecnico
- [ ] Resultado esperado definido
- [ ] Estimacion en horas
- [ ] Dependencias tecnicas identificadas
- [ ] YAML front-matter completo
```
### 3.3 Bug (BUG)
```markdown
## Checklist DoR - Bug
- [ ] Descripcion del error
- [ ] Pasos para reproducir
- [ ] Comportamiento esperado vs actual
- [ ] Severidad asignada
- [ ] Modulo afectado identificado
- [ ] Evidencia (logs, screenshots)
```
---
## 4. PROCESO DE VALIDACION
### 4.1 Quien Valida
| Item | Validador Principal | Validador Secundario |
|------|---------------------|----------------------|
| US | @PO-Agent | @Tech-Lead-Agent |
| Task | @Tech-Lead-Agent | @Backend-Agent |
| Bug | @QA-Agent | @Backend-Agent |
### 4.2 Cuando Validar
1. **Antes de Sprint Planning:** Revisar items candidatos
2. **Durante Refinement:** Detallar items del backlog
3. **Al crear item:** Verificar checklist inicial
### 4.3 Como Validar
1. Revisar checklist correspondiente al tipo
2. Verificar que todos los obligatorios estan completos
3. Marcar item como "Ready" en Board.md
4. Mover a columna "Por Hacer" si aplica
---
## 5. YAML FRONT-MATTER REQUERIDO
### User Story Ready
```yaml
---
id: "US-BA-XXX"
title: "Titulo descriptivo"
type: "User Story"
status: "To Do" # Indica que paso DoR
priority: "Alta"
epic: "BA-XXX"
story_points: X
labels: ["modulo", "feature"]
created_date: "YYYY-MM-DD"
updated_date: "YYYY-MM-DD"
ready_date: "YYYY-MM-DD" # Fecha que paso DoR
---
```
---
## 6. EXCEPCIONES
### Cuando se puede relajar DoR
| Situacion | Criterios relajables | Aprobador |
|-----------|---------------------|-----------|
| Bug Critico (P0) | Estimacion | @PO-Agent |
| Spike/Investigacion | Criterios de aceptacion | @Tech-Lead |
| Hotfix | Documentacion completa | @PO-Agent |
### Documentar Excepciones
Agregar al item:
```markdown
## Excepcion DoR
**Fecha:** YYYY-MM-DD
**Aprobador:** @Agente
**Criterios omitidos:** [lista]
**Razon:** [justificacion]
```
---
## 7. METRICAS
### KPIs de DoR
| Metrica | Target | Actual |
|---------|--------|--------|
| % Items que pasan DoR | 100% | - |
| Items rechazados por Sprint | <2 | - |
| Tiempo promedio de refinement | <2h | - |
---
## 8. REFERENCIAS
- **DoD:** [DEFINITION-OF-DONE.md](./DEFINITION-OF-DONE.md)
- **Board:** [../planning/Board.md](../planning/Board.md)
- **Config:** [../planning/config.yml](../planning/config.yml)
- **AGENTS:** [../../AGENTS.md](../../AGENTS.md)
---
**Documento:** Definition of Ready
**Proyecto:** Betting Analytics
**Version:** 1.0.0
**Fecha:** 2026-01-04
**Estado:** Approved