SPC Conocimientos Generales APF common mistakes
SPC Conocimientos Generales APF · Understand the traps and how to avoid them.
Responder que el Scrum Master asigna tareas, prioriza el backlog o decide quién hace qué dentro del Sprint, tratándolo como un jefe de proyecto.
Se traslada la mentalidad de gestión tradicional al rol y se confunde la responsabilidad de facilitar el proceso con la autoridad para dirigir el trabajo diario del equipo.
What to do instead
Memorizar la distinción: el Product Owner ordena el Product Backlog, los Developers autoorganizan la ejecución, y el Scrum Master sirve al equipo eliminando impedimentos y enseñando Scrum. Ante cualquier pregunta de 'quién decide', preguntarse si la decisión es de valor (PO), de proceso (SM) o de ejecución (Developers).
Confundir el Daily Scrum con una reunión de reporte de estado al Scrum Master o al Product Owner, o extenderlo más allá de los 15 minutos para resolver problemas.
La costumbre organizacional de rendir cuentas ante un superior pesa más que la definición del evento, y se cree que hablar de cada detalle técnico demuestra rigor.
What to do instead
Fijar que el Daily Scrum es del equipo, para inspeccionar el progreso hacia el Sprint Goal y adaptar el plan de las próximas 24 horas; el Scrum Master no lo dirige ni lo convierte en interrogatorio. Los problemas que surgen se aparcan y se tratan después con las personas relevantes.
Tratar el Sprint Review como una demo o presentación formal al cliente donde solo se muestran funcionalidades terminadas, sin inspeccionar el incremento ni adaptar el backlog.
Se confunde el evento con una reunión de aprobación o de marketing, y se olvida que su propósito es la inspección colaborativa del producto y la adaptación del Product Backlog.
What to do instead
Describir el Sprint Review como sesión de trabajo con los stakeholders donde se inspecciona el incremento, se revisan métricas y objetivos, y se actualiza el backlog con lo aprendido. La demo es un medio, no el fin; la salida esperada es un backlog adaptado.
Definir la Definition of Done como criterio de aceptación por historia, o aceptar que cada equipo tenga una DoD distinta dentro del mismo producto sin justificación.
Se mezclan dos conceptos parecidos: la DoD es un estándar de calidad compartido para el incremento, mientras que los criterios de aceptación son específicos de cada item. La costumbre de improvisar por equipo agrava el error.
What to do instead
Explicar que la DoD es una lista de comprobación única y acordada que todo incremento debe cumplir; si no se cumple, el item no cuenta como terminado ni se presenta. Los criterios de aceptación viven en el item del backlog. En un producto, la DoD debería ser común y mejorarse con el tiempo.
Identificar el Product Goal, el Sprint Goal y la Definition of Done como si fueran intercambiables o como simples secciones del backlog sin función propia.
Los tres conceptos aparecen juntos en la guía y comparten la palabra 'objetivo', lo que invita a memorizarlos sin distinguir su alcance temporal ni su uso.
What to do instead
Anclar cada uno a su horizonte: el Product Goal es el estado futuro del producto a medio plazo y vive en el Product Backlog; el Sprint Goal es el propósito único del Sprint y da cohesión al equipo; la DoD es el estándar de calidad que hace verificable el incremento. Practicar con ejemplos donde solo uno de ellos cambia.
Elegir 'cumplir el plan inicial' o 'entregar todas las historias comprometidas' como respuesta correcta ante preguntas sobre adaptación al cambio, en lugar de priorizar el valor y el objetivo.
El reflejo de la gestión de proyectos tradicional asocia éxito con adherencia al plan, y los distractores se redactan de forma plausible para atraer esa intuición.
What to do instead
Interiorizar el principio de responder al cambio sobre seguir un plan: en Scrum el plan es una hipótesis que se revisa en cada evento. Cuando dos opciones parezcan válidas, elegir la que preserve el Sprint Goal, el valor para el cliente y la transparencia, no la que salve el cronograma.
Calcular velocidad, lead time o capacidad mezclando unidades (puntos de historia con horas, items con puntos) o usando la velocidad para comparar equipos y presionar su rendimiento.
Las métricas se aprenden como fórmulas sueltas sin su propósito, y la presión organizacional empuja a usar la velocidad como KPI de productividad comparativa.
What to do instead
Asociar cada métrica a su decisión: la velocidad es una previsión interna del equipo en sus propias unidades y nunca sirve para comparar equipos; el lead time y el throughput describen el flujo; las métricas de calidad miran el incremento. Verificar siempre la unidad antes de operar y rechazar usos punitivos de la métrica.
Describir el escalado (por ejemplo, con marcos tipo LeSS, Nexus o SAFe) como una forma de añadir capas de gestión, comités y reportes por encima de los equipos.
Se confunde escalar con controlar, y los modelos mentales jerárquicos llevan a imaginar estructuras de coordinación pesadas en lugar de mecanismos de alineación técnica y de producto.
What to do instead
Explicar que escalar es mantener la agilidad al crecer: equipos pequeños y autónomos, un backlog y una DoD compartidos cuando corresponda, sincronización ligera y decisiones descentralizadas. Identificar los anti-patrones (dependencias ocultas, integración tardía, comités de aprobación) y las prácticas que los resuelven.
Justificar una conducta dudosa (aceptar presión para saltarse la DoD, ocultar un retraso, manipular el burndown) apelando a la confianza o a la flexibilidad ágil.
Los escenarios éticos se leen como preguntas de 'qué haría un buen compañero' en lugar de preguntas sobre transparencia, integridad y responsabilidad profesional.
What to do instead
Aplicar un criterio fijo: transparencia radical sobre el estado real, no ocultar información a los stakeholders, no falsear artefactos y escalar los conflictos de interés por los canales adecuados. Si una opción requiere mentir, maquillar datos o saltarse un estándar de calidad, es incorrecta aunque parezca pragmática.
Confundir el rol del facilitador con el de líder de opinión: imponer la decisión del equipo, votar en lugar de facilitar el consenso o intervenir dando la solución técnica.
Se asocia facilitar con dirigir y se teme que un proceso sin imposición no llegue a conclusiones, por lo que se recurre al atajo de decidir por el grupo.
What to do instead
Distinguir facilitar (diseñar el proceso, hacer preguntas, proteger la participación, sintetizar y verificar acuerdos) de decidir el contenido. Practicar técnicas como la votación por puntos para priorizar sin imponer, el check-in, la escucha activa y el registro explícito de acuerdos y responsables.