Como Sabotear Scrum: User Stories

La mayor cantidad de empresas que he visto fracasar sus procesos usando Scrum tienen un común denominador: "un mal" Product Owner. Listo, ya sabes cómo sabotear Scrum :)

Ahora bien, si lo que deseas es entender cómo reducir la posibilidad de fallar con Scrum, necesitamos entrar más a detalle con cómo un "mal" Product Owner funciona (o mejor dicho no funciona).

Lo irónico de este artículo es que una de las formas en las que puedes sabotear Scrum es aplicando mal una técnica que no es de Scrum, si no de XP.

¿Listo? Hablemos un poco sobre las historias de usuario.

En realidad las User Stories son bastante sencillas. Una user story es un texto pequeño de forma:

Como <Tipo de usuario> quiero <hacer algo> para <tener este beneficio>

Solo reemplaza los < > por información real y ¡Listo! ¡Tienes tu user story! Parte tus requerimientos en pequeños sub-requerimientos usando este formato . Pídele a tu Product Owner que sea muy específico agregando todas las user stories que necesite para incluir hasta el más pequeño y simple detalle. Las stories están tan bien escritas y con todos los detalles que el equipo de desarrollo logrará entender lo que estás pidiendo y ya solo tienen que desarrollarlo.

¿Correcto? Lamentablemente NO! Si estás haciendo esto es muy probable que fracase tu implementación de Scrum.

¿Qué estamos haciendo mal? Aparte de que necesitarás miles de user stories para poder describir todo lo que quieres (haciendo más difícil el mantenimiento del Product Backlog), sigues con la mentalidad waterfall, de primero escribo todo perfecto en un gran libro y después tú leyendo el libro debes entender (y asumir algunos detalles adivinando mi mente) lo que quise decir.

1. Si bien el formato que te presenté arriba es el correcto, ese texto de por si solo es 1/3 de lo que es una historia de usuario. 

Recordemos que ágil se trata de mejorar la comunicación entre personas y asegurarnos que todos entendemos la base de lo requerido e iremos descubriendo juntos nuevas cosas mientras avancemos. 

Una user story está conformada de 3 partes: 

• Texto (Conocido como card en inglés)
• Una noción de lo que hay que hacer sin necesidad de entrar hasta en el más mínimo detalle, escribimos a grandes rasgos qué queremos sin decir cómo hacerlo.
• Ron Jeffries (uno de los pioneros de las user stories) dijo: el texto de la user story no es más que la promesa de una futura discusión.
• Discusión
• Product Owner explicará a detalle la historia de usuario y revisarán el texto.
• El equipo de desarrollo debe de indagar en los detalles de la nueva funcionalidad requerida.
• El Product Owner debe de asegurarse que todo el equipo de desarrollo tiene un entendimiento común de cómo el usuario final va a interactuar con la nueva característica del producto que describe la historia de usuario. 
• Confirmación
• Escribiremos en forma una lista los criterios de aceptación, es decir el conjunto mínimo de detalles que el Product Owner necesita que estén incluidos en el desarrollo para aceptarle al equipo la entrega de la funcionalidad requerida.

¿Qué mejoramos? Fomentamos la discusión y nos aseguramos de un buen entendimiento común de lo esperado tanto del lado del equipo de desarrollo como del Product Owner (mejor manejo de expectativas).

2. Si piensas que puedes hacer que alguien escriba un requerimiento y luego los desarrolladores deben entender lo que esta allí descrito a la perfección, comenzamos ya a violar el manifesto ágil.

Una desventaja del idioma inglés... bueno, también del español... y del francés... de hecho de todos los lenguajes excepto de la matemática, es que son lenguajes ambiguos. Es decir, cada quien puede darle diferentes interpretaciones a un mismo texto.

La única forma de asegurarte de que todos estamos en sintonía cuando hablamos de un requierimiento es utilizando la segunda y tercera parte de la historia de usuario (la discusión y la confirmación).

¿Puedo combinar los roles en Scrum?

Algunas de las preguntas frecuentes que me han hecho en varias empresas son:

• ¿Puede ser el Scrum Master también el Product Owner?
• ¿Puede ser el Scrum Master también parte del equipo de desarrollo?
• ¿Puede el Product Owner ser del equipo de desarrollo?

Comencemos por la pregunta más fácil de contestar. 

El Product Owner y Scrum Master son dos roles separados intencionalmente por Jeff Sutherland y Ken Schweber desde el principio, estos roles son complementarios pero totalmente diferentes. He visto casos en los que en equipos (sobre todo equipos nuevos) el Product Owner quiere que se hagan cosas y el Scrum Master evita que sucedan para proteger al equipo o proteger el marco de Scrum, por ejemplo:

• Cambiar el trabajo que debe de hacerse durante el Sprint
• Presionar al equipo y aumentar la velocidad de producción en corto plazo (aunque esto sea desastroso para la velocidad en mediano y largo plazo)

Es decir, el Scrum Master y Product Owner tendrán en algunos casos conflicto de intereses.

Antes de entrar a este tema de lleno, quisiera mostrarle la siguiente imagen:

¿Se puede imaginar cuál es la conversación entre Zizou y Ronaldo?

Que tal algo como: "Mirá pues Ronaldo, la pelota no la vayas a tocar con la mano por que te marcan falta. Lo que tenés que hacer es llevar la pelota con el pie e intentar meterla en el arco del otro equipo para que te den un punto, a eso se le llama Gol." :)

¿Será algo por el estilo? Si su respuesta es "definitivamente no, Ronaldo ya sabe jugar Futbol", entonces le tengo otra pregunta: ¿Para qué necesita entonces el Real Madrid un coach? Todos los jugadores saben jugar ya, ¿no?

¿Cuál es el objetivo de Zizou en este equipo?

Sip! Es definir la estrategia del equipo, entender cómo el Real puede ser cada día mejor y cómo enfrentarse y vencer en diferentes situaciones. 

Ahora, veamos otro tema: ¿Cuántas veces vieron que cuando el Real se acercaba a la portería del contrincante, Zizou con su traje y corbata se metiera al campo para ir a meter el gol? ¿Nunca?, ¿Por qué no? (aparte de que las reglas del juego lo prohíban :))

Si el entrenador se metiera al campo a jugar entonces durante este momento, su mirada se concentraría en la pelota y posiblemente en dos o tres jugadores. En este preciso momento el perdería la visión global de que es lo que esta pasando y le sería imposible definir estrategias efectivas para todo el equipo. 

¿Dónde debe estar Zizou? Afuera de la cancha, con una visión desde fuera, lograra ver el todo de lo que esta pasando.

Recordemos que el Scrum Master es el coach del equipo de desarrollo, si bien el equipo debe de definir sus propias estrategias, el Scrum Master necesita tener una visión desde fuera y enfocarse en ayudar a que el equipo de Scrum sea mejor. 

En cuanto un Scrum Master se vuelve parte del equipo, su mirada se volverá al problema que él como developer quiere resolver (solo verá el balón), y esto puede hacerle difícil crear una estrategia para ayudar al equipo (incluyendo la relación del Product Owner con los Stake Holders).

De la misma forma, el Product Owner es el responsable de definir e implementar las estrategias de cómo mejorar el producto y cómo hacer que se le de cada vez más valor al cliente final.

Así que mi recomendación es no meter a la cancha junto con el equipo de developers a jugar ni al Product Owner ni al Scrum Master.