Skip to main content
  • Send to AI

Flujo de Refinamiento de Tickets - Product Owner

Objetivo​

Asegurar que cada ticket llegue a Development con una definición completa, entendible, accionable y profunda, minimizando ambigüedades y retrabajos.

🎯 Flujo Completo de Refinamiento​

📅 Timing Semanal Sugerido​

DíaActividadDuraciónParticipantes
Lunes AMPre-trabajo30-45 minGonza solo
Lunes PMProduct Alignment60 minNico + Ce + (Lara si es customer-facing)
Martes AMCheck con Lara15 min o asyncGonza + Lara
Martes PMTechnical Refinement45 minGonza + Nacho
Miércoles AMFinalización + Check DoR30 minGonza solo
Miércoles PMBacklog Refinement60-90 minEquipo completo

📋 Fase 1: Pre-trabajo (Gonza - Solo)​

Objetivo​

Llegar preparado a Product Alignment con contexto completo y preguntas específicas.

Actividades​

1. Research de Contexto​

  • Revisar feedback de clientes relacionado en Slack/Linear
  • Buscar issues relacionados en el backlog
  • Revisar métricas relevantes (si aplica)
  • Identificar dependencias con otros proyectos del roadmap

2. Draft Inicial del Ticket​

Crear el ticket en Linear con:

  • Título descriptivo
  • Descripción básica del problema/oportunidad
  • User story en borrador (As a... I want... So that...)
  • Casos de uso identificados (mínimo 2-3)
  • Links a referencias (otros tickets, Slack threads, docs)

3. Preparar Preguntas​

Documentar en el ticket o en notas:

  • Para Nico: Validaciones de negocio, prioridad, scope
  • Para Ce: Necesidades de diseño, referencias visuales
  • Para Lara: Pain points conocidos, edge cases frecuentes

Template: Pre-trabajo Notes​

## Pre-trabajo - [Título del Ticket]

### Contexto Investigado

- Origen: [cliente X solicitó / bug reportado / métrica Y baja]
- Referencias: [links]
- Impacto estimado: [usuarios afectados / revenue / etc]

### Draft User Story

**Como** [tipo de usuario]
**Quiero** [acción/funcionalidad]
**Para** [beneficio/objetivo]

### Casos de Uso Identificados

1. [Caso feliz]
2. [Edge case A]
3. [Error scenario B]

### Preguntas para Alignment

**Nico:**

- ¿Scope inicial vs futuro?
- ¿Qué NO entra en este ticket?

**Ce:**

- ¿Tenemos referencia visual?
- ¿Impacta design system?

**Lara:**

- ¿Cuántos tickets de soporte relacionados?
- ¿Edge cases conocidos?

🎨 Fase 2: Product Alignment Meeting​

Participantes​

  • Obligatorio: Gonza + Nico + Ce
  • Opcional: Lara (si es feature customer-facing o con historial de issues)

Duración​

60 minutos

Agenda​

Primera Parte (20 min): Contexto y Problema​

  1. Gonza presenta (5 min):

    • Contexto investigado
    • Draft de user story
    • Casos de uso identificados

  2. Nico valida (10 min):

    • Alcance del proyecto
    • Prioridad vs roadmap
    • Qué NO entra (out of scope)
    • Métricas de éxito

  3. Ce aporta (5 min):

    • Necesidades de diseño
    • Impacto en design system
    • Referencias visuales existentes

Segunda Parte (30 min): Definición​

  1. Refinamiento colaborativo:

    • User stories finales
    • Flujos de usuario (happy path + edge cases)
    • Criterios de aceptación
    • UX considerations

  2. Lara aporta (si está presente):

    • Pain points recurrentes
    • Edge cases de soporte
    • Impacto esperado en tickets

Tercera Parte (10 min): Acciones​

  1. Next steps claros:
    • ¿Ce necesita crear mockups? ¿Cuándo?
    • ¿Lara necesita validar algo adicional?
    • ¿Documentación de producto necesaria?
    • ¿Cuándo va a Technical Refinement?

Output Esperado​

  • User stories finalizadas
  • Criterios de aceptación claros
  • Scope bien definido (in/out)
  • Métricas de éxito acordadas
  • Mockups solicitados (si aplica)

💬 Fase 3: Check con Lara (Support)​

¿Cuándo incluir esta fase?​

SÍ incluir si:

  • Feature es customer-facing
  • Hay historial de issues de soporte relacionados
  • Cambio en flujo de usuario existente
  • Potencial impacto en carga de soporte

NO incluir si:

  • Trabajo puramente técnico/interno
  • Refactor sin cambio de UX
  • Lara ya participó en Product Alignment

Formato​

Opción A: Async (preferido para validaciones simples)​

Slack thread con estructura:

Hey @Lara, necesito tu input en este ticket: [link]

**Contexto:** [1-2 líneas]

**Preguntas específicas:**

1. ¿Cuántos tickets de soporte tenemos relacionados a [X]?
2. ¿Qué edge cases ves con frecuencia en [Y]?
3. ¿Este cambio reducirá tickets de tipo [Z]?

**Deadline:** Necesito respuesta antes de [día] para refinar con Nacho.

Opción B: Sync (15 min para casos complejos)​

Agenda:

  1. Contexto rápido (3 min)
  2. Pain points conocidos (5 min)
  3. Edge cases frecuentes (5 min)
  4. Impacto en soporte (2 min)

Documentar en el Ticket​

Agregar sección en Linear:

## Insights de Support

### Pain Points Conocidos

- [Problema frecuente 1]
- [Problema frecuente 2]

### Edge Cases Reportados

- [Caso A: descripción + frecuencia]
- [Caso B: descripción + frecuencia]

### Impacto Esperado

- **Tickets reducidos:** [tipo X, estimado -N%]
- **Nuevos tipos de tickets:** [tipo Y probable]
- **Documentación necesaria:** [Help Center article sobre Z]

**Validado con:** Lara - [fecha]

🔧 Fase 4: Technical Refinement (Nacho)​

Participantes​

  • Gonza + Nacho

Duración​

45 minutos

Pre-requisitos​

  • Product Alignment completado
  • Mockups disponibles (si aplicaba)
  • Support input obtenido (si aplicaba)

Agenda​

Parte 1: Contexto (10 min)​

  1. Gonza presenta:

    • User stories finales
    • Criterios de aceptación
    • Mockups (si hay)
    • Insights de Support

  2. Nacho lee y procesa:

    • Revisión silenciosa
    • Preguntas de clarificación

Parte 2: Approach Técnico (25 min)​

  1. Nacho propone:

    • Approach técnico general
    • Componentes/archivos involucrados
    • Dependencias técnicas
    • Consideraciones de:
      • Performance
      • Security
      • Scalability
      • Maintainability

  2. Identificar:

    • Riesgos técnicos
    • Alternativas (pros/cons)
    • Trabajo preparatorio necesario
    • Tests strategy

  3. Decisión sobre complejidad:

    • ¿Necesita Spike ticket de investigación?
    • ¿Se puede estimar o hay mucha incertidumbre?
    • ¿Hay que dividir en subtasks?

Parte 3: Validación (10 min)​

  1. Gonza valida:

    • Approach alineado con expectativas de negocio
    • Scope técnico vs scope de producto
    • Timeline realista

  2. Acuerdos finales:

    • Approach aprobado
    • Riesgos aceptados
    • Next steps claros

Output Esperado​

Documentar en el ticket:

## Technical Context

### Approach Propuesto

[Descripción del approach técnico en 2-3 párrafos]

### Componentes Involucrados

- `path/to/component.php` - [qué se modifica]
- `path/to/another.ts` - [qué se crea]
- Database: `table_name` - [qué columnas se agregan]

### Dependencias Técnicas

- [ ] [Dependencia 1: descripción]
- [ ] [Dependencia 2: descripción]

### Consideraciones Especiales

**Performance:** [consideraciones]
**Security:** [consideraciones]
**Scalability:** [consideraciones]

### Riesgos Técnicos

1. **[Riesgo A]**
   - Probabilidad: Alta/Media/Baja
   - Impacto: Alto/Medio/Bajo
   - Mitigación: [estrategia]

### Alternativas Consideradas

**Opción B:** [descripción]

- ❌ Descartada porque: [razón]

**Opción C:** [descripción]

- ❌ Descartada porque: [razón]

### Test Strategy

- Unit tests: [qué cubrir]
- Integration tests: [qué cubrir]
- Manual QA: [escenarios críticos]

### Estimación de Complejidad

**Tamaño:** S / M / L / XL
**Justificación:** [razón de la estimación]

**Validado con:** Nacho - [fecha]

¿Cuándo crear un Spike Ticket?​

Si Nacho identifica alta incertidumbre técnica:

# Spike: Investigar [Tema X]

**Time-box:** 2-4 horas max
**Owner:** [Developer asignado]

**Objetivo:**
Definir approach técnico para [feature Y]

**Preguntas a Responder:**

1. [Pregunta específica 1]
2. [Pregunta específica 2]

**Output Esperado:**

- Documento con recomendación técnica
- Pros/cons de 2-3 alternativas
- Estimación más precisa del trabajo real
- POC código (opcional)

**Criterio de Éxito:**
Poder estimar el ticket real con confianza después del spike.

✍️ Fase 5: Finalización y Definition of Ready Check​

Participantes​

  • Gonza solo

Duración​

30 minutos

Actividades​

1. Consolidar Toda la Información​

Asegurar que el ticket en Linear tiene:

  • Toda la info de Product Alignment
  • Insights de Support
  • Technical Context de Nacho
  • Mockups embebidos o linkeados
  • Links a referencias y docs

2. Validar contra Definition of Ready​

Usar el checklist completo (ver sección siguiente).

3. Escribir User Flows en Gherkin (si es complejo)​

Para features con lógica de negocio importante:

Feature: [Nombre del Feature]

  Scenario: [Happy Path]
    Given [contexto inicial]
    When [acción del usuario]
    Then [resultado esperado]
    And [validación adicional]

  Scenario: [Edge Case A]
    Given [contexto específico]
    When [acción que causa el edge case]
    Then [comportamiento esperado]

  Scenario: [Error Scenario B]
    Given [precondiciones]
    When [acción que causa error]
    Then [manejo de error esperado]

4. Crear Subtasks (si aplica)​

Para tickets grandes (L/XL), dividir en subtasks accionables:

## Subtasks

### Backend

- [ ] [Subtask 1: descripción específica]
- [ ] [Subtask 2: descripción específica]

### Frontend

- [ ] [Subtask 3: descripción específica]
- [ ] [Subtask 4: descripción específica]

### Testing

- [ ] [Subtask 5: tests específicos]

### Documentation

- [ ] [Subtask 6: docs específicas]

5. Preparar para Backlog Refinement​

  • Ticket cumple Definition of Ready
  • Agregar al proyecto de Backlog Refinement del miércoles
  • Notificar al equipo (Slack o Linear)
  • Preparar notas de presentación (2 min pitch)

📊 Definition of Ready (DoR) - Checklist​

✅ Sección: Producto​

  • Título claro y descriptivo

    • Formato: [Tipo]: Descripción accionable
    • Ejemplo: Bug: Mail de soporte llega en inglés o Feature: Automatically open checkout para suscripciones

  • User Stories completas

    • Formato: As a [role], I want [action], so that [benefit]
    • Mínimo 1 user story, idealmente 2-3 para diferentes roles

  • Descripción del problema/oportunidad

    • Por qué es importante resolver esto ahora
    • Contexto de negocio
    • Links a feedback de usuarios/clientes

  • Criterios de Aceptación específicos

    • Mínimo 3-5 criterios
    • Testables y no ambiguos
    • Formato: - [ ] Cuando X, entonces Y

  • Casos de uso documentados

    • Happy path
    • Mínimo 2 edge cases
    • Mínimo 1 error scenario

  • Mockups/wireframes (si aplica)

    • Embebidos en el ticket o link a Figma
    • Desktop y Mobile si es responsive
    • Estados: default, hover, active, error, loading

  • Scope definido (In/Out)

    • Qué SÍ incluye este ticket
    • Qué NO incluye (para futuras iteraciones)

  • Métricas de éxito

    • Cómo mediremos si funcionó
    • Ejemplo: "Reducción de 30% en tickets de soporte tipo X"

✅ Sección: Técnico​

  • Approach técnico validado con Nacho

    • Descripción del approach en 2-3 párrafos
    • Componentes/archivos a modificar identificados

  • Dependencias identificadas

    • Dependencias de otros tickets
    • Dependencias técnicas (APIs, servicios, etc)
    • Trabajo preparatorio necesario

  • Riesgos técnicos conocidos

    • Mínimo 1 riesgo identificado (o "Ninguno")
    • Para cada riesgo: probabilidad, impacto, mitigación

  • Consideraciones especiales documentadas

    • Performance
    • Security
    • Scalability
    • Accessibility (si es UI)

  • Test strategy definida

    • Qué tests unitarios se necesitan
    • Qué tests de integración
    • Escenarios para QA manual

  • Estimación de complejidad

    • Tamaño: S / M / L / XL
    • Justificación del tamaño

✅ Sección: Support/UX​

  • Pain points considerados

    • Input de Lara obtenido (si aplica)
    • Pain points frecuentes documentados

  • Edge cases identificados

    • De experiencia de soporte
    • De análisis de producto

  • Impacto en soporte evaluado

    • ¿Reducirá tickets? ¿Cuáles?
    • ¿Creará nuevos tipos de tickets?
    • ¿Necesita documentación en Help Center?

✅ Sección: Contexto​

  • Links a issues relacionados

    • Issues que bloquean este
    • Issues que este bloqueará
    • Issues similares resueltos antes

  • Referencias a documentación

    • Docs técnicas relevantes
    • RFCs o ADRs relacionados
    • Documentación de APIs/servicios

  • Tags apropiados

    • Labels: Bug, Feature, Improvement, etc
    • Project asignado
    • Team asignado

  • Prioridad clara

    • 0 = No priority
    • 1 = Urgent
    • 2 = High
    • 3 = Normal
    • 4 = Low

✅ Final Check​

  • El ticket es entendible por alguien que no estuvo en las reuniones
  • El ticket es accionable - un dev puede empezar a trabajar
  • El ticket es completo - no faltan definiciones críticas
  • El ticket es profundo - considera edge cases y riesgos

👥 Fase 6: Backlog Refinement (Equipo Completo)​

Participantes​

  • Equipo completo de Development
  • Gonza (facilita)
  • Nico (opcional, si hay dudas de negocio)
  • Ce (opcional, si hay dudas de diseño)

Duración​

60-90 minutos

Agenda​

Por cada ticket (10-15 min):​

  1. Presentación (Gonza - 3 min)

    • Contexto en 1 minuto
    • User story principal
    • Demo de mockups (si hay)
    • Approach técnico resumido

  2. Preguntas y Clarificaciones (5-8 min)

    • Equipo hace preguntas
    • Gonza/Nacho responden
    • Se agregan clarificaciones al ticket en vivo

  3. Validación Técnica (2-3 min)

    • ¿Alguien ve riesgos no identificados?
    • ¿Dependencias faltantes?
    • ¿Approach tiene sentido para todos?

  4. Estimación (2-3 min) (si usan story points)

    • Planning poker o similar
    • Consenso de complejidad
    • Discusión si hay discrepancias grandes

  5. Decisión Final (1 min)

    • ✅ Ready for Development
    • 🔄 Needs more refinement (qué falta específicamente)
    • ❌ Rejected/On hold (por qué)

Facilitación - Tips para Gonza​

Antes de la reunión:

  • Tickets ordenados por prioridad
  • Máximo 6-8 tickets por sesión
  • Pre-lectura compartida (enviar tickets 24h antes)

Durante la reunión:

  • ⏱️ Timeboxear estrictamente cada ticket
  • 🎯 Mantener foco en clarificaciones, no en diseñar soluciones
  • 📝 Tomar notas de cambios en vivo en Linear
  • 🚦 Parking lot para temas profundos (seguir offline)

Después de la reunión:

  • Actualizar tickets con decisiones tomadas
  • Mover tickets aprobados a "Ready for Development"
  • Agendar follow-ups para tickets que necesitan más trabajo
  • Comunicar decisiones en Slack

Red Flags - Cuándo pausar​

⚠️ PAUSAR refinamiento del ticket si:

  • Surgen más de 5 preguntas sin respuesta clara
  • Equipo identifica un riesgo técnico no considerado
  • Approach propuesto tiene desacuerdo significativo
  • Faltan mockups críticos para entender el alcance
  • Dependencias no están resueltas

Acción: Marcar ticket como "Needs more refinement" y agendar seguimiento.

📈 Métricas de Éxito del Proceso​

Track Estas Métricas Mensualmente​

1. Calidad de Refinamiento​

✅ % de tickets que pasan Backlog Refinement sin cambios mayores
   Target: >80%

   Cómo medir:
   - Tickets aprobados directamente / Total tickets presentados

2. Eficiencia​

⏱️ Tiempo promedio de refinamiento por ticket
   Target: <2 horas total (todas las fases)

   Cómo medir:
   - Sumar tiempo de todas las reuniones + pre-trabajo + finalización

3. Predictibilidad​

🔄 % de tickets que regresan a refinement post-Development
   Target: <10%

   Cómo medir:
   - Tickets que devs dicen "esto no está claro" / Total en desarrollo

4. Claridad Percibida​

💡 Score de claridad por developers
   Target: >4/5

   Cómo medir:
   - Survey trimestral: "Del 1-5, ¿qué tan claros están los tickets?"

5. Calidad en Producción​

🐛 Ratio de bugs encontrados (QA vs Production)
   Target: >10:1 (más bugs en QA = mejor refinement)

   Cómo medir:
   - Bugs encontrados en QA / Bugs encontrados en Production

Dashboard Mensual Sugerido​

## Refinement Metrics - [Mes]

### Tickets Procesados

- Total presentados: [N]
- Aprobados directamente: [N] ([%])
- Necesitaron más trabajo: [N] ([%])

### Eficiencia

- Tiempo promedio por ticket: [X] horas
- Tickets refinados por semana: [N]

### Calidad

- Tickets devueltos por devs: [N] ([%])
- Bugs QA vs Production ratio: [X:1]

### Feedback del Equipo

- Claridad promedio: [X]/5
- Comentarios: [resumen]

### Acciones de Mejora

- [ ] [Acción 1 basada en métricas]
- [ ] [Acción 2 basada en feedback]

🎯 Templates de Tickets por Tipo​

Template 1: New Feature​

# [Feature Name]

## 🎯 Objetivo

[1-2 líneas sobre el objetivo de negocio]

## 📊 Contexto y Justificación

### Por qué ahora

- [Problema que resuelve]
- [Oportunidad que aprovecha]
- [Impacto esperado en métrica X]

### Referencias

- Feedback de clientes: [link a Slack/Linear]
- Issues relacionados: [#123, #456]
- Documentación: [link]

## 👥 User Stories

### Como [Rol de usuario]

**Quiero** [acción/funcionalidad]
**Para** [beneficio/objetivo]

**Scenarios:**

- Happy path: [descripción]
- Edge case A: [descripción]
- Error scenario B: [descripción]

## 📐 Diseño

### Mockups

[Embeber imágenes o link a Figma]

### User Flows

```gherkin
Feature: [Feature Name]

  Scenario: [Happy Path]
    Given [contexto]
    When [acción]
    Then [resultado]
```

✅ Criterios de Aceptación​

Funcionalidad​

  • [Criterio específico 1]
  • [Criterio específico 2]
  • [Criterio específico 3]

User Experience​

  • [Criterio UX 1]
  • [Criterio UX 2]

Technical​

  • [Criterio técnico 1]
  • [Criterio técnico 2]

🔧 Technical Context​

Approach Propuesto​

[Descripción del approach en 2-3 párrafos]

Componentes Involucrados​

  • path/to/file.php - [qué se modifica]
  • path/to/file.ts - [qué se crea]

Dependencias​

  • [Dependencia 1]
  • [Dependencia 2]

Consideraciones​

Performance: [consideraciones] Security: [consideraciones] Accessibility: [consideraciones]

Riesgos Técnicos​

  1. [Riesgo] - Probabilidad: [Alta/Media/Baja], Impacto: [Alto/Medio/Bajo]
    • Mitigación: [estrategia]

Test Strategy​

  • Unit tests: [qué cubrir]
  • Integration tests: [qué cubrir]
  • Manual QA: [escenarios críticos]

💡 Insights de Support​

Pain Points Conocidos​

  • [Pain point 1]
  • [Pain point 2]

Edge Cases Reportados​

  • [Caso A: frecuencia]

Impacto Esperado​

  • Tickets reducidos: [tipo, estimado %]
  • Docs necesaria: [Help Center article]

🎬 Out of Scope​

[Qué NO incluye este ticket - para futuras iteraciones]

📏 Métricas de Éxito​

  • [Métrica 1: valor objetivo]
  • [Métrica 2: valor objetivo]

🔗 Links Relacionados​

  • Issues bloqueantes: [#123]
  • Issues que esto bloqueará: [#456]
  • RFC/ADR: [link]

Validaciones:

  • ✅ Product Alignment: [fecha] - Nico, Ce, Lara
  • ✅ Support Check: [fecha] - Lara
  • ✅ Technical Refinement: [fecha] - Nacho
  • ✅ Definition of Ready: [fecha] - Gonza
  • ✅ Backlog Refinement: [fecha] - Team

Complejidad: [S/M/L/XL] Prioridad: [0-4]


---

### Template 2: Bug Fix

```markdown
# Bug: [Descripción del Bug]

## 🐛 Descripción del Problema

### Comportamiento Actual
[Qué está pasando ahora - específico y observable]

### Comportamiento Esperado
[Qué debería pasar]

### Impacto
- **Severidad:** Critical / High / Medium / Low
- **Usuarios afectados:** [número o %]
- **Frecuencia:** [cuántas veces ocurre]
- **Workaround disponible:** Sí/No - [descripción]

## 📋 Steps to Reproduce

1. [Paso específico 1]
2. [Paso específico 2]
3. [Paso específico 3]

**Resultado actual:** [qué pasa]
**Resultado esperado:** [qué debería pasar]

## 🔍 Contexto Adicional

### Ambiente
- **Tenant afectado:** [nombre de tienda o "Todos"]
- **Versión:** [si aplica]
- **Browser/Device:** [si es frontend]
- **User roles afectados:** [todos o específicos]

### Reportado por
- [Cliente X vía Slack: link]
- [Support ticket #123]
- [Usuario Y: email]

### Evidencia
[Screenshots, videos, logs]

## 🔧 Análisis Técnico

### Root Cause (si se conoce)
[Descripción de la causa raíz]

### Componentes Involucrados
- `path/to/file.php` - [problema específico]

### Fix Propuesto
[Descripción del fix en 1-2 párrafos]

### Consideraciones
- **Regresión risk:** [Alto/Medio/Bajo] - [por qué]
- **Database changes:** Sí/No - [qué]
- **Requires migration:** Sí/No

## ✅ Criterios de Aceptación

- [ ] Bug no se reproduce siguiendo steps originales
- [ ] Comportamiento esperado funciona correctamente
- [ ] No hay regresiones en funcionalidad relacionada
- [ ] Tests agregar para prevenir regresión futura

## 🧪 Test Strategy

### Regression Tests
- [Escenario 1 a testear]
- [Escenario 2 a testear]

### Verificación Manual
- [ ] [Paso de verificación 1]
- [ ] [Paso de verificación 2]

## 🔗 Issues Relacionados
- Duplicados: [#123]
- Bloqueado por: [#456]
- Similar a: [#789]

---

**Prioridad:** [0-4]
**Complejidad:** [S/M/L]

Template 3: Technical Debt​

# Tech Debt: [Descripción del Problema Técnico]

## 🎯 Objetivo

[En 1-2 líneas: qué se busca mejorar y por qué importa]

## 📊 Contexto

### Estado Actual

[Descripción del código/arquitectura actual y por qué es problemático]

### Problemas que Causa

- **Performance:** [impacto específico]
- **Maintainability:** [impacto específico]
- **Developer Experience:** [impacto específico]
- **Escalabilidad:** [impacto específico]

### Costo de Mantener el Status Quo

[Qué pasa si NO hacemos esto - en términos de tiempo, bugs, features bloqueadas]

## 🔧 Propuesta de Mejora

### Enfoque

[Descripción del refactor/mejora propuesta]

### Beneficios Esperados

- [Beneficio 1: métrica mejorada]
- [Beneficio 2: métrica mejorada]

### Trade-offs

**Pros:**

- [Pro 1]
- [Pro 2]

**Cons:**

- [Con 1: cómo mitigamos]
- [Con 2: cómo mitigamos]

## 📐 Plan de Implementación

### Fase 1: [Nombre]

- [ ] [Tarea específica 1]
- [ ] [Tarea específica 2]

### Fase 2: [Nombre]

- [ ] [Tarea específica 3]
- [ ] [Tarea específica 4]

### Rollout Strategy

[Cómo se desplegará - feature flags, gradual, etc]

## 🧪 Testing & Validation

### Regression Prevention

- [Tests que debemos tener antes de empezar]

### Success Criteria

- [ ] [Criterio medible 1]
- [ ] [Criterio medible 2]

### Rollback Plan

[Qué hacemos si sale mal]

## 📏 Métricas de Éxito

**Baseline → Target:**

- [Métrica 1]: [valor actual] → [valor objetivo]
- [Métrica 2]: [valor actual] → [valor objetivo]

## 🚧 Riesgos

1. **[Riesgo 1]**
   - Probabilidad: [Alta/Media/Baja]
   - Impacto: [Alto/Medio/Bajo]
   - Mitigación: [estrategia]

## 🔗 Referencias

- RFC/ADR: [link]
- Issues relacionados: [#123]
- Documentación: [link]

---

**Complejidad:** [S/M/L/XL]
**Prioridad:** [0-4]

Template 4: Design/UX Improvement​

# UX Improvement: [Descripción]

## 🎯 Objetivo

[Qué experiencia de usuario queremos mejorar]

## 📊 Contexto

### Pain Point Actual

[Descripción del problema de UX existente]

### Evidencia

- Feedback de usuarios: [quotes o links]
- Métricas: [bounce rate, time on page, etc]
- Usability tests: [findings]
- Support tickets: [frecuencia]

### Impacto en Negocio

[Cómo este pain point afecta métricas de negocio]

## 📐 Propuesta de Diseño

### Mockups

[Embeber imágenes - Desktop y Mobile]

#### Estado Actual

[Screenshot del estado actual]

#### Propuesta

[Mockup de la propuesta]

### Cambios Específicos

1. **[Cambio 1]**
   - Por qué: [justificación]
   - Impacto esperado: [métrica]

2. **[Cambio 2]**
   - Por qué: [justificación]
   - Impacto esperado: [métrica]

### Principios de Diseño Aplicados

- [Principio 1: ej. Progressive disclosure]
- [Principio 2: ej. Consistency]

## 👥 User Flows

### Flow Actual

[Usuario] → [Paso 1] → [Paso 2] → [Problema] → [Frustración]


### Flow Propuesto

[Usuario] → [Paso 1 mejorado] → [Meta lograda]


## ✅ Criterios de Aceptación

### Visual
- [ ] [Criterio visual específico]
- [ ] Responsive: Desktop, Tablet, Mobile
- [ ] Estados: Default, Hover, Active, Disabled

### Funcional
- [ ] [Criterio funcional]
- [ ] [Criterio funcional]

### Accesibilidad
- [ ] Focus states visibles
- [ ] Contrast ratio ≥ 4.5:1
- [ ] Screen reader compatible
- [ ] Keyboard navigation

## 🔧 Consideraciones Técnicas

### Componentes a Modificar
- [Componente 1]
- [Componente 2]

### Design System Impact
- ¿Afecta design system? Sí/No
- ¿Nuevos componentes? Sí/No - [cuáles]

## 📏 Métricas de Éxito

**A/B Test Plan:**
- Métrica primaria: [ej. Completion rate]
- Baseline: [valor actual]
- Target: [valor objetivo]
- Duración test: [días]

**Criterios de Éxito:**
- [Métrica 1] mejora en ≥ [X]%
- [Métrica 2] no regresa más de [Y]%

## 🔗 Referencias
- Design system: [link]
- User research: [link]
- Similar patterns: [ejemplos]

---

**Validado por Ce:** [fecha]
**Complejidad:** [S/M/L]
**Prioridad:** [0-4]

🚀 Quick Reference - Cheat Sheet​

⚡ Cuándo Involucrar a Quién​

FaseQuiénCuándo SÍCuándo NO
Pre-trabajoSolo GonzaSiempre-
Product AlignmentNico + CeSiempre-
Product Alignment+ LaraFeature customer-facing
Historial de issues
Cambio en UX		Trabajo interno
Refactor sin UX change
Support CheckLara (async)Si no estuvo en Alignment
Y es customer-facing		Ya participó
Trabajo puramente técnico
TechnicalNachoSiempre-
Backlog RefinementTeam completoSiempre-
Backlog Refinement+ NicoDudas de negocio-
Backlog Refinement+ CeDudas de diseño-

🎯 Signos de un Ticket Bien Refinado​

✅ Un developer puede leerlo y empezar a trabajar sin preguntas ✅ Los criterios de aceptación son testables ✅ Los edge cases están identificados ✅ Los riesgos técnicos están documentados ✅ El scope está claro (in/out) ✅ Hay mockups para cambios visuales ✅ Las dependencias están explícitas

⚠️ Red Flags - Cuándo Pausar​

🚨 PAUSAR si:

  • Más de 5 preguntas sin respuesta en Backlog Refinement
  • Riesgo técnico no identificado aparece
  • Desacuerdo significativo en approach
  • Faltan mockups críticos
  • Dependencias no resueltas
  • Definition of Ready no cumplida

Acción: Marcar como "Needs more refinement" + agendar follow-up

📋 Atajos de Linear​

# Para crear tickets rápido
cmd/ctrl + k → "New issue"

# Para linkear issues
#[número] o pegar URL

# Para mencionar personas
@nombre

# Para agregar a proyecto
cmd/ctrl + k → "Add to project"

# Para cambiar status
cmd/ctrl + shift + s

# Para cambiar prioridad
cmd/ctrl + shift + p

🎓 Aprendizaje Continuo​

Retrospectiva Mensual del Proceso​

Agendar 30 min al final de cada mes para reflexionar:

## Retro de Refinement - [Mes]

### 🎉 Qué funcionó bien

- [Cosa 1]
- [Cosa 2]

### 😕 Qué no funcionó

- [Problema 1]
- [Problema 2]

### 💡 Ideas de mejora

- [Idea 1]
- [Idea 2]

### 📊 Métricas del mes

[Pegar dashboard mensual]

### 🎯 Acciones para el próximo mes

- [ ] [Acción 1]
- [ ] [Acción 2]

Feedback del Equipo​

Trimestral - Survey Anónimo:

# Refinement Process Feedback

1. Del 1-5, ¿qué tan claros llegan los tickets a Development?
   [ ] 1 [ ] 2 [ ] 3 [ ] 4 [ ] 5

2. ¿Qué falta frecuentemente en los tickets?
   [respuesta abierta]

3. ¿Qué está demás en los tickets?
   [respuesta abierta]

4. ¿Las reuniones de Backlog Refinement son productivas?
   [ ] Sí [ ] A veces [ ] No
5. Sugerencias de mejora:
   [respuesta abierta]

📚 Recursos Adicionales​

Documentación Interna​

Tools​

  • Linear: Gestión de tickets
  • Figma: Mockups y diseño
  • Slack: Comunicación async
  • Loom: Videos explicativos
  • Miro: Diagramas y flows

Referencias Externas​

🆘 Troubleshooting​

Problema: "Los tickets siguen regresando de Development"​

Diagnóstico:

  • ¿Qué porcentaje regresa? Si >20%, hay problema
  • ¿Qué feedback dan devs? ¿Falta diseño, contexto técnico, o criterios?

Solución:

  1. Review el último mes de tickets devueltos
  2. Identificar patrón común
  3. Agregar checkpoint específico en Definition of Ready
  4. Considerar pre-review con 1-2 devs senior antes de Backlog Refinement

Problema: "Backlog Refinement se alarga mucho"​

Diagnóstico:

  • ¿Duración promedio? Target: 60-90 min
  • ¿Cuántos tickets por sesión? Target: 5-7 max
  • ¿En qué se va el tiempo? ¿Discusiones técnicas profundas?

Solución:

  1. Reducir tickets por sesión - mejor 5 bien que 10 apurados
  2. Pre-reading obligatoria - enviar 24h antes
  3. Parking lot - llevar discusiones profundas offline
  4. Timeboxing estricto - 12 min max por ticket
  5. Mejor preparación - asegurar Definition of Ready 100%

Problema: "No hay tiempo para tanto refinamiento"​

Diagnóstico:

  • ¿Cuántas horas/semana inviertes? Track 2 semanas
  • ¿Qué fases toman más tiempo?

Solución:

  1. Prioriza: No todos los tickets necesitan el mismo nivel
    • S tickets: refinamiento light
    • L/XL tickets: refinamiento completo
  2. Async first: Muchas validaciones pueden ser por Slack
  3. Batch similar tickets: Refina 3 bugs juntos con Nacho
  4. Mejora templates: Más estructura = menos tiempo pensando

Problema: "Equipo no lee los tickets antes de Refinement"​

Diagnóstico:

  • ¿Tickets accesibles? ¿Enviados con anticipación?
  • ¿Demasiado largos?

Solución:

  1. TL;DR al inicio - resumen en 3 bullets

  2. Notificación estructurada:

    🎯 Backlog Refinement Miércoles 3pm

    Tickets a refinar (pre-lectura):
    1. DEV-123 - Feature X (L) - 👀 Revisar mockups
    2. DEV-124 - Bug Y (M) - 👀 Revisar steps to reproduce

    Total: 5 tickets, ~60 min

  3. Incentivo: Los que pre-leen hacen mejores preguntas y terminan antes

  4. Accountability: Rotar quién presenta (no siempre Gonza)

✨ Tips Finales​

Para Gonza​

💡 Eficiencia:

  • Usa snippets para secciones repetitivas
  • Duplica tickets similares como punto de partida
  • Ten templates pre-configurados en Linear

💡 Calidad:

  • Si dudas si algo está claro, no está claro
  • Una imagen vale más que 1000 palabras
  • Los ejemplos concretos > descripciones abstractas

💡 Colaboración:

  • Sobre-comunica en lugar de asumir
  • Documenta decisiones en el momento
  • Celebra buenos tickets (feedback positivo al equipo)

💡 Balance:

  • No todos los tickets necesitan ser perfectos
  • Prioriza profundidad en tickets críticos/complejos
  • Está bien iterar después de empezar (si es menor)

📝 Change Log​

VersiónFechaCambios
1.02025-10-07Versión inicial del documento

Mantenido por: Gonzalo Parra (Product Owner) Última actualización: 2025-10-07 Feedback: #product-feedback en Slack

X

Graph View