Explicación
La colaboración ágil significa participación continua — retroalimentación frecuente,
conversaciones sobre prioridades, acceso al equipo. No es solo firmar un contrato al inicio y recibir el
producto al final.
La Scrum Guide es explícita: 'la duración del Sprint es de un mes o menos.' 2 meses
viola este principio sin excepción posible. Sprints largos reducen la capacidad de inspección y adaptación.
La Retro inspecciona el PROCESO: personas, interacciones, herramientas, DoD.
Produce un plan de mejora con al menos una acción concreta para el siguiente Sprint.
Responsabilidad mutua = el equipo como unidad asume el compromiso del Sprint, no
cada persona por separado. Si alguien falla, el equipo ayuda, no señala.
Apertura en Scrum significa honestidad sobre el estado real del trabajo, los
problemas encontrados y los impedimentos. Es transparencia en las conversaciones, no solo en los
artefactos.
Coraje en Scrum incluye tener conversaciones difíciles, decir verdades incómodas y
hacer lo correcto aunque sea difícil. No decirle al PO que algo es imposible es falta de coraje.
Transparencia es uno de los 3 Pilares TIA (Transparencia → Inspección →
Adaptación). Los 5 valores son: Compromiso, Foco, Apertura, Respeto, Coraje. Esta distinción sale en casi
todos los exámenes SMPC.
Facilitar = crear las condiciones para que el evento cumpla su propósito. El SM no
dirige ni controla — guía el proceso para que el equipo llegue a sus propias conclusiones.
Las estimaciones son responsabilidad exclusiva de los Developers. El PO puede
aclarar el alcance para que la estimación sea más informada, pero nunca puede imponer un número.
El PO debe priorizar según valor de negocio para el usuario. Si también es Tech
Lead, puede inconscientemente priorizar features técnicamente interesantes sobre features valiosas para el
usuario.
El facilitador asegura que los eventos de Scrum funcionen bien. El coach trabaja en
el desarrollo de capacidades: autogestión, multifuncionalidad, pensamiento empírico. Son dos dimensiones
distintas del rol del SM.
La Scrum Guide distingue: impedimento = lo que el equipo NO puede resolver solo.
Si pueden resolverlo, es su trabajo hacerlo — el SM intervenir sería infantilizar al equipo.
El SM como agente de cambio educa a la organización sobre Scrum. Los reportes
individuales contradicen la autogestión y la transparencia colectiva de Scrum. La alternativa: hacer visible el
trabajo del equipo a través de los artefactos de Scrum.
La Scrum Guide usa el término 'generalmente' — no prescribe un máximo absoluto.
Pero más de 10 personas complica la comunicación, la autogestión y la cohesión del equipo.
El PO propone cómo el Sprint puede aumentar el valor del producto. Luego todo el
Scrum Team colabora para definir el Sprint Goal. Es un proceso de co-creación, no una decisión unilateral del
PO.
Los Developers seleccionan los PBIs según su capacidad y comprensión del Sprint
Goal. El PO puede aclarar, responder preguntas y señalar prioridades, pero no puede imponer qué ítems
entran al Sprint.
La Daily Scrum es DE los Developers. Ellos eligen la estructura que les funcione
para inspeccionar el progreso hacia el Sprint Goal. Ni el SM ni el PO tienen autoridad sobre cómo la Daily se
estructura.
Solo el Product Owner puede cancelar un Sprint, y solo si el Sprint Goal se volvió
obsoleto. El stakeholder debe comunicárselo al PO para que evalúe. El PO decide.
Los PBIs incompletos regresan al Product Backlog. El PO los re-evalúa, puede
cambiar su prioridad o incluso descartarlos. No 'pasan automáticamente' al siguiente Sprint — eso lo decide
el PO.
La Sprint Review es una sesión de trabajo: los stakeholders inspeccionan el
Incremento, comparten sus perspectivas y el equipo adapta el Product Backlog en consecuencia. No es el
equipo mostrando y los stakeholders aplaudiendo.
La Scrum Guide no prohíbe explícitamente que el SM también sea Developer. Sin
embargo, advierte que puede generar conflictos de interés — por ejemplo, facilitar objetivamente eventos
donde también participas como Developer es difícil.
El timebox es siempre un MÁXIMO, no un objetivo ni un mínimo. Si el equipo logró
inspeccionar el Sprint Goal y adaptar el plan en 8 minutos, terminó. Estirarlo artificialmente es perder el valor
del timebox.
El SM es parte del Scrum Team. La Retro es del Scrum Team completo. El SM no es
un observador externo — también inspecciona el proceso y puede contribuir a las mejoras.
La Scrum Guide no prescribe un criterio de ordenamiento específico para el Product
Backlog. El PO usa su juicio para maximizar el valor: puede considerar valor de negocio, riesgo,
dependencias técnicas, feedback de usuarios, oportunidades de mercado, etc.
Emergente significa que el backlog nunca está 'terminado'. Evoluciona con cada
Sprint, con el feedback del cliente, con cambios del mercado. Si alguien dice 'ya tenemos todos los
requerimientos', no está siendo ágil.
La Definition of Done no tiene excepciones. Si el ítem no la cumple, no es parte del
Incremento y regresa al Product Backlog. Presentar trabajo incompleto como Incremento compromete la
transparencia.
La Scrum Guide lista explícitamente esta responsabilidad del PO: garantizar la
transparencia, visibilidad y comprensión del Product Backlog. No significa que todos los ítems deban estar
detallados — el refinamiento es continuo.
La Card (tarjeta) es deliberadamente breve — un Post-It o ficha. Es un recordatorio
de que hay una conversación pendiente, no el requerimiento completo. El detalle está en la Conversación, no
en la tarjeta.
'Gestionar usuarios' es vago: ¿crear? ¿eliminar? ¿bloquear? ¿asignar roles? Sin
criterios de aceptación concretos nadie sabe cuándo está 'terminada'. Viola Testable — no se puede verificar.
La divergencia en Planning Poker es valiosa: indica que hay comprensiones distintas
del PBI. El mayor y el menor argumentan (30 seg cada uno) para que el equipo escuche perspectivas
diferentes. Luego se vota de nuevo — sin promedio.
La Scrum Guide 2020 lo dice explícitamente: 'Pueden crearse múltiples Incrementos
dentro de un Sprint.' Cada ítem que cumple la DoD es un Incremento. Incluso se puede entregar al cliente
antes de la Review.
Si no hay estándar organizacional, el Scrum Team crea su propia DoD. Es una
responsabilidad del equipo, no algo que espera que le den.
Sprint Backlog: plan creado POR los Developers para el Sprint actual (3
componentes: Goal+PBIs+plan). Product Backlog: lista emergente y ordenada de todo lo necesario para el
producto, gestionada por el PO.
Cuando múltiples Scrum Teams trabajan en el mismo producto, deben definir
conjuntamente una DoD común. Esto garantiza que el Incremento integrado sea coherente y de calidad
uniforme.
Nexus añade mínimas capas sobre la Scrum Guide: el Nexus Integration Team (que
coordina la integración entre equipos) y el Nexus Sprint Backlog (para gestionar las dependencias entre
equipos).
Kanban limita explícitamente cuántos ítems pueden estar en progreso
simultáneamente (regla WIP). Scrum selecciona una cantidad de trabajo para el Sprint basada en la
capacidad del equipo — pero no tiene una regla de WIP durante el Sprint.
La paradoja del SM: su éxito es hacerse innecesario para las operaciones diarias. Un
equipo que funciona bien con poca intervención es el resultado de un buen coaching. El SM puede seguir
aportando valor a nivel organizacional aunque el equipo sea autónomo.
El SM como coach y facilitador no toma partido — facilita que las partes lleguen a un
entendimiento. Los conflictos sobre prioridades suelen ser señal de que hay una conversación importante
pendiente sobre valor de negocio vs. capacidad técnica.
El SM como agente de cambio trabaja con el management educando sobre lo que
Scrum requiere: cambio cultural, no solo instalación de eventos. Propone una alternativa basada en evidencia
— implementación gradual con aprendizaje real.
Esta es la definición textual de la Scrum Guide 2020: 'El Scrum Master es
responsable de la efectividad del Scrum Team. Lo hace habilitando al equipo para mejorar sus prácticas
dentro del marco Scrum.' No entrega el Sprint Goal — eso es del equipo. No remueve TODOS los obstáculos
— los del equipo que no puede resolver solo.
