Scrum está pensado como un marco simple pero suficiente para la entrega de productos complejos. Scrum no es una solución única, una bala de plata o una metodología completa. En cambio, Scrum proporciona los límites mínimos dentro de los cuales los equipos pueden autoorganizarse para resolver un problema complejo utilizando un enfoque empírico. Esta simplicidad es su mayor fortaleza, pero también es la fuente de muchas malas interpretaciones y mitos que rodean a Scrum. En esta serie de publicaciones, nosotros, sus ” Cazadores de mitos “, Christiaan Verwijs & Barry Overeem, abordaremos los mitos y malentendidos más comunes. 

PD: Las grandes imágenes son de Thea Schukken.

El mito de hoy se comprende mejor con un ejemplo de un equipo con el que trabajamos recientemente. Su Product Backlog incluía este item: “Como diseñador, quiero crear una guía de estilo para que todos los desarrolladores puedan hacer el diseño básico por sí mismos”. Este formato – ‘Como un [rol] quiero [acción] para que [motivo]’ – se conoce comúnmente como una ‘Historia de usuario’. La lectura adicional del Product Backlog arrojó ejemplos similares: “Como visitante, quiero ver el sitio en un dispositivo móvil para poder verlo de camino a casa” y “Como desarrollador, quiero tener una API para puede consultar pedidos desde el backend de la aplicación ‘. ¿Por qué el equipo no escribió simplemente tres elementos más breves, respectivamente: “Crear guía de estilo”, “Soporte de dispositivos móviles” y “Permitir consultas de pedidos desde el backend (API)”? En cambio, hicieron un gran esfuerzo para formular todo en su Product Backlog como Historias de Usuarios.

Cuando los desafiamos sobre la formulación de los ítems, el equipo respondió que así era como se les explicó Scrum. Les habían dicho que los pedidos pendientes de productos consistían en historias de usuarios. Incluso se sintieron forzado a veces, e hizo que el equipo se lamentara de la ‘carga administrativa’ de tener que reformular tareas obvias en Historias de usuarios solo por el simple hecho de hacerlo.

Hoy vamos a acabar con el mito de que el Product Backlog tiene que consistir en User Stories. Lo haremos volviendo al propósito del Product Backlog y las Historias de Usuario. En el proceso, también rompemos un mito relacionado; que las Historias de Usuario son una parte inherente y necesaria de Scrum.

Rompiendo el mito

De acuerdo con la Guía Scrum, el Product Backlog enumera todas las características, funciones, requisitos, mejoras y correcciones que constituyen los cambios que se realizarán en el producto en futuras versiones . Dicho de manera más sucinta, enumera todo el trabajo que se considera necesario para el producto.

El cómo los equipos Scrum deciden capturar este trabajo es algo que depende totalmente de ellos. Pueden escribir historias de usuarios, pueden usar un montón de palabras clave, escribir casos de uso o incluso hacer dibujos. Como se enfatizó en publicaciones anteriores, Scrum solo describe lo que se debe hacer, pero no hace cumplir cómo debe hacerse. Las realidades del desarrollo de productos son demasiado complejas para una solución única, soluciones mágicas y técnicas genéricas.

Un poco sobre las historias de usuarios

A lo largo de los años, las historias de usuario se han convertido en la técnica a la que recurren la mayoría de los equipos Scrum. Su uso ha sido fuertemente defendido por libros, blogs (incluido el nuestro) y trainers. En su forma actual, se consideran “buenas prácticas”. Originalmente acuñado en 1998 por Alistair Cockburn, el uso de User Stories se volvió dominante en Extreme Programming (XP). Mientras tanto, con la creciente popularidad de Scrum, no sorprende que las historias de usuario se hayan trasladado a Scrum junto con otros conceptos de XP (como los puntos de la historia y el ‘stand up’).

La popularidad de las historias de usuario se comprende fácilmente. Son muy diferentes de las amplias especificaciones de enfoques más basados ​​en planes. En lugar de intentar capturar cada detalle de una función en largos requisitos y listas de viñetas, las Historias de usuarios simplemente describen la esencia funcional desde la perspectiva de un usuario: “Como comprador, quiero poner un producto de interés en mi cesta de la compra para que Puedo comprar más productos a la vez”. La fuerza de User Stories radica en su simplicidad. Por diseño, son incapaces de transmitir todos los detalles de lo que se necesita. A medida que un Scrum Team avanza a través del Product Backlog, entregando elementos como parte de los Incrementos de trabajo, eventualmente necesitarán tener una conversación sobre lo que se necesita para implementar un próximo elemento que su User Story describe tan sucintamente. Pero tendrán esa conversación cuando estén a punto de implementarla, no al principio. Los items de un Product Backlog son recordatorios para futuras conversaciones, basados ​​en el conocimiento y las percepciones que han surgido en ese momento.

Los elementos de un Product Backlog son recordatorios para futuras conversaciones, basados ​​en el conocimiento y las percepciones que han surgido en ese momento. Clic para tuitear

Esto encaja bien con el enfoque empírico de Scrum para el desarrollo de productos y el cono inherente de incertidumbre.

Técnicas para capturar el trabajo en el Product Backlog

Así que no hay absolutamente nada de malo en las Historias de usuarios. Son una gran técnica para capturar los requisitos funcionales de una manera “suficientemente buena por ahora”, lo que deja espacio para futuras conversaciones. Pero Scrum no los prescribe ni los requiere. Otras técnicas están bien, siempre que ayuden a promover tres cosas:

• Hacen que el Product Backlog sea comprensible para el Scrum Team y sus stakeholders. Una stakeholder debe poder ver el Product Backlog y tener una buena idea de lo que se avecina y en qué orden;
• El nivel de detalle que exigen debe ajustarse a la incertidumbre del desarrollo de productos. Los elementos que se encuentran más lejos en el futuro deberían requerir menos detalles que los elementos que están a punto de incorporarse a un Sprint;
• Deben fomentar una comunicación y una conversación continuas entre el equipo Scrum y los stakeholders (que incluye a los usuarios);

Algunos trabajos se pueden capturar con unas pocas palabras clave o una frase corta. Si tanto el equipo Scrum como los stakeholders entienden lo que significa un “sitio receptivo”, ¿por qué hacer el esfuerzo de forzarlo en la historia de usuario mencionada en la introducción? ¿Y el trabajo técnico? ¿Te gusta crear una API o configurar una infraestructura? Si se usa con moderación, una descripción técnica del trabajo está bien si esa es la forma más simple y comprensible de capturarlo. Hay poco valor en una historia de usuario vaga “Como empresa, queremos tres instancias de un sitio, de modo que una falla de una instancia no derribe todo” si también se entiende si simplemente escribimos “Configurar equilibrio de carga para sitio ”en un post-it. Que el Product Backlog en su conjunto deba ser comprensible para el Scrum Team y sus stakeholders no significa que todos los Items tengan que serlo. El Product Backlog sigue siendo una conversación en curso.

Un Product Backlog saludable contiene una combinación de elementos. Algunos items serán tareas técnicas (por ejemplo, ‘Instalar un nuevo servidor web’ o ‘Crear un programa de respaldo para la base de datos de producción’), mientras que otros serán funcionales (por ejemplo, ‘Los suscriptores pueden almacenar elementos en su lista de lectura para que puedan leerlos en un momento posterior ‘). Las historias de usuario son una excelente manera de capturar los requisitos funcionales si fluyen naturalmente de la conversación en la que se identifican, y su formulación no se siente forzada ni como “una tarea administrativa”. Si se encuentra forzando algo en una plantilla de historia de usuario debe considerar otras técnicas.

Si quieres profesionalizarte en agilidad a través de Scrum te invitamos a las próximas fechas abiertas al público

Consejos

• Si se encuentra forzando requisitos en una plantilla de ‘Historia de usuario’, considere para qué sirve la historia . ¿Es esta la mejor manera de hacer que el Product Backlog sea comprensible tanto para el Scrum Team como para sus stakeholders?
• La plantilla de ‘Historias de usuarios’ es solo una guía . No hay nada de malo en taquigrafía como ‘Los visitantes pueden registrarse para recibir el boletín’;
• Explore otras formas de capturar los requisitos en un Product Backlog. En lugar de utilizar historias de usuarios, preferimos hacer esta pregunta para cada elemento: “¿Qué se vuelve posible o más fácil después de implementar este item?”. Anotamos la respuesta en las llamadas “Tarjetas de características”. El reverso de la tarjeta contiene dos preguntas más detalladas que generalmente se responden durante el Refinement o el Sprint Planning: “¿Qué criterios se aplican a esta función?” (p. ej., criterios de aceptación) y “¿Cómo sabemos que esta función funciona según lo previsto?” (por ejemplo, casos de prueba). Nuevamente, esto es solo una técnica;
• La naturaleza forzada de las ‘Historias de usuarios’ es especialmente evidente en entornos que no son de TI. Diseñada para capturar los requisitos funcionales en las aplicaciones, la plantilla no es tan útil fuera de TI. A menudo conduce a elementos de orientación interna vagos o con frases extrañas, como “Como especialista en marketing, quiero enviar un correo al grupo X para que conozcan los nuevos productos” o “Como miembro del equipo, quiero escribir un plan para vea cómo se puede hacer Y”. Preferimos pedir a los equipos que no son de TI que se centren en poner los resultados que quieren lograr en el Product Backlog , no en lo que van a hacer, por ejemplo, “Notificar al grupo X de nuevos productos” y “Estrategia para lograr Y”;

Conclusiones

En esta publicación, hemos desmantelado el mito de que un Product Backlog tiene que consistir completamente en User Stories o historias de usuario en español. Al describir el propósito y las características del Product Backlog, también rompimos el mito relacionado; que las historias de usuario son una parte inherente y necesaria de Scrum.

¿Qué piensas de este mito? ¿Estás de acuerdo con esta publicación o no? Háznoslo saber en los comentarios.