Preguntas de entrevista para Scrum Masters

Este documento contiene una traducción de las preguntas de entrevista para Scrum
Masters, sugeridas por Stefan Wolpers y Andreea Tomoiaga1. Este recurso no se encuentra
orientado solamente a los reclutadores de roles ágiles, sino también a todos los que nos
encontramos en la práctica habitual de Scrum.

El rol de un Scrum Master

Pregunta 01

El manifiesto ágil infiere “personas sobre los procesos”. Por lo tanto ¿No es el Scrum
Master - cuyo rol está destinado a hacer cumplir el proceso - una contradicción?

Un Scrum Master no ejerce ninguna autoridad real. El Equipo Scrum no le reporta. El

objetivo de esta pregunta es ayudar a revelar si el candidato entiende que su función es
liderar el equipo, en lugar de gestionarlo. Hacer esta pregunta también es probable que
revele por qué el candidato está interesado en el rol de Scrum Master en primer lugar.

Las respuestas aceptables deben enfatizar la facilitación y el apoyo:

● “Soy el facilitador del Equipo Scrum. Mi trabajo es hacerlos exitosos".
● “No soy ni project manager, tampoco gerente de RRHH. Apoyo al Equipo Scrum
para lograr su autogestión. No le digo a las personas qué hacer".
● "Soy el facilitador del Equipo Scrum como instructor, coach o mentor, y los aliento a
sobresalir como un equipo ágil".

Pregunta 02

¿Qué indicadores podrían existir para demostrar que las prácticas ágiles funcionan en la
organización y cuáles de estos demostrarían que los esfuerzos en agile están teniendo
éxito?

No existe un estándar o definición general de "éxito ágil" que pueda usarse para medir la
agilidad de una organización. Cada organización debe desarrollar sus propios criterios. La
velocidad de equipo2 en crecimiento generalmente no se considera un indicador significativo
(vea la pregunta 40 para una discusión de la velocidad de equipo).

Sin embargo, aunque en su mayoría son indirectos, hay varios indicadores que pueden ser
útiles para determinar el éxito:

1
38+9 Scrum Master Interview Questions to Avoid Agile Imposters [PDF and Video] -
https://age-of-product.com/38-scrum-master-interview-questions-to-avoid-imposters-free-pdf/
2
La velocidad de equipo es una medida del trabajo completado dentro de un período de tiempo
determinado en base a comparaciones relevantes.

@marcoviaweb
 ● La mejora de la felicidad de un equipo se expresa mediante una reducción de la
rotación y un aumento del número de referencias de los miembros.
● El incremento de la competitividad en la batalla por el talento se puede demostrar
mediante el aumento en el número de personas con experiencia que desean unirse
a la organización.
● Los productos entregados a los clientes se traducen en mayores índices de
retención, mejores tasas de conversión, mayor duración del valor y mejoras similares
para el negocio.
● El incremento de la calidad del software se puede demostrar con una
considerablemente menor Deuda Técnica3, menos errores y menor tiempo dedicado
al mantenimiento.
● El tiempo de producción, desde la validación de la idea hasta el envío del producto,
se ha sido reducido.
● El Cycle Time4 para la validación de hipótesis se ha reducido.
● Se ha reducido la asignación de recursos a productos de bajo valor.
● Hay un mayor respeto entre los Stakeholders por el equipo de TI.
● Los Stakeholders participan cada vez más en reuniones ágiles, especialmente
durante el Sprint Demo5.

Pregunta 03

¿Debería un Scrum Master eliminar los impedimentos en nombre del Equipo Scrum?

Un Scrum Master no debe preocuparse por "eliminar impedimentos en nombre del Equipo
Scrum", sin importar con qué frecuencia se menciona este requisito en los anuncios de
trabajo. Si un Scrum Master actúa como una "mamá de Scrum", su equipo nunca se
auto-organizará.

Un Equipo Scrum debe tomar sus propias decisiones. Esto resulta casi inevitablemente en
fallas, callejones sin salida y otras excursiones no planificadas cuando el equipo está
aprendiendo algo nuevo. En consecuencia, al principio, un equipo necesitará más
orientación de lo habitual por parte del Scrum Master - y de una clase distinta al que se
ejemplifica para dibujar tableros offline (ver Preguntas 31 y 32) o actualizar tickets en JIRA6.
Sin embargo, dicha orientación no debe convertirse en un ejercicio de “sobre protección de
hijos”: se debe permitir que un equipo aprenda de sus fracasos.

Pregunta 04

3
La Deuda Técnica es el trabajo de desarrollo adicional que surge cuando se utiliza un código que es
más fácil o más rápido de implementar a corto plazo en lugar de aplicar una mejor solución global.
4
Cycle time, es el número de días entre el inicio y el final de un experimento adecuado para validar o
falsificar la hipótesis motivadora.
5
Parte del Sprint review, el Sprint Demo es el evento durante el cual el Equipo Scrum presenta el
trabajo completado durante el Sprint a los stekaholders.
6
JIRA® es un sistema de software patentado publicado por Atlassian Pty Ltd. para la gestión de
proyectos y seguimiento de issues.

@marcoviaweb
 ¿Cómo debe comunicarse un Scrum Master con el Product Owner?

Comunicarse de manera honesta y abierta es la mejor manera para que un Scrum Master
obtenga la cooperación del Product Owner. Ambos deben servir como líderes sin ser
autoritarios, y cada uno depende de que el otro trabaje recíprocamente para el éxito de un
Equipo Scrum (por ejemplo, lograr la meta de un Sprint). Son aliados con respecto al
coaching de la organización para volverse, y seguir siendo, ágiles.

El Product Owner es responsable de proporcionar una retroalimentación rápida sobre

asuntos del producto, de aclarar los objetivos y de garantizar que todo el equipo de delivery
del producto7 comprenda la visión.

El Scrum Master, en cambio, apoya al Product Owner en la creación del Product Backlog de
alto valor, y para este fin debe facilitar la colaboración efectiva entre el Product Owner y el
Equipo Scrum.

Pregunta 05

¿Debería el Equipo Scrum involucrarse en el proceso de Product Discovery y, de ser así,

cómo?

Hay dos razones principales por las que un Equipo Scrum debería participar en el proceso
de Product Discovery lo antes posible:
1. Cuanto antes participen los ingenieros en el proceso de Product Discovery, menores
serán las posibilidades de buscar soluciones que técnicamente no sean viables o
que no generen un retorno de la inversión.
2. Involucrar a un Equipo Scrum desde el principio garantiza que el equipo y el Product
Owner desarrollen una comprensión y sentido de propiedad compartida de lo que se
construirá. Esto ayuda significativamente con la asignación de recursos a los
problemas correctos, maximizando el valor para el cliente y mitigando el riesgo de
inversión.

Involucrar a los ingenieros de un Equipo Scrum al inicio del proceso garantiza su aceptación
y la disposición del equipo a participar en todas las fases del desarrollo de un producto. Esto
motiva al equipo a participar cuando se realizan los cambios necesarios para lograr los
objetivos definidos en cada Sprint o Release del producto.

Pregunta 06

El papel del Product Owner por naturaleza es un cuello de botella. ¿Cómo apoya al
Product Owner para que maximice el valor?

7
Un equipo de delivery de producto comprende a todos los involucrados en la entrega de un
producto al mercado, incluidos los equipos de Scrum involucrados.

@marcoviaweb
Esta pregunta retoma el anterior. Una vez más, el candidato debe centrarse en explicar por
qué involucrar al Equipo Scrum al principio del proceso de Product Discovery es beneficioso
tanto para el Product Owner como para la organización. Esencialmente, en el equipo todos
ganan o todos pierden.

Pregunta 07

¿Cómo puede asegurarse de que un Equipo Scrum tenga acceso a los Stakeholders de
un proyecto?

Al responder a esta pregunta, el candidato debe explicar que no hay una manera fácil de
garantizar el acceso a los Stakeholders.

El candidato podría sugerir alentar a los Stakeholders a participar en una comunicación

efectiva (transparente y útil). Los Sprint Review son un lugar útil para esto, y la interacción a
menudo promueve mejores relaciones entre diferentes departamentos y unidades de
negocios.

Pregunta 08

¿Cómo promueve una mentalidad ágil a través de los diferentes departamentos y a lo

largo de una organización y, en pos de eso, cuál es su estrategia cuando capacita a los
Stakeholders que no están familiarizadas con TI?

Hay varias tácticas que un Scrum Master puede usar para involucrar a los Stakeholders en
Scrum:
● Lo más importante es que un Scrum Master debe vivir y respirar los principios del
Manifiesto Ágil. Ellos deben hablar con todos los miembros de la organización que
participan en la construcción del producto y deben ser transparentes sobre lo que
hacen.
● Los equipos de producto e ingeniería pueden producir evidencia, en presentaciones
o de otra manera, demostrando a los Stakeholders que Scrum está reduciendo
significativamente el tiempo de entrega desde la idea hasta el lanzamiento del
producto.
● Los equipos de producto e ingeniería pueden demostrar que Scrum mitiga el riesgo
(es decir, la predicción de cuándo podrían estar disponibles las nuevas
características), lo que contribuye al éxito de otros departamentos en la planificación
y ejecución.
● Un Equipo Scrum puede ser transparente con respecto a su trabajo y comprometer
de manera proactiva a los Stakeholders invitándolos a reuniones, revisiones de
Sprint y otros eventos donde el equipo comunica su actividad o progreso.

@marcoviaweb
 ● La capacitación para todos en la organización, en particular los Stakeholders, es
importante. Un enfoque práctico es organizar talleres diseñados para enseñar
técnicas ágiles para colegas no técnicos.

Pregunta 09

¿Cómo darías a conocer Scrum a los altos ejecutivos?

Esta es una pregunta deliberadamente abierta destinada a alentar la discusión. Al

responder a esta pregunta, el candidato debe explicar cómo difundir una mentalidad ágil en
toda la organización o, idealmente, y más específicamente, cómo crearían una organización
de aprendizaje que abarque la experimentación con el fin de identificar el mejor producto
para los clientes.

Es probable que un buen candidato hable sobre la necesidad de "vender" ágilmente a la

organización para ganar los corazones y las mentes de los interesados. Al comienzo de una
transición, cualquier organización muestra inercia al cambio, por lo que para superar esta
resistencia, los ejecutivos y las Stakeholders deben saber qué tan ágil les beneficiará antes
de que puedan comprometerse.

Un enfoque práctico al presentar el Scrum a los ejecutivos sénior es organizar talleres para
la gestión del nivel C. La aplicación de Scrum a nivel ejecutivo ha tenido éxito en el pasado.
Los ejecutivos e incluso los directores clave, pueden obtener experiencia de primera mano
con metodologías ágiles si se organizan como un Equipo Scrum.

No hay respuestas correctas o incorrectas a esta pregunta. Las mejores prácticas deben
tener en cuenta la cultura de la organización, el tamaño, la madurez del producto, los
requisitos legales y de cumplimiento, y la industria en la que opera.

Pregunta 10

Ya ha proporcionado capacitación de Scrum a los Stakeholders de su proyecto. Después

de la fase inicial de tratar de aplicar los conceptos es cuando se encuentran los primeros
obstáculos, algunos de estos actores comienzan a resistirse a la adopción continua.
¿Cuál es su estrategia y experiencia en el manejo de estas situaciones?

El objetivo de esta pregunta es fomentar un intercambio de ideas y lecciones aprendidas

cuando se supera la resistencia a la agilidad dentro de una organización. La familiaridad con
los patrones de fracaso ágil, que son comunes a muchas organizaciones, demostrará la
experiencia del candidato.

El candidato también debe estar familiarizado con el desafío particular que enfrentan los
gerentes intermedios en cualquier transición a prácticas ágiles. Pasar de un estilo de

@marcoviaweb
comando y control (es decir, administrar personas y decirles qué hacer) a un estilo de
liderazgo de servicio - por lo que abandonar los principios de Taylor8 - no es para todos.

Refinamiento y estimación de backlog

Pregunta 11

Con frecuencia el Product Owner convierte los documentos de requisitos recibidos de los
Stakeholders en tickets y pide al equipo que los estimen. ¿Cómo te sientes acerca de
este procedimiento?

El Product Owner nunca debe convertir los documentos de requisitos9 recibidos de los
Stakeholders en tickets, y un Scrum Master nunca debe aceptar tal procedimiento. No es
nada más que un proceso en cascada10 disfrazado de una metodología pseudo-ágil.

Si se supone que una organización se enfoca en entregar valor a sus clientes, es esencial
que se abandone cualquier proceso que implique "requisitos" que un gerente de proyecto
transmita a sus ingenieros. No hace ninguna diferencia si el gerente del proyecto se
presenta como Product Owner. En su lugar, la organización debería comenzar a incluir a
todos en el proceso de descubrimiento del producto, asegurando así una visión compartida
de lo que se debe construir.

Pregunta 12

¿Qué tipo de información necesitaría de parte del Product Owner para darle al equipo una
actualización sobre el producto y la situación del mercado?

La información que un Scrum Master podría requerir del Product Owner cuando se quiere
actualizar al equipo sobre el producto, o la reacción del mercado, incluiría cualquier
información que pudiera proporcionar al Equipo Scrum una comprensión de por qué algo es
valioso para los clientes. Dicha información puede ser de naturaleza cuantitativa (por
ejemplo, datos analíticos que describen cómo se utiliza un proceso) o de naturaleza
cualitativa (por ejemplo, transcripciones, screencasts o videos de una sesión de prueba de
usuario).

Una excelente sugerencia por parte del candidato sería que el Equipo Scrum participe en la
recopilación de señales cualitativas participando en las entrevistas con los usuarios.

8
Los principios de la administración científica de F.W. Taylor son una teoría de la organización y la
administración en la era industrial según la cual los trabajadores son vistos como recursos y deben
ser gestionados como tales.
9
Los documentos de requisitos pueden incluir, por ejemplo, especificaciones de requisitos de
software (SRS).
10
Un proceso de cascada es un proceso de diseño secuencial que generalmente se adhiere al
modelo de cascada utilizado tradicionalmente en el desarrollo de software.

@marcoviaweb
Pregunta 13

¿Quién debería escribir las historias de usuarios?

Escribir historias de usuarios debe ser un esfuerzo conjunto entre todos los miembros de un
Equipo Scrum. Si no es así, el equipo podría sentir que no es propietario de las historias, lo
que inevitablemente lleva a menos o ningún compromiso, motivación reducida y, en última
instancia, a un producto de menor calidad.

Pregunta 14

¿Cómo es una buena historia de usuario? ¿Cuál es su estructura?

Una buena historia de usuario

● incluye una descripción,
● tiene criterios de aceptación definidos,
● se puede entregar dentro de un solo Sprint,
● tiene todos los entregables UI disponibles,
● tiene todas las dependencias (probables) identificadas,
● tiene criterios de rendimiento definidos,
● tiene criterios de seguimiento definidos, y
● es estimado por el equipo.

Pregunta 15

¿En qué consiste la Definition of Ready?

La "Definition of Ready" es un acuerdo entre el Equipo Scrum y el Product Owner sobre lo

que debe incluirse en una historia de usuario (antes de que la historia pueda considerarse
lista para su estimación). Esto define cómo es una buena historia de usuario.

La discusión en la pregunta 14 incluye un resumen de lo que debe incluir una buena historia
de usuario. Otro enfoque es utilizar un marco para las historias de usuario, como la
mnemotecnia INVEST de Bill Wake:
● Independiente (Independent). La historia de usuario debe ser autocontenida, de
manera que no haya una dependencia inherente con otra historia de usuario.
● Negociable (Negotiable). Hasta que se conviertan en parte de una iteración, las
historias de usuario siempre pueden cambiarse y reescribirse.
● Valioso (Valuable). Una historia de usuario debe entregar valor al usuario final.
● Estimable (Estimable). Siempre se debe poder estimar el tamaño de una historia de
usuario.

@marcoviaweb
 ● Pequeña (Small). Las historias de usuario no deben ser tan grandes como para que
sea imposible planificarlas, asignarles tareas y priorizarlas con cierta certeza.
● Comprobable (Testable) La historia del usuario (o su descripción relacionada) debe
proporcionar la información necesaria para hacer posible el desarrollo de la prueba.

Pregunta 16

¿Por qué las historias de usuarios no se estiman en horas hombre?

Estimar historias de usuarios en horas hombre nunca es una buena idea. Se desvía
intencionalmente el énfasis del verdadero propósito del proceso de estimación: crear una
comprensión compartida de la tarea que está por delante entre todos los miembros del
Equipo Scrum. Ergo, la estimación en sí es sólo un subproducto.

Estimar es a menudo complicado cuando:

● software legacy está involucrado,
● un equipo se enfrenta a una deuda técnica significativa, o
● un equipo está compuesto principalmente por miembros junior.

Los puntos de historia11 son mucho más adecuados para estimar que las horas de trabajo
en todas las situaciones, pero especialmente en situaciones difíciles, porque reflejan con
precisión tanto la complejidad de la tarea como el esfuerzo requerido para completarla. El
uso de horas de trabajo en lugar de puntos de historia generalmente cambia el enfoque de
la creación de valor para los clientes a la gestión de proyectos y presupuestos más
tradicional, lo que impone un proceso en cascada.

El candidato mencionaría esta discusión en la comunidad ágil sobre si las estimaciones son
útiles en general. Probablemente, también señalaría el concepto de "no estimaciones" (por
ejemplo, #noestimates).

Pregunta 17

El Product Owner tiende a agregar ideas de todo tipo en el Product Backlog como un
recordatorio para trabajar en ellas en una etapa posterior. Con el tiempo, esto ha llevado
a más de 200 tickets en varias etapas. ¿Qué piensas sobre esto? ¿Puede un Equipo
Scrum trabajar en 200 tickets?

Cualquier Product Backlog mayor que el alcance de dos o tres Sprints no es manejable. El
uso indebido de un backlog al agregar cientos de elementos es una clara señal de que el
Product Owner necesita la ayuda del Equipo Scrum o del Scrum Master para hacer frente a
la afluencia de ideas, sugerencias y requisitos. Un retraso más pequeño evita la mala
asignación de recursos; un retraso mayor es una indicación de desperdicio.

11
Los puntos de historia son unidades de medida que expresan las estimaciones del esfuerzo total
requerido para implementar completamente un elemento del Product Backlog.

@marcoviaweb
El candidato debe dejar claro que apoyaría al Product Owner en la gestión con el tamaño
del Product Backlog y con el procesamiento de los aportes de las Stakeholders.

Sprint planning

Pregunta 18

¿Cómo puede el Scrum Master contribuir con el Sprint Planning de manera que permita al
Equipo Scrum trabajar solo en las historias de usuario más valiosas?

Es una prerrogativa del Product Owner definir el alcance de un próximo Sprint identificando
y priorizando las historias de usuario más valiosas del Product Backlog, y es deber del
Scrum Master apoyar al Product Owner en esto. En consecuencia, la mejor manera para
que un Scrum Master se asegure de que un Equipo Scrum esté trabajando en las historias
de usuario más valiosas es:
1. garantizar que el Equipo Scrum esté involucrado en el proceso Product Discovery en
una etapa temprana;
2. garantizar que el proceso de refinamiento del Product Backlog sea bien comprendido
tanto por el Equipo Scrum como por el Product Owner (esto debería respaldarse, por
ejemplo, mediante la creación de una Definition of Ready estándar para historias de
usuario); y
3. garantizar que todas las historias de usuario se crean en un esfuerzo de
colaboración entre el Product Owner y el Equipo Scrum (el objetivo es una
comprensión compartida de las historias de usuario y, por lo tanto, la propiedad
conjunta).

El candidato debe tener en cuenta que aunque el Product Owner define el alcance del
Sprint (y la meta del Sprint), es una prerrogativa del Equipo Scrum para abordar la deuda
técnica y los errores durante el mismo Sprint (un equipo debe poder asignar hasta 25% de
su capacidad disponible para esto).

Pregunta 19

¿Con qué métricas evaluarías el valor de una historia de usuario?

Existen mediciones tanto cuantitativas como cualitativas que pueden usarse para evaluar el
valor de una historia de usuario o si su inversión vale la pena. Estos pueden incluir:
● aumento de ingresos,
● los beneficios de reducción de costos logrados por las mejoras de procesos internos
● aumentos en las tasas de satisfacción del cliente (NPS12),

12
NPS® (Net Promoter Score) es una métrica de fidelidad del cliente y una marca comercial
registrada de Fred Reichheld, Bain & Company y Satmetrix Systems.

@marcoviaweb
 ● Incrementos en los registros para nuevos productos, o
● comentarios positivos recibidos por el equipo de atención al cliente.

Pregunta 20

¿Cómo facilita la selección de historias de los usuarios de manera que se elijan las
historias más valiosas sin anular la prerrogativa del Equipo Scrum para definir su propio
compromiso?

Si un Equipo Scrum se involucra con la suficiente anticipación en la selección de historias

del usuario (preferiblemente mediante la creación conjunta de las historias con el Product
Owner) o en el Producto Discovery, es probable que un Scrum Master no tenga que
proporcionar orientación para ver que se elijan las historias más valiosas. La mayoría de los
equipos apoyarán las historias de usuario elegidas por el Product Owner para un Sprint
determinado.

Si un equipo recurre a elegir a su antojo - elegir historias de usuario solo para satisfacer sus
preferencias personales - durante el Sprint planning, el proceso de refinamiento del backlog
debe ser inspeccionado seriamente. Con toda probabilidad, el Product Owner está eligiendo
historias de usuario que no maximizan el valor para el cliente.

Pregunta 21

¿Cuánta capacidad de un Equipo Scrum, durante un Sprint regular, consideraría

adecuada para refactorizar? ¿Arreglando errores importantes? ¿Explorando nuevas
tecnologías o ideas?

Además de los Sprints durante los cuales hay tareas críticas y urgentes que deben
abordarse (como solucionar un problema que ha desconectado el sitio web), una buena
regla general es una asignación de 15-10-5 a la capacidad de un Equipo Scrum para
refactorizar, corregir, y la investigación.

En concreto, esto significa dedicar

● 15% de la capacidad de un equipo para la deuda técnica,
● 10% de la capacidad de un equipo para errores, y
● 5% de la capacidad de un equipo para spikes exploratorios (cuando sean
potencialmente útiles).

Un Equipo Scrum puede, por supuesto, desviarse de esto cuando se trata de Sprints
individuales. Pero, en general, las asignaciones consistentes cumplirán con la calidad del
código y los requisitos de mantenimiento de la mayoría de las aplicaciones de software.

Pregunta 22

@marcoviaweb
 ¿Debería el Product Owner asignar historias o tareas de usuario a miembros individuales
de un Equipo Scrum?

El Product Owner que asigna individualmente historias de usuarios a los miembros de un

Equipo Scrum no es ágil, y si el Product Owner está haciendo esto, es necesario detenerlo.
Se supone que los equipos de Scrum son auto-organizados. La asignación de historias de
usuarios y la distribución de tareas entre los miembros de un Equipo Scrum es una
prerrogativa del propio equipo. Prevenir este error debería ser una de las preocupaciones
más apremiantes del Scrum Master.

Pregunta 23

¿Cómo lidiar con los miembros del equipo que eligen tareas a su antojo?

Un Equipo Scrum tiene autonomía en la forma en que sus miembros eligen distribuir las
tareas, por lo que puede ser que una presunta selección de tareas por parte de los
miembros individuales del equipo sea, de hecho, una parte valiosa y crucial del camino del
equipo hacia su desempeño. Sin embargo, si los miembros del equipo se quejan de cómo
los demás están eligiendo sus tareas, el Scrum Master debe abordar el problema. Una
capacitación adicional podría ayudar a algunos miembros del equipo a adaptarse a una
mayor variedad de tareas. O quizás, otros miembros del equipo deban ser expulsados
suavemente de su zona de confort para que puedan elegir más fácilmente diferentes tipos
de tareas sobre las que se han acostumbrado.

Pregunta 24

A una historia de usuario le faltan los diseños finales de la interfaz de usuario, pero el
equipo de diseño se compromete en entregarlo el segundo día del próximo Sprint. El
Product Owner está bien con esta situación, y presiona para que la historia del usuario se
agregue al Sprint Backlog. ¿Qué piensas sobre este escenario?

El hecho de que se agregue una historia de usuario incompleta al Sprint Backlog depende
de las preocupaciones actuales del equipo y de la experiencia con las circunstancias que
causaron que la historia no cumpliera con su Definition of Ready. En el caso de un diseño
de interfaz de usuario (UI) incompleto o faltante, por ejemplo, si es casi seguro que el
equipo de diseño realice la entrega porque lo ha hecho en el pasado, si la historia del
usuario es de gran valor, si la historia puede ser lograda dentro del Sprint a pesar de que
sus entregables de UI llegan tarde, y si el equipo lo acepta, entonces una excepción puede
ser aceptable.

Tenga en cuenta que las excepciones tienen una tendencia a convertirse en prácticas
aceptadas. No se debe permitir que una intención de la organización de ser ágil omita el
refinamiento de la cartera de pedidos y el proceso de Sprint Planning. El candidato debe ser

@marcoviaweb
consciente de que tales situaciones no son sostenibles. Además, si la implementación de
una historia de usuario sujeta a tal excepción falla, nadie se molestará en leer la letra
pequeña y reconocer que se ha hecho una excepción. En su lugar, lo más probable es que
vean que el proceso ágil en sí ha fallado.

Sus candidatos pueden aceptar o rechazar excepciones al proceso ágil. Pero también
deben poder analizar las situaciones en las que se han hecho excepciones y explicar el
daño colateral al que puede estar expuesto el Equipo Scrum.

Pregunta 25

Un miembro del Equipo Scrum no quiere participar en el Sprint planning y considera que
las reuniones son una pérdida de tiempo. ¿Cómo lidias con esta actitud?

Si un miembro de un Equipo Scrum no quiere participar en el Sprint Planning y considera

que las reuniones son una pérdida de tiempo, están mostrando un tipo de comportamiento
pasivo-agresivo. Aunque no es específico de Scrum, este es un problema porque la actitud
subyacente es tóxica y afectará tanto la formación como el rendimiento del equipo.

Cuando el miembro de un Equipo Scrum se comporta como se describe, el Scrum Master

del equipo debe actuar. El comportamiento contraproductivo no puede ser ignorado ni
tolerado si el equipo debe continuar funcionando. Es probable que una acción efectiva
requiera una serie de pasos escalonados:
1. El Scrum Master debe comenzar dirigiéndose al miembro del equipo en privado para
discutir su reserva y, quizás, más coaching o un período de capacitación más largo.
2. Después de una discusión privada, todo el equipo puede participar haciendo de esta
situación un tópico de discusión durante una o más retrospectivas. Esto permite al
equipo ofrecer su apoyo.
3. Si todavía no hay ningún cambio en la actitud del miembro del equipo, se
recomienda una reunión con el miembro del equipo y su gerente.
4. Si no se puede lograr ningún cambio, podría ser posible reasignar al colaborador a
otro equipo (probablemente no ágil), o a un equipo kanban que probablemente no
obligue al miembro del equipo a salir de su zona de confort.

Situaciones como las que se describen resaltan que Scrum no es para todos.

Daily Scrums

Pregunta 26

¿Recomendaría Standups formales para todos los equipos, sin importar el tamaño o el
nivel de experiencia?

@marcoviaweb
Al responder a esta pregunta, su candidato debe mostrar sentido común con respecto a los
Standups formales. Los Standups son una parte importante de Scrum, pero no todos los
Standups tienen que ser formales. Un equipo pequeño, experimentado y co-localizado
puede usar un descanso para tomar café para su standup.

Sin embargo, adoptar un enfoque relajado e informal para los Standups de un equipo
grande con varios miembros juniors probablemente no logrará nada, si es primero no se
torna un caos. Para equipos grandes, es necesario una reunión formal para proporcionar
formato y orientación.

Para los equipos distribuidos que no pueden reunirse fácilmente para tomar un café, es
necesario un standup formal para adaptarse a las limitaciones técnicas, y debe programarse
y realizarse de manera organizada.

Pregunta 27

¿Crees que los miembros más experimentados del equipo esperen hasta el próximo
standup en pedir ayuda para superar un impedimento?

Cuando surge un impedimento, los miembros de un Equipo Scrum nunca deberían tener
que esperar, ni por un standup ni por ningún otro evento, para pedir ayuda. Un equipo que
espera para solicitar ayuda es un equipo que retrasa su progreso. Si los miembros más
experimentados de un Equipo Scrum están esperando el próximo standup antes de pedir
ayuda o lidiar con un impedimento, el Scrum Master debe hacer un trabajo de Team
Building.

Pregunta 28

¿Cómo maneja a los miembros del equipo que "lideran" los Standups, convirtiendo el
evento en una sesión de informe para ellos mismos?

No hay roles oficiales de liderazgo en Scrum. Sin embargo, no es raro que algunos
miembros de un Equipo Scrum asuman el liderazgo. Esto suele suceder cuando un
miembro de un equipo en particular posee una experiencia (técnica) superior, habilidades
de comunicación o simplemente un mayor nivel de participación.

Todos los equipos pasan por las etapas de desarrollo de grupo de Tuckman: formación,
enfrentamiento, normalización y desempeño. Los equipos de Scrum no son una excepción.

Es importante que cuando un miembro de un Equipo Scrum asuma el liderazgo, esto no

resulte en que otros miembros se reporten a ellos. Un Scrum Master debe estar atento e
intervenir si es necesario para garantizar que todos los miembros del equipo se comuniquen
y trabajen juntos, durante las luchas y otras cosas, en el espíritu de Scrum.

@marcoviaweb
Pregunta 29

¿Cómo gestionas a los miembros del equipo que consideran que los Standups son una
pérdida de tiempo y, por lo tanto, son tardíos, poco cooperativos o simplemente no
asisten?

Refiérase a la pregunta 25, donde se aborda en detalle cómo abordar esta actitud similar y
este problema de comportamiento. Las respuestas del candidato deben abordar esos
mismos puntos.

Pregunta 30

Los Standups del equipo no son atendidas por ningún stakeholder. ¿Cómo cambiarías
eso?

Hacer esta pregunta puede desencadenar fácilmente una discusión filosófica sobre si se
debe permitir a los Stakeholders ​participar en las reuniones de un Equipo Scrum. Intenta
evitar esto.

Si las Stakeholders participan en los Standups de un equipo, ¿es probable que resulte en
una forma de reporte que elude las reglas de Scrum? No necesariamente. Es bueno si se
puede hacer alguna adaptación de Scrum para que funcione para una organización. No se
debe descartar la posibilidad de permitir que los Stakeholders ​participen en los Standups si
el equipo lo encuentra aceptable.

De hecho, si los Stakeholders asisten a los Standups regularmente, esto invariablemente

mejora significativamente la comunicación entre un equipo y los Stakeholders.

Entonces, ¿cómo hace un Scrum Master para alentar a los Stakeholders a asistir a los
Standups? Hacer que valga la pena su tiempo. El Scrum Master puede lograr esto de varias
maneras: por ejemplo, puede ofrecer a los Stakeholders la oportunidad de aprender los
primeros detalles de un nuevo producto o feature, o pueden optar por darles la oportunidad
de hacer preguntas a los ingenieros directamente (sin pasar por el Product Owner).

Pregunta 31

¿Cómo abordas los Standups con equipos distribuidos?

Los Standups para los equipos Scrum cuyos miembros se distribuyen entre diferentes
oficinas o trabajan de forma remota no son muy diferentes de los Standups para los equipos
Scrum cuyos miembros comparten la ubicación. La excepción es que los equipos
distribuidos que comparten la actividad del tablero pueden requerir videoconferencias
cuando se trabaja con tableros offline que se reflejan entre sí.

@marcoviaweb
Si un Equipo Scrum está usando un software de planificación o gestión de tareas online
como JIRA, los tableros del equipo pueden estar online y las actualizaciones pueden
realizarse en pantalla. Esto generalmente facilita que los miembros de un equipo distribuido
sigan la actividad del tablero. Con los tableros online en su lugar, una llamada de Skype o
Google Hangouts13 probablemente será suficiente para que un equipo distribuido tenga su
Standup.

Pregunta 32

¿Puedes dibujar un ejemplo del tablero kanban offline de un Equipo Scrum?

En esta pregunta, el calificador ‘kanban’ es un teaser. Cualquier persona que realice una
entrevista para el rol de Scrum Master debe poder dibujar una simple tablero offline.

Normalmente hay cinco columnas (o filas) en un tablero offline:

1. Backlog
2. en progreso
3. revisión de código
4. aseguramiento de la calidad
5. Hecho

Se puede incluir información adicional o adjuntarse a cualquier tipo de tablero, por ejemplo,
● fechas de Sprint o reuniones,
● pruebas de aceptación del usuario (UAT),
● la Definition of Ready,
● un gráfico de quema (progreso y trabajo restante a lo largo del tiempo), y
● un estacionamiento (temas para discusión futura).

El candidato debe mencionar que un Scrum Master no está obligado a proporcionar al

Equipo Scrum un tablero offline. Una tablero es responsabilidad del equipo que trabaja con
ella. Sin embargo, el Scrum Master debe proporcionar un taller introductorio sobre el tema si
ningún miembro del equipo está familiarizado con los tableros offline.

Retrospectivas

Pregunta 33

¿Quiénes deberían participar en una retrospectiva?

13
Skype y Google Hangouts son populares aplicaciones de computadora basados en video.

@marcoviaweb
Solo los miembros inmediatos de un Equipo Scrum deben participar en las retrospectivas de
ese equipo. Es importante es que los gerentes de los miembros de un equipo no estén
presentes.

La única excepción es el Product Owner. En general, es una buena idea incluir al Product
Owner en las retrospectivas de un Equipo Scrum porque es un miembro crucial del equipo.
Pero no es obligatorio. Algunos equipos pueden preferir que el Product Owner no participe,
y los deseos de un equipo siempre deben ser considerados.

Pregunta 34

¿Se debe controlar la “salud” de un equipo durante una retrospectiva o es innecesario

hacerlo? Si lo haces, ¿Cómo lo harías?

Medir la “salud” de un Equipo Scrum, es decir, obtener una idea sobre los niveles actuales
de compromiso y satisfacción, es útil para identificar tendencias que pueden afectar la
productividad.

Un método efectivo para medir la “salud” de un Equipo Scrum es hacer circular un

cuestionario de opción múltiple en las retrospectivas del equipo. Un cuestionario que
requiere solo dos minutos para completarse y utiliza una escala simple para cada una de las
preguntas suele ser mejor, por ejemplo.
1. terrible
2. pobre
3. neutral
4. bueno
5. excelente

Durante la retrospectiva, al completar el cuestionario, el equipo debe discutir los resultados

con el objetivo de descubrir cualquier inquietud o frustración que puedan tener.

Pregunta 35

¿Qué formatos de retrospectiva has usado en el pasado?

Hay varios formatos de retrospectiva de uso común, y cada uno está diseñado para
adaptarse a diferentes situaciones. El candidato debe tener experiencia en la aplicación de
más de uno de estos formatos y debe poder compartir su lógica por haberlo hecho:

El formato clásico
● ¿Qué hicimos bien?
● ¿Qué deberíamos haber hecho mejor?

El formato del barco

@marcoviaweb
 ● ¿Qué nos está empujando hacia adelante?
● ¿Qué nos está frenando?

La retrospectiva de la estrella de mar.

● Empezar a hacer ...
● Hacer menos de ...
● Hacer más de ...
● Deja de hacer ...
● Continuar haciendo ...

Los formatos Diana Larsen y Esther Derby14.

● Preparar el escenario
● Recopilar datos
● Generar ideas
● Decide qué hacer
● Cerrar la retrospectiva.

Pregunta 36

¿Cómo prevenir el aburrimiento durante las retrospectivas?

Cuando se requiera asistir a una retrospectiva aburrida, los miembros de un Equipo Scrum
se aburrirán.

Existen muchas posibilidades de variación que pueden usarse para evitar que una
retrospectiva sea aburrida y que los miembros del equipo se aburran. Una ubicación
diferente, un formato diferente y el acortamiento o alargamiento del Time Box asignado son
solo algunas de las variaciones que se pueden probar. El Scrum Masters también puede
usar los elementos de acción elegidos por un equipo para alentar y estructurar las
discusiones sobre temas que son importantes para el equipo, creando así un compromiso a
través del reconocimiento. Los sitios web como Retromat ofrecen cientos de juegos y
ejercicios diferentes para que las retrospectivas sean agradables y valiosas para todo el
equipo.

No existe una solución única y, por lo tanto, no hay una sola respuesta correcta, ni al
aburrimiento ni a esta pregunta. Lo importante es que su candidato reconozca que el
aburrimiento con la rutina puede convertirse en un problema, y ​que hay formas de lidiar con
él.

Pregunta 37

14
Este es el formato descrito en el libro Agile Retrospectives: Making Good Teams Great por Diana
Larsen y Esther Derby.

@marcoviaweb
 Si el equipo elige elementos de acción razonables pero no los entrega, ¿cómo abordaría
la situación?

Durante una retrospectiva, generalmente se espera que los miembros de un Equipo Scrum
elijan una serie de elementos de acción (tareas a realizar). Si estos elementos de acción no
se completan posteriormente de manera oportuna, el Scrum Master debe realizar un
seguimiento.

Es posible que un equipo no esté completando los elementos de acción que eligió porque
se encontraron con un impedimento externo. Si este es el caso, el Scrum Master debe
abordar la causa, y el equipo puede ponerse al día durante un Sprint posterior. Sin
embargo, si no hay un impedimento externo, es probable que el problema se deba a la
motivación, la actitud o los problemas personales dentro del equipo. En este último caso, el
Scrum Master debe proporcionar a los miembros del equipo infractor el estímulo o la
motivación suficientes para superar el problema, y ​luego ver que cumplan con sus
compromisos.

Si un equipo no completa los elementos de acción que eligió y el problema no se puede

resolver, seleccionar elementos de acción se convierte en un ejercicio inútil y el equipo
sufrirá las consecuencias.

Pregunta 38

¿Cómo recomendarías realizar el seguimiento de los elementos de acción?

Se espera que un Scrum Master haga el seguimiento de los elementos de acción (tareas a
realizar) que los miembros de un Equipo Scrum seleccionan durante las retrospectivas de
su equipo. Una buena manera para que un Scrum Master haga esto es comenzar a hablar
sobre el estado de los elementos de acción seleccionados durante la última retrospectiva
antes de elegir otros nuevos iniciando una discusión en el Inicio de cada nueva
retrospectiva. Si esta discusión descubre elementos de acción seleccionados durante una
retrospectiva anterior que no se completó como se esperaba, el equipo debe entender por
qué y evitar que vuelva a ocurrir.

Métricas Agile

Pregunta 39

¿Existe alguna métrica estándar a la que harías seguimiento? Si es así, ¿Cuál y con qué
propósito?

@marcoviaweb
Al realizar el seguimiento de las métricas a nivel organizativo, los efectos de cualquier
proceso o cambio se pueden medir cuantitativamente con un modelo de puntuación de
métricas. Los impactos medidos incluirían:
● la capacidad de responder a los cambios y producir un código valioso (por ejemplo,
la capacidad de desglosar las funciones);
● la dualidad de la planificación tanto en el lanzamiento como en el Sprint;
● la flexibilidad para adaptarse a los hechos cambiantes, los cuadros de tiempo y la
entrega continua;
● la frecuencia con la que los Equipos Scrum están ofertando por historias, y si los
equipos están ejerciendo alguna libertad en su enfoque para resolverlos;
● la creación y el crecimiento de una cultura de aprendizaje compartido; y
● La continuidad con la que se entregan las características.

El diseño de un modelo de puntuación de métricas debe tener en cuenta la madurez ágil de

la organización, de modo que los aspectos cualitativos puedan cuantificarse y, por lo tanto,
compararse. Si el modelo de puntuación de métricas se puede diseñar antes de introducir
un marco ágil en una organización, se debe estudiar el status quo para establecer una línea
de base contra la cual medir estos efectos y rastrear su evolución en el tiempo.

Cualquier métrica útil para medir los efectos de un proceso o cambio relevante debe
registrarse con regularidad, durante todo el viaje ágil. Encuestar a los miembros de los
Equipos Scrum de una organización es un buen comienzo.

Pregunta 40

El Equipo Scrum no está cumpliendo con los compromisos y su velocidad es inestable.

¿Cuáles son las razones más probables de este problema y cómo lo abordaría con el
equipo?

Si un Equipo Scrum muestra una velocidad inestable y no cumple con sus compromisos,
sugiere que la velocidad se está utilizando como la métrica prevalente para medir el
progreso de ese equipo. El candidato debe mencionar esto y hablar sobre la notoriedad de
la "velocidad" como una métrica de la industria para medir el progreso de un equipo.

Además, deberían poder explicar por qué la velocidad es una métrica ágil dudosa, y señalar
que las métricas cuantitativas no son ideales para medir el progreso de un equipo en el
dominio del Scrum. Hay muchos factores que pueden hacer que la velocidad de un Equipo
Scrum sea inestable:
● nuevos miembros del equipo están siendo incorporados;
● miembros experimentados que abandonan el equipo;
● el equipo que trabaja en territorio inexplorado;
● el equipo que trabaja con código heredado, probablemente sin documentar;
● el equipo se encuentra con una deuda técnica inesperada;
● vacaciones y baja por enfermedad reduciendo la capacidad del equipo;
● una intervención ejecutiva que cambia el alcance de un Sprint; y

@marcoviaweb
 ● el equipo aborda los errores prioritarios.

Otra causa común para que un Equipo Scrum no cumpla constantemente con sus
compromisos es que los compromisos del equipo con frecuencia son demasiado agresivos.
Esto podría indicar que las historias de usuario están mal preparadas (por ejemplo, no
cumplen con la Definition of Ready del equipo), lo que dificulta la estimación de las historias
por parte del equipo. A la inversa, los proyectos que reciben el equipo pueden sufrir un
código heredado mal documentado, una deuda técnica excesiva o simplemente un código
demasiado defectuoso y mal escrito, todo lo cual hace que la estimación sea una apuesta.

El candidato no debe alinearse con la falacia de que una adopción ágil funciona solo porque
el compromiso y la velocidad de un Equipo Scrum están alineados.

Pregunta 41

¿A qué métricas ágiles cualitativas consideraría realizar seguimiento?

El propósito de las métricas cualitativas en Agile es obtener información sobre cómo uno o
más de los equipos Scrum de una organización están progresando con Agile.

Hay varias pruebas de autoevaluación disponibles que un Equipo Scrum puede ejecutar
regularmente para recopilar métricas cualitativas sobre su implementación de Scrum; Scrum
Checklist por Henrik Kniberg es un buen ejemplo. El intervalo de prueba a través de la
autoevaluación es cada 4 a 12 semanas, con equipos de menor madurez que realizan sus
pruebas en el extremo inferior de este rango. Los valores individuales registrados por estas
pruebas no son muy importantes, pero la tendencia en el tiempo es. Para visualizar estas
tendencias, el Scrum Master deberá agregar los resultados; en el caso del Checklist de
Henrik Kniberg, se puede crear un mapa de práctica ágil15 a lo largo del tiempo.

Si bien las pruebas de autoevaluación, como el Checklist de Henrik Kniberg, suelen ser
ejercicios de equipo para registrar métricas de implementación, las métricas de sentimiento
se capturan mejor mediante ​encuestas de opinión anónimas para asegurar la
participación de los miembros más introvertidos del equipo. En las encuestas de opinión, las
preguntas típicas para registrar métricas de sentimiento incluyen:
● ¿Qué valor entregó el equipo en el último Sprint?
● ¿Ha aumentado o disminuido el nivel de deuda técnica durante el último Sprint?
● ¿Estás contento de trabajar con tus compañeros de equipo?
● ¿Recomendaría su empleador (o cliente) a un amigo que busca un nuevo trabajo?

Es mejor hacer encuestas de opinión después de cada Sprint; estas encuestas solo deben
requerir unos segundos para completar. Al igual que con las pruebas de autoevaluación, los
valores individuales registrados al realizar encuestas de opinión anónimas no son muy

15
Un mapa de práctica ágil es un método de organización de historias de usuario para evitar fallas
que pueden ser causadas por la entrega incremental.

@marcoviaweb
importantes, lo que importa es la tendencia en el tiempo. Las tendencias derivadas de estas
encuestas son excelentes puntos de conversación durante las retrospectivas de un equipo.

Con respecto a las métricas en general, el candidato debe respaldar el Manifiesto Ágil y su
principio de transparencia: todas las métricas deben estar disponibles para todos los
miembros de un Equipo Scrum, y en gran parte también para aquellos que trabajan en la
Organización del Product Delivery16 en general.

Cómo iniciar una transición a Scrum

Pregunta 42

¿Cómo te prepararías para iniciar la transición a Scrum?

Si no sabes a dónde vas, cualquier camino te conduce allí. El candidato debe comprender
que una transición ágil debe tener un objetivo y una meta, lo que significa planificar con
anticipación.

Prepararse para iniciar la transición a Scrum es escuchar y observar: el candidato debe

expresar interés en entrevistar a tantos miembros del equipo y Stakeholders como sea
posible, antes de entrar en acción. Estas entrevistas deben incluir a todos, sin importar su
rol (ingenieros, profesionales de control de calidad, control de calidad de vida y UX,
gerentes de producto) para identificar los patrones subyacentes a los problemas actuales,
fallas y disfunciones dentro de la organización. La fusión de esos patrones con los
problemas técnicos y comerciales más apremiantes identificará los objetivos más probables
para los primeros equipos de Scrum. Esta fase de observación, durante la cual un Scrum
Master realiza sus entrevistas, generalmente requerirá entre cuatro y ocho semanas,
dependiendo del tamaño y la estructura de la organización.

La capacitación de los futuros miembros del equipo y las Stakeholders debe comenzar y ser
paralela a las entrevistas.

Crear los primeros Equipos Scrum a partir de los departamentos de ingeniería y productos
existentes es el segundo paso para iniciar una transición al Scrum.

Su candidato debe ser capaz de esbozar el plan aproximado de una transición y abordar los
problemas comunes que pueden surgir durante el inicio.

Pregunta 43

¿Cómo crearías el primer Equipo Scrum?

16
La Organización del Product Delivery es, efectivamente, todos los miembros de una organización
que participan en llevar el producto al mercado.

@marcoviaweb
Cuando una organización está haciendo la transición a Scrum y al mismo tiempo se
enfrenta a importantes problemas de organización, comerciales y técnicos, los miembros
fundadores de sus Equipos Scrum deben ser voluntarios que entiendan completamente el
desafío que se les presenta, en lugar de personas que entran en servicio. Los mejores
voluntarios son aquellos deseosos de demostrar que volverse ágil es la forma más efectiva
de alcanzar un objetivo.

Los candidatos para el rol de Scrum Master deben ser lo suficientemente astutos como para
sugerir invitar a todos los miembros del equipo de entrega de productos, así como a los
ejecutivos de nivel C que patrocinan la transición, a una reunión inicial. El objetivo de una
reunión de inicio de la transición es apoyar a los miembros de los equipos de ingeniería y de
productos en la forma en que deciden autoorganizarse en los primeros equipos de Scrum
multifuncionales. Las reuniones de inicio de la transición pueden durar algunas horas o
varios días, según las circunstancias de una organización en particular.

A pesar de la importancia de la reunión de inicio para una transición de Scrum, profundizar

en su estructura tomará mucho tiempo de la entrevista. Es más importante que sus
candidatos presenten una breve hoja de ruta de lo que debería suceder a continuación para
los equipos de Scrum recién formados.

Si bien dependen algo de las habilidades, la experiencia y la capacitación existentes de los

miembros de los nuevos Equipos de Scrum de una organización, sus candidatos deben
anticipar tener que enseñar los conceptos básicos del Scrum después de una reunión de
inicio. Podrían proponer hacer esto a través de una serie de talleres o capacitación en el
trabajo con ejercicios de refinamiento del Product Backlog, escribiendo historias de
usuarios, estimando y creando tableros offline.

Pregunta 44

¿Qué recomendaría trabajar primero a un Equipo Scrum de reciente formación?

El primer problema crítico para la mayoría de los Equipos de Scrum recién formados es el
atraso existente del producto heredado. Las respuestas a esta pregunta no tienen por qué
referirse a las etapas de desarrollo del equipo de Tuckman, a los ejercicios adicionales de
creación de equipos o a cualquier tipo de capacitación o taller sobre Scrum que no esté
relacionado con la acumulación de productos.

Es una rara ocasión para que un Scrum Master comience desde cero con un equipo
completamente nuevo y sin un producto existente, incluso más en una organización
naciente como una startup. En la mayoría de los casos, es una organización de entrega de
productos existente con productos y servicios existentes que "se volverá ágil". Para estos
casos, el candidato debe señalar que el primer paso práctico es refinar el Product Backlog
heredado.

@marcoviaweb
El Product Backlog heredado por si es un artefacto interesante porque proporciona
información completa sobre el historial de la organización del Product Delivery: este atraso
en particular permite identificar la deuda de la organización, las insuficiencias de los
procesos, las decisiones cuestionables de los productos y otros anti-patrones. Al observar
una acumulación de productos heredados, un candidato excelente podrá señalar algunos de
estos anti-patrones (por ejemplo, tickets obsoletos o mal conservados), y ofrecer una buena
idea sobre cómo transformar el Backlog heredado en un Backlog bien refinado y actual del
producto, de modo que un nuevo Equipo Scrum (incluido el Product Owner) pueda trabajar
con él.

Los candidatos deben mencionar que la ejecución de un taller de refinamiento del Product
Backlog crea una buena oportunidad para proporcionar un nuevo Equipo Scrum y
capacitación práctica del Product Owner con Scrum. Esto se debe a que un taller de
refinamiento de trabajos pendientes generalmente cubrirá la creación de historias de
usuarios, la transferencia de conocimiento entre los miembros del equipo, el proceso de
estimación (si corresponde), las métricas de introducción ágil, el análisis técnico de deudas
y otros temas críticos para Scrum.

Anti-patrones de Scrum

Pregunta 45

¿En qué anti-patrones podría caer un Scrum Master durante un Sprint?

Los anti-patrones en los que un Scrum Master podría caer durante un Sprint impedirán la
productividad de un equipo. Los más típicos de estos se resumen aquí. Es la obligación del
Scrum Master evitar que estos anti-patrones se manifiesten.

Interrupción del flujo

El Scrum Master permite a las Stakeholders interrumpir el flujo de trabajo del equipo
de desarrollo durante el Sprint.

Hay varias formas posibles de que las Stakeholders puedan interrumpir el flujo de un
equipo durante un Sprint:
● El Scrum Master tiene una política de Laissez-Faire con respecto al acceso al
equipo de desarrollo.
● El Scrum Master no se opone cuando la administración invita a los ingenieros
a reuniones aleatorias como expertos en la materia.
● Por último, el Scrum Master permite que las Stakeholders o los
administradores convierten el Scrum diario en una sesión de informes.

Falta de apoyo
El Scrum Master no es compatible con los miembros del equipo que necesitan ayuda
con una tarea.

@marcoviaweb
 Los equipos de desarrollo a menudo crean tareas que un ingeniero puede terminar
en un día. Sin embargo, si alguien tiene dificultades con una tarea durante más de
dos días sin expresar que necesita ayuda, el Scrum Master debe abordar el
problema. Es importante destacar que esta es también la razón para marcar las
tareas en un tablero físico con puntos rojos cada día si no se han movido a la
siguiente columna.

Microgestión
El Scrum Master no impide que el Product Owner, o cualquier otra persona, asigne
tareas a los ingenieros.

El equipo de desarrollo normalmente se organiza sin intervención externa. Y el

Scrum Master debería actuar como el escudo del equipo a este respecto.

#NoRetro
El Scrum Master no recopila datos durante el Sprint que respalda al equipo en la
próxima retrospectiva.

Esto se explica por sí mismo.

Pregunta 46

¿Qué anti-patrones sabes que pueden ocurrir durante una retrospectiva?

Los anti-patrones típicos de una retrospectiva incluyen:

Pérdida de tiempo
El equipo no valora colectivamente la retrospectiva.

Si algunos miembros del equipo consideran que la retrospectiva tiene poco o ningún
valor, lo más frecuente es que la retrospectiva sea el problema. ¿Es el mismo
procedimiento cada vez, ritualizado y aburrido? Tener una meta-retrospectiva sobre
la retrospectiva en sí. Cambiar el lugar. Tener una cerveza o vino retrospectiva. Hay
muchas cosas que un Scrum Master puede hacer para que las retrospectivas sean
interesantes y valiosas, reduciendo la tasa de ausencias. Además, es bueno
recordar que (en nuestra experiencia) a los introvertidos, no solo a los extrovertidos,
les gusta participar en retrospectivas.

Presos
Algunos miembros del equipo solo participan porque están obligados a formar un
equipo.

No presione a nadie para que participe en una retrospectiva. En su lugar, haz que
valga la pena. El impulso de mejorar continuamente como equipo debe ser
alimentado por una motivación intrínseca, no por el miedo o la orden. Consejo: El

@marcoviaweb
 ejercicio de Retromat “¿Por qué estás aquí?” es un buen inicio para una
retrospectiva de vez en cuando.

Día de la marmota
La retrospectiva nunca cambia en composición, lugar o duración.

En este caso, es probable que el equipo vuelva a revisar los mismos problemas una
y otra vez, como el día de la marmota, sin el final feliz.

Realizarlo en el siguiente Sprint

El equipo pospone la retrospectiva hasta el próximo Sprint.

Más allá de la tarea de "inspeccionar y adaptar", una retrospectiva sirve como un

momento de cierre, ayudando a reajustar la mente de todos para que el equipo
pueda centrarse en el objetivo del próximo Sprint. Esa es la razón por la que
tenemos una retrospectiva antes de planificar el Sprint de seguimiento. Posponer
una retrospectiva hasta el próximo Sprint también puede interrumpir el flujo del
equipo, retrasando así posibles mejoras. Por estas razones, es importante realizar
una retrospectiva antes de planificar el siguiente Sprint.

#NoDocumentation
Nadie está tomando minutos para su uso posterior.

Una retrospectiva es una inversión sustancial por muchas razones y debe tomarse
en serio. Tomar notas y fotos apoya el proceso.

Sin seguridad psicológica

Cada retrospectiva es un ciclo interminable de culpas y señalamientos.

En el equipo ganan o pierden todos. Desafortunadamente, el juego de la culpa indica

tanto el fracaso del Scrum Master como el facilitador de una retrospectiva como la
falta de madurez y habilidades de comunicación de un equipo.

Intimidación
Uno o dos miembros del equipo dominan la retrospectiva.

Este comportamiento de comunicación es a menudo el signo de un Scrum Master

débil o desinteresado. La retrospectiva debe ser un lugar seguro donde todos, los
introvertidos incluidos, puedan abordar los problemas y proporcionar sus
comentarios de forma gratuita de los miembros del equipo que dominan la
conversación, intimidan o intimidan a otros compañeros de equipo. Si no se
proporciona un lugar seguro, los participantes abandonarán la retrospectiva y los
resultados quedarán obsoletos. Es responsabilidad principal del Scrum Master
garantizar que todos puedan ser escuchados y que tengan la oportunidad de
expresar sus pensamientos. Según Google, el tiempo de habla distribuido de
manera equitativa fomenta y significa un equipo de alto rendimiento.

@marcoviaweb
 Alerta de Stakeholders
Los Stakeholders participan en la retrospectiva.

Hay muchas ceremonias de Scrum que abordan las necesidades de comunicación

de las Stakeholders: la revisión del Sprint, el refinamiento del Product Backlog, los
Standups, sin mencionar las oportunidades para conversar en los enfriadores de
agua, tomar un café o durante el almuerzo. Si esas posibilidades de comunicación
aún no son suficientes, celebre reuniones adicionales. La retrospectiva es para el
equipo y debe estar fuera del alcance de los stakeholders.

Pasividad
Los miembros del equipo están presentes, pero no están participando.

Existen muchas razones para tal comportamiento: los miembros del equipo
consideran que la retrospectiva es una pérdida de tiempo, no es seguro o los
participantes están aburridos por su capacidad de predicción. Los miembros del
equipo también pueden temer las repercusiones negativas si estuvieran ausentes ...
o quizás se contrató involuntariamente un grupo homogéneo de introvertidos.
Cualquiera sea la razón, es probable que no haya una solución rápida. El Scrum
Master debe determinar qué estilo de retrospectiva funcionará mejor en el contexto
de su organización.

Pregunta 47

¿Cómo puede usted (como Scrum Master) identificar dónde se necesita mejorar?

¿Cómo puede un Scrum Master identificar dónde se necesita mejorar? Es una pregunta
simple, con una respuesta simple: un Scrum Master debería preguntarle a su equipo y a los
Stakeholders cómo creen que se podría mejorar.

Scrum Masters pueden ejecutar retrospectivas en sí mismos. Una retrospectiva dedicada es

mucho más efectiva que pedir sugerencias sobre cómo se puede mejorar durante los
últimos minutos de las retrospectivas regulares del equipo.

@marcoviaweb