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 el Development Team. En la Daily Scrum, el Development Team inspecciona y adapta el Sprint Backlog de cara a organizar el trabajo del Sprint.
El resto de roles, e incluso stakeholders, pueden asistir bajo petición del Development Team 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.
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. El Dev Team se encarga de contar los problemas que han surgido, cómo los han resuelto y demostrar cuáles son los PBIs que se han finalizado. El accountable es el Product Owner y el Development Team le ayuda.
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 el Development Team y, por tanto, es un ejemplo de madurez el que no necesiten al Scrum Master para conducirla.
5. ¿Cuándo un miembro del Development Team se hace dueño de un Item del Sprint Backlog?
Nunca, realmente el Development Team es propietario de todos los items y responsable 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 miembros del Development Team tienen tareas durante el Sprint?
El Development Team se autoorganiza, 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 autoorganizarse. 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? (elige 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 es el Development Team. Respecto al formato, no es de pie, eso es solo una técnica. El Development Team decidirá qué formato quiere utilizar, esto lo aclararon en la última versión de la guía.
8. ¿Cuáles de estas acciones se realizan 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 hacen 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.
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 el Development Team realiza 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. El Development Team se reúne y crea un plan para el Sprint, lo que llamamos Sprint Backlog. Por último, se reúnen con el Product Owner para explicarle en qué consiste ese plan y cómo van a trabajar.
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 al Development Team 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.
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? 🙂
