Criterios de creación de tickets

Cómo y cuándo crear tickets para optimizar la gestión de tareas.

📝 Estructura base: Un ticket por página

Regla principal

Crear un ticket principal por cada página del sitio/proyecto.

✅ Ejemplos correctos:

• Ticket #15: Page - Homepage
• Ticket #16: Page - About Us
• Ticket #17: Page - Contact
• Ticket #18: Page - Product Detail

❌ Ejemplos incorrectos:

• Ticket #15: Home - Header
• Ticket #16: Home - Hero
• Ticket #17: Home - Features
• Ticket #18: Home - Footer

Rationale

¿Por qué un ticket por página?

• Claridad: Fácil de entender el scope
• Ownership: Un responsable por página completa
• Timeline: Alineado con estimaciones del Gantt
• Testing: QA integral de toda la página
• Client review: Presentación coherente al cliente

🎯 Subtickets por módulo (si amerita)

Estructura de subtickets

Ejemplo para Homepage:

Ticket #15: Homepage
├── Subtask #15.1: Hero Section + Navigation
├── Subtask #15.2: Features Section
├── Subtask #15.3: Testimonials Carousel
├── Subtask #15.4: CTA Section + Footer

Guidelines para subtickets

✅ Crear subticket cuando:

• El módulo requiere mucho trabajo
• Tiene lógica/interacciones complejas independientes
• Puede ser trabajado por diferentes personas
• Requiere validaciones específicas del cliente
• Se necesita adjuntar documentación específica

❌ No crear subticket cuando:

• Es un componente simple
• Depende completamente de otros módulos
• No aporta valor en el tracking

📋 Template de ticket

Información básica

# [Página/Feature Name] -

## 📋 Descripción

Descripción clara de qué incluye este ticket.

## 🎯 Objetivos

- [ ] Objetivo específico 1
- [ ] Objetivo específico 2
- [ ] Objetivo específico 3

## 📐 Scope incluido

- Diseño responsive
- Funcionalidades específicas
- Integraciones necesarias
- Estados y edge cases

## ❌ Scope excluido

- Funcionalidades que NO están incluidas
- Integraciones que se harán en otro ticket
- Optimizaciones que están fuera de scope

## 🔗 Dependencias

- [ ] Ticket #X debe estar completo
- [ ] Assets del cliente necesarios
- [ ] API endpoints disponibles

## ✅ Criterios de aceptación

- [ ] Funcionalidad X implementada
- [ ] Responsive en todos los breakpoints
- [ ] Performance satisfactorio
- [ ] Cross-browser testing completo
- [ ] Accesibilidad básica implementada

## 📎 Recursos

- [Link a diseños en Figma]
- [Documentación adicional]
- [Referencias técnicas]

🔄 Cierre de tickets base

Criterio de cierre

Un ticket se cierra cuando:

1. ✅ Se cumple el objetivo principal (página funcionando)
2. ✅ Pasa todas las instancias de QA
3. ✅ Está dentro del tiempo estimado del Gantt
4. ✅ Cliente ha validado (si aplica)

Timeline esperado

Ejemplos de duración según Gantt:

• Homepage: 2 sem desktop + 1 sem mobile + 1 sem QA = 4 semanas máximo
• About Us: 1 sem desktop + 3 días mobile + 2 días QA = 2 semanas máximo
• Contact: 3 días desktop + 2 días mobile + 1 día QA = 1 semana máximo

🆕 Tickets adicionales

Cuándo crear tickets nuevos

Después del cierre del ticket principal, crear nuevos tickets para:

• Bugs encontrados post finalizar tarea principal
• Optimizaciones de performance
• Features adicionales solicitadas por cliente
• Refactoring técnico
• Integraciones adicionales

Naming convention para tickets adicionales

# Tickets principales
Ticket #15: Homepage

# Tickets adicionales (post-cierre)
Ticket #25: Fix Homepage Hero - Button Component
Ticket #26: Homepage Performance Optimization
Ticket #27: Homepage - Add Newsletter Integration

Linking y traceabilidad

Siempre linkear tickets relacionados:

• Ticket original → Tickets de fixes/mejoras
• Issues encontrados → Tickets de resolución
• Features adicionales → Ticket base donde se implementan

Ejemplo de documentación:

## Related tickets

- **Originates from:** #15 (Homepage)
- **Blocks:** #30 (Newsletter Campaign Setup)
- **Related:** #28 (Global Button Component Update)

🎯 Best practices

Para PMs al crear tickets

1. 📝 Ser específico: Describir exactamente qué incluye y qué no
2. 🔗 Linkear recursos: Figma, documentación, referencias
3. 👥 Asignar responsables: Claridad desde el inicio
4. 📋 Definir criterios: Qué significa "done" para este ticket

Para contributors al trabajar tickets

1. 📖 Leer completamente: Entender scope y criterios antes de empezar
2. ❓ Preguntar dudas: Clarificar antes de asumir
3. ⏱️ Estimar realisticamente: Usar datos históricos
4. 📊 Actualizar progreso: Mantener ticket actualizado
5. 🚨 Comunicar bloqueos: Escalation temprana de problemas
6. ✅ Validar criterios: Verificar que se cumple todo antes de marcar como completo

📝 Buenos criterios de creación de tickets son la base de una gestión de proyecto eficiente y predecible.