Aprovechando estos días de confinamiento y coronavirus, queremos pasaros un test de Scrum que creamos hace tiempo, para evaluar a posibles candidatos a Scrum Master. El test tiene preguntas de diferente dificultad. Os explicamos las respuestas correctas en la parte inferior,¡esperemos que os guste!
1. Qué frase describe mejor a Scrum?
La respuesta correcta es un marco de trabajo para crear productos complejos en entornos complejos. Scrum es muy útil en situaciones en las que hay mucha incertidumbre, ya que la inspección y la adaptación contínuas nos permiten tomar decisiones a medida que aprendemos y tenemos datos del equipo. Además, Scrum es un marco, lo que permite “jugar” de muchas maneras.
2. ¿Quién debe asistir a la Daily Scrum?
Cuando decimos “debe” referimos a obligatoriedad. En este caso, la Daily Scrum es por y para los Developers. En la Daily Scrum, los Developers inspeccionan y adaptan el Sprint Backlog de cara a organizar el trabajo del Sprint.
El resto de roles, e incluso stakeholders, pueden asistir bajo petición de los Developers o bajo el acuerdo de todo el equipo. Si asisten, hay que evitar el reporte a esas figuras y que participen activamente. El Scrum Master velará por todo ello, pero en principio no deben asistir.
En Scrum2020 se aclara que, si el Product Owner y el Scrum Master participan de la creación del producto, se les considera Developers a todos los efectos, entre ello asistir a la Daily Scrum.
3. ¿Quién debe presentar la Sprint Review?
A la hora de “presentar” nos referimos a las personas que tienen una parte protagonista a la hora de mostrar el producto. El Product Owner trata todo lo referente a los PBIs que se han terminado en este Sprint y la conversación referente al futuro del producto y su impacto en mercado. Los Developers se encargan de contar los problemas que han surgido, cómo los han resuelto y demostrar cuáles son los PBIs que se han finalizado. El Scrum Master garantiza que la Sprint Review es un evento de trabajo para inspeccionar y adaptar. El accountable es el Scrum Team al completo.
4. ¿Cuál es el motivo principal para que un Scrum Master esté en la Daily Scrum?
La misión del Scrum Master es asegurarse de que la Daily Scrum se hace bien, al igual que el resto de Scrum. La Daily Scrum es para los Developers y, por tanto, es un ejemplo de madurez el que no necesiten al Scrum Master para conducirla.
5. ¿Cuándo un Developer se hace dueño de un Item del Sprint Backlog?
Nunca, realmente los developers son propietarios de todos los items y responsables de su desarrollo. Es cierto que en muchas herramientas digitales nos asignamos los items para organizarnos, pero eso no nos resta responsabilidad. Si un compañero no finaliza un item, el resto del equipo es corresponsable. Con esta regla, buscamos generar más ambiente de equipo y mejorar las relaciones entre los miembros. Frases como “esto no es mío” o “esto no lo he hecho yo” generan desconfianza y afectan a la entrega de valor del equipo.
6. ¿Quién debería asegurarse de que todos los Developers tienen tareas durante el Sprint?
Los Developers se autoorgestionan, lo que supone que ellos son responsables de hacer seguimiento del Sprint, repartirse tareas, cubrir la calidad definida, respetar reglas de equipo o resolver conflictos internos. El Scrum Master estará ahí para ayudarles y conseguir que mejoren en estos aspectos, pero son ellos los responsables de autogestionarse. Evidentemente, esto no es nada fácil y por eso existe la figura del Scrum Master.
7. ¿Cuáles de las siguientes opciones son obligatorias en la Daily Scrum? (marca 5)
Esta pregunta es un poco más complicada al ser multirespuesta. La Daily Scrum tiene una duración máxima de 15 minutos y no depende de las personas que asistan. El objetivo es inspeccionar y adaptar nuestro Sprint Backlog, para poder tomar decisiones, en el Sprint, con respecto a nuestro Sprint Goal. Pueden asistir stakeholders, aunque los únicos participantes requeridos son los Developers. Respecto al formato, no es de pie, eso es solo una técnica. Los Developers decidirán qué formato quieren utilizar. Las tres preguntas no eran obligatorias y, de hecho, han sido eliminadas de la guía en la edición de 2020.
8. ¿Cuáles de estas acciones se podrían realizar en una Sprint Review? (marca las que apliquen)
Esta pregunta tiene algo de trampa (lo reconozco). Realmente hay que marcar todas las respuesta ya que todas son válidas y todas se hacían en la Sprint Review. Ya hicimos hace tiempo un test sobre este evento en el que contamos cada paso.
En la Sprint Review, inspeccionamos el incremento y adaptamos el Product Backlog si fuera necesario. Durante el evento, buscamos la colaboración de los stakeholders y del Scrum Team, para entender si nuestro producto está funcionando. Por eso, hay hablamos sobre el estado actual del producto, enseñamos los elementos terminados y demostramos que están terminados, desarrollamos los próximos pasos, estudiamos el impacto en el mercado (con métricas por ejemplo) y todo ello lo volcamos en el Product Backlog.
En la versión 2020 de la guía, se ha simplificado ampliamente la Sprint Review y se considera que todos estos pasos no habría que seguiros de manera estricta. Eso sí, la Sprint Review sigue siendo un evento de trabajo, donde podamos analizar el impacto de nuestro producto con respecto al mercado. Por eso, hemos puesto al palabra «se podrían realizar», como acciones que suelen tener sentido.
9. ¿Cuáles de las siguientes opciones deberían ocurrir en una Retrospectiva?
Esta pregunta es complicada por la cantidad de opciones. Son todas menos la de que “no sea obligatoria” (obviamente una Retrospectiva es obligatoria). Pueden venir stakeholders, si son invitados, pero estará formada por el Scrum Team completo. Uno de los errores típicos es que lo facilite el Scrum Master siempre, como si el evento fuera suyo. Realmente, es un evento del Scrum Team y cualquiera puede facilitarlo. El resto de opciones son verdaderas.
10 ¿Qué partes son obligatorias en una Sprint Planning?
Para la Sprint Planning, hay que aclarar qué partes son necesarias para que funcione (aunque podemos añadir más si nos aporta). Al principio, trabajaremos el “qué” vamos a hacer. Para esto, el Product Owner explica los items que le gustaría que se desarrollasen y los Developers realizan preguntas para clarificar el alcance. Tras esta conversación, podremos determinar entre todos el Sprint Goal al que podemos aspirar.
Una vez hemos hablado del qué, toca hablar del cómo. Los Developers se reúnen y crea un plan para el Sprint.. Por último, se reúnen con el Product Owner para explicarle en qué consiste ese plan y cómo van a trabajar. La suma del Sprint Goal, los items selecionados (forecast) y el plan de trabajo es lo que conocemos como Sprin Backlog.
El resto de opciones podrían ocurrir, pero no son obligatorias. Por ejemplo, podemos usar Historias de Usuario, no obstante, no son obligatorias en Scrum. Que el Product Backlog esté refinado no es obligatorio, pero sí muy recomendable.
11. ¿Qué precondición se debe dar para comenzar con una Sprint Planning?
La Sprint Planning no tiene precondiciones, más allá de que asistan las personas que tienen que asistir y que tengan acceso al Product Backlog. Es un evento al que se traen los deberes hechos (Product Backlog refinado)y, así, podemos ir más rápido y hacerlo más efectivo, pero no es obligatorio. Pueden existir objetivos de Negocio, cuya existencia dependerá de la capacidad del equipo de decidir si es viable su acometida ¡Nadie le puede decir a los Developers la cantidad de trabajo que van a ser capaces de hacer!
12. ¿De qué rinde cuentas un Product Owner en Scrum?
Cuando hablamos de un Product Owner, recordemos que su función principal es maximizar valor de su producto y del propio equipo. Su trabajo principal es ese y, por tanto, las organizaciones que apuesten por un marco como Scrum deben tener muy claro, a la hora de medir, el trabajo de las personas.
13. ¿De qué es responsable un Scrum Team?
Esta pregunta tiene bastante trampa, ¡y cúal no! Puede ser uno de los cambios mas disruptivos de la nueva guía Scrum. Un Scrum Team es responsable de todo lo que tenga que ver con su producto, mucho más que su desarollo. Eso incluye cualquier actividad, como ponerle precio o el marketing. ¡Todo debe depender del Scrum Team! Además, el equipo es responsable de que se entregue valor en cada Sprint.
Conclusiones
Esperamos que os haya gustado este test, un poco largo y complicado. Los mejores exámenes que he visto en certificaciones son aquellos que se centran en casos prácticos y, no tanto, en el detalle de la guía Scrum. Aún así, dominar la guía es el papel de un Scrum Master, y sigo viendo a muchos que se la han leído una o dos veces o, peor aún, todavía no se la han leído.
Hace tiempo, mi compañera Esther y yo escribimos un libro para entender mejor la guía: ¡mola Scrum, ¡pero que lo haga otro!, por si necesitáis bibliografía.
Y tú, ¿qué preguntas has fallado? 🙂
