Diagnóstica y corrige los problemas más habituales en equipos de desarrollo que usan Scrum mal: sprints que no cierran, deuda técnica acumulada y estimaciones que nunca se cumplen.
Cuándo usarlo: Diagnosticar y corregir las disfunciones de Scrum en un equipo de ingeniería para mejorar la predictabilidad y la calidad de las entregas.
Herramienta recomendada: Claude
Eres un Scrum Master y agile coach con experiencia en equipos de ingeniería de software de empresas en fase de crecimiento. Necesito tu ayuda para diagnosticar los problemas de nuestro proceso Scrum actual y construir un plan de mejora concreto. Mi contexto: - Tamaño del equipo de desarrollo: [número de personas y roles: devs, QA, diseño, etc.] - Tiempo que lleváis usando Scrum: [meses o años] - Duración actual de los sprints: [1, 2 o 3 semanas] - Principales síntomas del problema: [sprints que no cierran, estimaciones siempre mal, deuda técnica creciente, retrospectivas que no cambian nada, conflictos con el product owner, etc.] - Velocidad media actual si la conocéis: [story points o ítems por sprint] - Stakeholders principales fuera del equipo: [CEO, CPO, clientes directos, etc.] Con ese contexto, dame: 1. DIAGNÓSTICO DE LOS DISFUNCIONALES DE SCRUM MÁS HABITUALES Explícame los diez antipatrones de Scrum más frecuentes en equipos de ingeniería en crecimiento y cómo reconocerlos: el sprint que siempre arrastra trabajo al siguiente, el refinement que no refina nada, el daily que se convierte en reporte de estado, la velocidad que varía un 40% entre sprints, el product owner que no está disponible y el backlog que nadie mira. Para cada antipatrón dame la señal de alarma temprana y la intervención que funciona. 2. ESTIMACIÓN Y PLANIFICACIÓN: CÓMO HACERLO BIEN ¿Por qué fallan las estimaciones en la mayoría de los equipos? Dame el proceso correcto de estimación relativa con story points: la importancia de tener una historia de referencia (anchor story), cómo hacer planning poker de forma eficiente (sin que se convierta en debate interminable), cómo manejar los ítems que el equipo no sabe estimar y cómo usar la velocidad histórica para hacer predicciones creíbles de entrega. 3. GESTIÓN DE LA DEUDA TÉCNICA EN EL CONTEXTO ÁGIL ¿Cómo incorporar la gestión de la deuda técnica en el proceso Scrum sin que el negocio sienta que el equipo no está entregando valor? Dame el marco para cuantificar la deuda técnica (en términos de impacto en velocidad o en riesgo), cómo incluirla en el backlog con criterios de priorización comparables a las historias de negocio, y cuál es el porcentaje de capacidad del sprint que debería destinarse a deuda técnica en diferentes fases del producto. 4. EL DEFINITION OF DONE QUE REALMENTE FUNCIONA ¿Cómo diseñar un DoD que sea exigente pero alcanzable y que el equipo respete? Dame los criterios mínimos que debería incluir un DoD para un equipo de desarrollo web o de producto SaaS, cómo involucrar al equipo en su diseño para que se apropie de él, y cómo evolucionar el DoD a medida que el equipo madura sin que se convierta en un documento que nadie lee. 5. LA RELACIÓN ENTRE EL EQUIPO DE INGENIERÍA Y EL PRODUCT OWNER ¿Cómo mejorar la colaboración entre el equipo de desarrollo y el product owner cuando hay fricción? Dame el protocolo de refinement efectivo: la cadencia ideal, quién debe participar, cómo preparar las historias antes de la sesión para no perder el tiempo del equipo y cómo gestionar los cambios de prioridad que llegan a mitad del sprint sin romper el proceso. 6. MÉTRICAS ÁGILES QUE EL EQUIPO Y EL NEGOCIO DEBEN MONITORIZAR Dame las seis métricas clave para un equipo de ingeniería que usa Scrum: velocity, predictability rate (% de ítems completados respecto a los comprometidos), cycle time, lead time, deuda técnica como % del backlog y tasa de bugs en producción por sprint. Para cada métrica explícame cómo calcularla, qué valor es saludable y qué acción tomar cuando está fuera de rango. 7. EL PLAN DE MEJORA DE 90 DÍAS Dame un plan de mejora de 90 días para un equipo de ingeniería con el proceso Scrum disfuncional: qué cambiar en las primeras dos semanas (wins rápidos que generen confianza), qué trabajar en el mes dos (cambios estructurales que requieren más tiempo) y qué evaluar al final de los 90 días para saber si la mejora es sostenible. Incluye cómo comunicar el plan al equipo y a los stakeholders para conseguir su compromiso.