Scrum está formado por cinco eventos de los cuales dos son la Sprint Planning donde planificamos el Sprint y la Sprint Review donde inspeccionamos el incremento. Ambas tienen su función dentro del marco, sin embargo creo que en muchos equipos hay una descompensación.
Muchos equipos se centran más en hacer una buena Sprint Planning que una buena Sprint Review, aunque admito que el timebox es el doble en el caso de la Planning no me refiero al tiempo dedicado sino a la preocupación por hacerlo bien. Algunos síntomas que nos ayudan a identificarlo es cuando vemos equipos que sufren cuando lo que dijeron que pasaría en la Planning no ocurre durante el Sprint, equipos que solo se dedican a sacar cartas durante el evento, otros que tratan de llenar todo el Sprint de cada persona del equipo de manera muy detallada. Sin embargo, en la Sprint Review no acude ningún Stakeholder, o peor aún, no acude ni el Product Owner y no los ves ni la mitad de preocupados.
Fallamos en la Sprint Planning
Después llega la Sprint Retrospective y el equipo se preocupa porque “fallaron en la Planning “ sin hablar sobre la Review. ¿Qué es fallar la Sprint Planning? ¿Qué no ha ocurrido lo que creías? ¿Te sientes mal porque no has sido capaz de predecir el futuro? Sin embargo fallar en una Review es que no tienes incremento, que no tienes nada que entregar o que no eres capaz de inspeccionar. ¡Esto sí es grave!
En equipos poco maduros ocurre esto porque aún tienen la mentalidad de proyecto. Quieren que su plan de proyecto ocurra a base de pequeñas iteraciones sin preocuparse de inspeccionar el incremento y su impacto en el negocio porque solo les interesa el % de avance respecto a una fecha final que les han impuesto.
Deja de buscar la Planning infalible, la técnica de estimación perfecta, el tablero físico definitivo o el Jira del que te sientes orgullo. Todo eso ayuda, no digo que no, pero cuidado, un equipo que es feliz porque acierta su estimación es un equipo que no ha entendido que hacer software es entregar valor. Lo que de verdad hará que te sientas bien, es que la hipótesis de lo que era valor realmente se cumplió y los usuarios están contentos porque han recibido lo que necesitaban. ¡Esta es la clave de Scrum!
La Sprint Review es la clave de Scrum
Después de leer el libro de Robert Galen titulado Scrum Product Ownership os comento algunos consejos del libro mezclado con ideas que he podido ver de los que equipos que he tenido la suerte de acompañar:
- Si eres Scrum Master trata de que el Product Owner sea accountable del evento y que su organización entienda la importancia del mismo
- Consigue a los Stakeholder adecuados. Es importante que vengan y que vengan las personas que más te puedan aportar.
- Pon en el calendario la reunión con tiempo para evitar otros eventos de los Stakeholders.
- Demuestra el incremento. Pero cuidado, no se trata de enseñar funcionalidad sino el valor de dicha funcionalidad.
- Trata de responder a la pregunta ¿Hemos ayudado al negocio en este Sprint?
- Tómatelo si quieres como una venta, como diría mi compañera Laura Argüello esto hay que venderlo a la audiencia.
- Habla del futuro, pero no en términos de fecha y alcance sino de valor entregado a futuro.
- Responde a la pregunta ¿Cómo vamos a ayudar al negocio en los próximos Sprints?
- Trata los impedimentos que el Scrum Team no es capaz de resolver, quizás algún stakeholder pueda ayudar. La transparencia da miedo pero ayuda.
- Dado que vas a inspeccionar y adaptar, ten el Product Backlog abierto para anotar todo lo que aprendas.
Por tanto, si estás haciendo Scrum piensa sobre tu Sprint Planning y tú Sprint Review y cuál te interesa mejorar. Y sobretodo reflexiona… ¿Eres feliz por acertar una estimación o porque lo que entregues de valor a la organización?
