inmobiliaria-analytics/docs/04-fase-backlog/DEFINITION-OF-READY.md

id	title	type	version	status	created_date	updated_date
DOR-IA	Definition of Ready - Inmobiliaria Analytics	Process Document	1.0.0	Active	2026-01-04	2026-01-04

Definition of Ready (DoR)

Inmobiliaria Analytics

---

Proposito

Define los criterios que debe cumplir un item (User Story, Task, Bug) para ser considerado "listo" para trabajar en un Sprint.

---

Checklist General

Un item esta Ready cuando cumple TODOS los siguientes criterios:

Claridad

• Titulo claro y descriptivo

  • El titulo describe la funcionalidad o tarea en pocas palabras
  • Cualquier miembro del equipo entiende de que se trata

• Descripcion completa

  • Problema o necesidad documentada
  • Contexto de negocio explicado
  • Sin ambiguedades en el lenguaje

• Criterios de aceptacion definidos

  • Minimo 3 criterios verificables
  • Escritos en formato "Dado/Cuando/Entonces" o lista clara
  • Cada criterio es medible y testeable

Alcance

• Scope delimitado

  • Limites claros de lo que incluye y NO incluye
  • Tamano adecuado para completar en un Sprint
  • No mas de 13 Story Points

• Dependencias identificadas

  • Lista de items que deben completarse antes
  • APIs o servicios externos requeridos
  • Datos o recursos necesarios

• Bloqueantes resueltos

  • No hay impedimentos conocidos
  • Accesos y permisos disponibles
  • Ambientes listos

Estimacion

• Story Points asignados

  • Estimacion del equipo (Planning Poker si aplica)
  • Consenso del equipo

• Complejidad evaluada

  • Riesgos tecnicos identificados
  • Incertidumbre documentada

Documentacion

• YAML front-matter completo

  • id, title, status, epic, story_points (para US)
  • priority, assignee (si aplica)
  • created_date

• Referencias vinculadas

  • RF asociado existe (para US)
  • ET existe si aplica (para implementacion tecnica)
  • Mockups/wireframes disponibles (si hay UI)

---

Checklist por Tipo

User Story

- [ ] Formato "Como [rol], quiero [funcionalidad], para [beneficio]"
- [ ] EPIC asignada
- [ ] Criterios de aceptacion (minimo 3)
- [ ] Story Points estimados
- [ ] Dependencias identificadas
- [ ] RF asociado

Task

- [ ] Descripcion tecnica clara
- [ ] Horas estimadas
- [ ] Prioridad asignada (P0-P3)
- [ ] US padre identificada (si aplica)
- [ ] Subtareas desglosadas (si >4 horas)

Bug

- [ ] Pasos para reproducir (minimo 3 pasos)
- [ ] Comportamiento esperado
- [ ] Comportamiento actual
- [ ] Severidad asignada (P0-P3)
- [ ] Modulo afectado identificado
- [ ] Screenshots/logs adjuntos

---

Proceso de Validacion

1. Autor crea el item con todos los campos
2. Autor completa checklist de DoR
3. PO/Tech Lead revisa el item
4. Si cumple DoR → Puede entrar al Sprint
5. Si NO cumple → Regresa a Backlog con feedback

---

Excepciones

Solo se permiten excepciones para:

1. Hotfixes P0: Items criticos que afectan produccion
2. Spikes: Investigaciones tecnicas time-boxed
3. Deuda tecnica critica: Aprobada por Tech Lead

En estos casos, documentar razon de excepcion en el item.

---

Metricas

Metrica	Objetivo
Items que cumplen DoR	>90%
Items rechazados por DoR	<10%
Tiempo promedio para cumplir DoR	<2 dias

---

Referencias

• DEFINITION-OF-DONE.md
• Board.md
• config.yml

---

Documento: Definition of Ready Version: 1.0.0 Estado: Active Ultima actualizacion: 2026-01-04