¿Cómo usar bien las User Stories?
Feb 15, 2022
Por Gerardo Morales, Scrum Inc.™ Trainer
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.
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.
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).
¡10 años de experiencia transformando profesionales!
