El libro 97 Things Every Scrum Practitioner Should Know, editado por Gunther Verheyen y publicado por O'Reilly, reúne contribuciones de casi un centenar de expertos de la comunidad Scrum. No es un libro para leer de principio a fin: es una colección de ensayos cortos, cada uno con su propia perspectiva y tesis. Su valor está en la diversidad de enfoques sobre un mismo marco.
De los noventa y siete artículos, hay una decena que destaca por su capacidad de transformar la manera en que los equipos entienden y practican Scrum. Estos son los que más recomendamos.
01Scrum no es un proceso — es un framework.
Uno de los malentendidos más frecuentes es tratar Scrum como un proceso prescriptivo que hay que ejecutar con fidelidad ciega. Este artículo argumenta que Scrum es un framework: una estructura ligera sobre la que cada equipo construye su propio proceso. Ese espacio de libertad no es un defecto — es el punto.
La implicación práctica: cuando algo falla en un equipo Scrum, la solución no suele estar en "hacer Scrum más puro", sino en entender qué problema organizativo o técnico se está evitando con esa rigidez.
02El Scrum Master no es el jefe del proceso.
Este artículo desmonta la figura del Scrum Master como policía del proceso. El SM genuinamente efectivo no controla ni dirige — facilita y elimina impedimentos. Su autoridad proviene del servicio, no del título.
El punto más agudo: un Scrum Master que se preocupa más por el cumplimiento de los rituales que por la efectividad del equipo está haciendo su trabajo al revés.
03El Product Backlog no es una lista de tareas.
Confundir el Product Backlog con una lista de tareas técnicas es uno de los errores más comunes — y más costosos. Este artículo distingue claramente entre items orientados a valor (lo que le importa al cliente) e items orientados a implementación (lo que le importa al desarrollador). El backlog debe hablar el idioma del primero, no del segundo.
04La velocidad es una métrica de planificación, no de rendimiento.
Este artículo ataca directamente el uso de la velocidad como KPI de productividad del equipo. Usada correctamente, la velocidad ayuda al equipo a planificar cuánto puede comprometerse en un sprint. Usada como métrica de rendimiento por la dirección, genera gaming, inflación de estimaciones y pérdida de confianza.
05La Definition of Done es un contrato de calidad, no un checklist.
El artículo explora cómo la DoD funciona como el acuerdo más importante del equipo. No es una lista de tareas que hay que marcar — es la declaración compartida de qué significa que algo está realmente terminado. Equipos con DoD débiles producen deuda técnica acumulada. Equipos con DoD rigurosa producen incrementos en los que se puede confiar.
06El Sprint Review no es una demo.
Uno de los artículos más frecuentemente citados en comunidades de Scrum. La distinción es crucial: una demo es un espectáculo donde el equipo muestra lo que ha hecho. El Sprint Review es una conversación de negocio donde el equipo, el PO y los stakeholders inspeccionan el producto y adaptan el plan. Cuando el Sprint Review se convierte en demo, pierde su función más valiosa.
La Sprint Review es el momento donde el producto habla y el equipo escucha. Si solo habla el equipo, algo va mal.— Perspectiva sobre Sprint Reviews
07Los impedimentos no son solo técnicos.
El artículo amplía la definición de impedimento más allá de los bloqueos técnicos o de proceso. Los impedimentos organizativos — cultura de reuniones, decisiones lentas, silos de información, falta de confianza entre áreas — son los más costosos y los más ignorados. El Scrum Master que solo resuelve impedimentos técnicos está viendo la punta del iceberg.
08Scrum sin ingeniería técnica excelente es teatro.
Uno de los artículos más directos del libro. Argumenta que Scrum asume —pero no prescribe— prácticas de ingeniería de alta calidad: TDD, integración continua, code review, automatización de tests. Sin esas prácticas, la cadencia de Scrum se convierte en presión sin soporte técnico, lo que acelera la deuda técnica en lugar de reducirla.
09La transparencia que duele es la que más importa.
Este artículo habla de la transparencia como valor incómodo. La transparencia que solo muestra lo bueno no es transparencia — es marketing interno. La transparencia real incluye mostrar el progreso real, los problemas reales, la deuda técnica real y la incertidumbre real. Es la única base para la confianza organizativa genuina.
10La retrospectiva es el evento más importante de Scrum.
Si hubiera que elegir un solo evento de Scrum, este artículo argumenta que sería la retrospectiva. Es el único evento cuyo propósito explícito es mejorar el propio sistema. Sin retrospectivas genuinas — no rituales vacíos — los equipos Scrum se estancan en sus propios problemas sin mecanismo de salida.
Un equipo que hace buenas retrospectivas mejora con el tiempo. Un equipo que hace malas retrospectivas o no las hace, repite sus errores sprint tras sprint.