Niveles de trabajo

El issue: la unidad central

Todo el trabajo del equipo existe como issue en Linear. Sin excepción. Lo que varía es si ese issue tiene un padre (proyecto) y si tiene hijos (sub-issues).

Cuándo existe un proyecto padre

Un proyecto agrupa issues que comparten un objetivo de negocio común. No es una carpeta administrativa — es una iniciativa con criterio de éxito definido, fecha estimada y un PRD que la respalda.

| Tipo de issue | ¿Tiene proyecto padre? | Por qué | |---|---|---| | Feature | ✅ Siempre | Toda nueva funcionalidad pertenece a una iniciativa con objetivo de negocio | | Deuda técnica | A veces | Si es parte de una refactorización mayor, sí. Si es un ajuste técnico puntual, no | | Ajuste | ❌ Nunca | Es un cambio sobre algo existente, sin discovery. No justifica una iniciativa | | Bug | ❌ Nunca | Tiene su propio flujo por SLA. No pertenece a ninguna iniciativa | | Fast track | ❌ Nunca | Por definición es trabajo urgente y puntual. No tiene iniciativa asociada |

Cuándo existen sub-issues hijos

Un sub-issue representa un paso técnico concreto dentro de la implementación de un issue. No tiene valor independiente para el usuario — es la descomposición interna del trabajo de desarrollo.

| Situación | ¿Usar sub-issues? | Alternativa | |---|---|---| | Issue que toca más de una capa (front + back, back + DB) | ✅ Sí | — | | Issue con más de un desarrollador involucrado | ✅ Sí | — | | Issue compleja, estimación mayor a un día | ✅ Sí | — | | Issue mediana, un solo desarrollador, uno o dos días | Opcional | Checklist en el description del issue | | Ajuste, fast track o bug simple | ❌ No | El issue solo es suficiente |

Cuando se usan, los sub-issues los genera el desarrollador asignado durante la planificación técnica, generalmente con apoyo de herramientas de IA en modo plan. El desarrollador revisa y ajusta; el Líder técnico valida antes de arrancar.

El mapa completo

Combinando ambas dimensiones, estos son los casos posibles:

| Caso | Proyecto | Issue | Sub-issues | Ejemplo | |---|---|---|---|---| | Feature compleja | ✅ | ✅ | ✅ | Nuevo motor de búsqueda → issue de integración con API → sub-issues por capa | | Feature simple | ✅ | ✅ | ❌ | Sitio SEO → issue de página de destino individual | | Deuda técnica mayor | ✅ | ✅ | ✅ | Migración Strapi → issue de migración de contenidos → sub-issues por modelo | | Deuda técnica puntual | ❌ | ✅ | ❌ | Actualizar dependencia crítica | | Ajuste | ❌ | ✅ | ❌ | Cambiar texto de botón de pago | | Bug complejo | ❌ | ✅ | ✅ | Bug en motor de reservas que toca front y back | | Bug simple | ❌ | ✅ | ❌ | Error de validación en formulario | | Fast track | ❌ | ✅ | ❌ | Banner de promoción urgente |

Reglas de la jerarquía

El issue siempre existe. No hay trabajo sin issue en Linear. Ni los fast tracks, ni los bugs menores, ni los ajustes de una línea se hacen sin issue.

El proyecto no es una carpeta. Un proyecto existe cuando hay un objetivo de negocio que justifica agrupar trabajo bajo un criterio de éxito común. Si eso no existe, no hay proyecto.

Los sub-issues son decisión del desarrollador, no del PO. El PO define qué y para qué. El desarrollador decide cómo descomponer la implementación. El Líder técnico valida esa descomposición antes de arrancar.

El PO ve y gestiona issues. Los desarrolladores trabajan con sub-issues. El Líder técnico y el CPTO ven ambos niveles.