¿Qué integra el Backlog de Producto?
El Backlog de Producto en un entorno Ágil representa el alcance del proyecto. Una de sus principales características es que se mantiene vivo a lo largo de todo el proyecto. Es decir que se puede modificar conforme avanzamos en desarrollo de la solución.
Principalmente el Backlog de Producto está constituido por historias de usuario. Otros elementos que también deberían incluirse son los errores, y los spikes. Sn embargo, no todos las historias de suario son iguales.
Recuerda que un Backlog de Producto conviven diferentes tipos de historia de usuario:
- Historias de usuario “estándar”: básicamente se refiere a aquellas que por su tamaño pueden completarse en un sprint. Cómo norma general no deberían requerir de más de tres o cuatro días de trabajo.
- Temáticas: hacen referencia a un conjunto de historias de usuario relacionadas, por ejemplo en base a una misma área funcional.
- Historias de usuario Épicas: se utiliza para referirse a historias de usuario, o a un conjunto de historias de usuario, que por su tamaño requerirán de varios meses de trabajo. Una historia de usuario Épica puede desarrollarse en varias releases o entregas.
Lo cierto es que al respecto no todos los autores o profesionales coinciden en llamarles de la misma manera. Lo importante es que sepas que en función del grado de detalle (granularidad) , pueden existir diferentes tipos de historia de usuario.
Scrum es un fantástico marco de gestión. No obstante scrum parte o da por supuesto un Backlog de Producto que no muchas veces queda claro de dónde sale, o cómo se genera.
¿De dónde sale el Backlog de Producto?
Para elaborar nuestro Backlog de Producto podemos recurrir al Mapa o Mapeo de Historias de Usuario (Users Story Mapping). Se trata de una técnica ideada originalmente por Jeff Patton, y qué básicamente consiste en visualizar el desarrollo de la solución (producto/servicio) planteado como si se tratara de una historia.
El Mapeo de Historias de usuario se basa en una perspectiva centrada en el usuario para generar un conjunto de historias de usuarios. La idea básica es descomponer las actividades de usuario de alto nivel, en un flujo de trabajo que se puede descomponer en un subconjunto de tareas más detalladas.
Si bien un Backlog de Producto sigue una lógica vertical; aparece ordenado de arriba abajo en función del valor de las historias de usuario, en un mapa de historias sigue una lógica es horizontal. Es decir, las historias de usuario aparecen ordenadas de izquierda a derecha.
¿Cómo generar un Mapa de Historias de Usuario?
Lo cierto es que no hay una única manera de crear un Mapa de Historias de Usuario. No obstante, las diferentes técnicas se basan en dos indicaciones básicas:
1. En la parte alta del mapa se sitúan lo que se conoce como historias épicas. Son aquellas Historias de Usuario que describen las características o las funcionalidades al más alto nivel.
2. En las capas inferiores, debajo de cada historia de usuario épica, se sitúan las Historias de Usuario en las que estas se subdividen.
Observa en el diagrama:
A. En el nivel más alto aparecen las historias de usuario Épicas. Estas se ordenarán de izquierda a derecha siguiendo el flujo de trabajo o la secuencia de uso del usuario.
B. Para desarrollar el siguiente nivel hay que tomar en consideración la secuencia o el flujo de actividades que seguiría el usuario para completar la Épicas. De nuevo las temáticas aparecen ordenadas de izquierda a derecha en función del tiempo.
C. Finalmente, cada una de las Temáticas se descomponen en historias de usuario estándar; aquellas que pueden llevarse a cabo durante un sprint. Estás aparecerán ordenadas verticalmente en función de su importancia. Es importante que tenga en cuenta que notas las historias de una Temática tienen porque entregarse en una misma realease.
Ventajas del Mapa de Historias de Usuario
El Mapeo de Historias de usuario es una técnica Ágil que combina el concepto de diseño centrado en el usuario y la descomposición en historias de usuario. Respecto a un estilo de gestión Ágil, es perfectamente compatible ya que utiliza herramientas sencillas y visuales, y se genera con la ayuda de todos (colaborativo).
- Herramientas sencillas y visuales: para su elaboración se emplean elementos visuales como tableros físicos y post its. De esta manera resulta más sencillo plasmar el entendimiento común que se va generando sobre aquello qué se quiere construir. Posteriormente podría llevarse a un soporte digital si fuera necesario.
- Se genera de manera colaborativa. Su elaboración se basa en el modo de comunicación preferido en los enfoques Ágiles, y que además tiene mayor probabilidad de éxito: la comunicación cara a cara. Esta forma de comunicación contribuye a genera una retroalimentación a través de la conversación continua entre todos los participantes, como base para la generación del entendimiento compartido.
Si bien se trata de una técnica 100% Ágil perfecta utilizable para construir soluciones de software, no es exclusiva de este ámbito. El Mapeo de Historias de Usuario podría empelarse en cualquier otro ámbito que requiera conseguir un entendimiento compartido sobre la solución a desarrollar.
Debes recordar una cosa: lo más importante no es el Mapa de Historias de Usuario generado como resultado del proceso. Es el propio proceso, entendió como el camino que recorre el equipo, o la búsqueda de un entendimiento compartido que lleva el quipo de manera conjunta. Así como el empoderamiento que la técnica torga al grupo que participa.
¿Qué son las historias de usuario ágiles?
Una historia de usuario es la unidad de trabajo más pequeña en un marco ágil. Es un objetivo final, no una función, expresado desde la perspectiva del usuario del software.
Una historia de usuario es una explicación general e informal de una función de software escrita desde la perspectiva del usuario final o cliente.
El propósito de una historia de usuario es articular cómo un elemento de trabajo entregará un valor particular al cliente. Ten en cuenta que los “clientes” no tienen por qué ser usuarios finales externos en el sentido tradicional, también pueden ser clientes internos o colegas dentro de tu organización que dependen de tu equipo.
Las historias de usuario son unas pocas frases en lenguaje sencillo que describen el resultado deseado. No entran en detalles, ya que los requisitos se añaden más tarde, una vez acordados por el equipo.
Las historias encajan perfectamente en marcos ágiles como scrum y kanban. En el scrum, las historias de los usuarios se añaden a los sprints y se “queman” a lo largo del sprint. Los equipos de kanban introducen las historias de usuario en su backlog y las ejecutan siguiendo su flujo de trabajo. Es este trabajo sobre las historias de usuario lo que ayuda a los equipos de scrum a mejorar en la estimación y planificación del sprint, lo que conduce a un pronóstico más preciso y a una mayor agilidad. Gracias a las historias, los equipos de kanban aprenden a gestionar el trabajo en curso (WIP) y pueden perfeccionar aún más sus flujos de trabajo.
Las historias de usuario son también los componentes básicos de los marcos ágiles más grandes, como los epics y las iniciativas. Los epics son grandes elementos de trabajo divididos en un conjunto de historias, y varios epics constituyen una iniciativa. Estas estructuras más grandes garantizan que el trabajo diario del equipo de desarrollo contribuya a los objetivos de la organización incorporados en los epics y las iniciativas.
¿Por qué crear historias de usuario?
Para los equipos de desarrollo nuevos en la metodología ágil, las historias de usuario a veces parecen un paso más. ¿Por qué no dividir el gran proyecto (epic) en una serie de pasos y seguir adelante? Pero las historias dan al equipo un contexto importante y asocian las tareas con el valor que estas aportan.
Las historias de usuario tienen varios beneficios clave:
- Las historias centran la atención en el usuario. Una lista de tareas pendientes mantiene al equipo centrado en tareas que deben completarse, pero un conjunto de historias lo mantiene centrado en solucionar problemas para usuarios reales.
- Las historias permiten la colaboración. Con el objetivo definido, el equipo puede colaborar para decidir cómo ofrecer un mejor servicio al usuario y cumplir con dicho objetivo.
- Las historias impulsan soluciones creativas. Las historias fomentan que el equipo piense de forma crítica y creativa sobre cómo lograr mejor un objetivo.
- Las historias motivan. Con cada historia el equipo de desarrollo disfruta de un pequeño reto y una pequeña victoria, lo que aumenta la motivación.
Trabajar con historias de usuario
Una vez que se ha escrito una historia, es hora de integrarla en tu flujo de trabajo. Por lo general, una historia la escribe el propietario del producto, el gestor del producto o el gestor del programa, y la envía para su revisión.
Durante una reunión de planificación de sprint o iteración, el equipo decide qué historias afrontará en ese sprint. Los equipos discuten los requisitos y la funcionalidad que requiere cada historia de usuario. Esta es una oportunidad para ponerse técnico y creativo en la implementación de la historia por parte del equipo. Una vez acordados, estos requisitos se añaden a la historia.
Otro paso común en esta reunión es calificar las historias en función de su complejidad o tiempo hasta su finalización. Los equipos usan las tallas de las camisetas, la secuencia de Fibonacci o el Planning Poker para hacer las estimaciones adecuadas. Una historia debe ser de un tamaño que pueda completarse en un sprint; por lo tanto, cuando el equipo establezca las especificaciones de cada historia, se deben asegurar de dividir las historias que superen ese horizonte de finalización.
Cómo escribir historias de usuario
Piensa en lo siguiente cuando escribas historias de usuario:
- Definición de “Listo”: la historia suele estar “lista” cuando el usuario puede completar la tarea descrita, pero debes asegurarte de definir lo que representa completarla.
- Describe tareas o subtareas: decide qué pasos específicos deben completarse y quién es responsable de cada uno de ellos.
- Perfiles de usuario: ¿para quién? Si hay varios usuarios finales, considera crear varias historias.
- Pasos ordenados: escribe una historia para cada paso en un proceso más grande.
- Escucha el feedback: habla con los usuarios y capta sus problemas o necesidades en lo que dicen. No es necesario tener que estar adivinando las historias cuando puedes obtenerlas de tus clientes.
- Tiempo: el tiempo es un tema delicado. Muchos equipos de desarrollo evitan hablar sobre el tiempo, y en su lugar confían en sus marcos de trabajo de estimación. Dado que las historias deberían completarse en un sprint, aquellas que puedan necesitar semanas o meses deberían dividirse en historias más pequeñas o considerarse un epic independiente.
Una vez que las historias de usuario estén definidas de forma clara, debes asegurarte de que todo el equipo pueda verlas.
Requisitos vs Casos de uso vs Historias de Usuario
Los tres intentan representar las características que tiene que tener un sistema, la diferencia está en el enfoque dado.
Los Requisitos del sistema están escritos desde la perspectiva del sistema y no en la interacción del usuario, representan las características en estado puro.
Los Casos de Uso están escritos como una serie de interacciones entre el usuario y el sistema. Hacen hincapié en el contexto orientado al usuario. Las características que utiliza cada usuario identificado en el sistema. Son la forma de capturar los requisitos del sistema desde el punto de vista del usuario.
Las Historias de Usuario sirven para describir lo que el usuario desea ser capaz de hacer. Además, las historias de los usuarios se centran en el valor que viene de usar el sistema en lugar de una especificación detallada de lo que el sistema debe hacer. Están concebidos como un medio para fomentar la colaboración.
Los requisitos y los casos de uso se pueden utilizar en desarrollos ágiles de software, pero ambos se apoyan fuertemente en las especificaciones documentadas del sistema, en lugar de colaboración tradicional de los métodos ágiles. Si no existe un enfoque integrado en la colaboración, es posible que se ahonde en una especificación detallada en el caso de uso que se convierte en la fuente de registro en lugar de un mecanismo de conversaciones.
En resumen las diferencias son: los requisitos tradicionales se centran en las operaciones del sistema, con una tendencia a la especificación detallada del sistema, los casos de uso se centran en las interacciones entre el usuario y el sistema con una tendencia similar de las especificaciones detalladas, y las historias de los usuarios se centran en el valor del cliente con una fuerte intención de fomentar la comunicación.
¿Son las historias de usuario mejor que otros tipos de especificación de requerimientos? Depende de la situación, pero en un ambiente de colaboración, la experiencia indica que claramente sí. Las historias de usuarios no hará que el proyecto sea ágil, o la falta de ellas hará que sea difícil adquirir agilidad.
Podríamos decir que una historia de usuario representa el “qué” quiere el cliente o usuario y un caso de uso es el “cómo” lo quiere.
Historias de usuario versus casos de uso
Si estamos en un contexto no-ágil, ¿ayudan las historias de usuario? Depende del equipo. Si un equipo está inmerso en un proceso de desarrollo en cascada o con procesos iterativos pesados y se utiliza el enfoque de «planificación pesada y requerimientos up-front”, es muy probable que influya en las historias de los usuarios, convirtiéndolas en requisitos tradicionales. Las historias de usuarios son claramente un poco vagas en cuanto a descripción y se prestan a refinamientos sucesivos, la planificación y el diseño por adelantado no es su punto fuerte. La especificación detallada a menudo es la práctica en entornos de procesos controlados y pesados, antes de que comience la codificación de manera que los requisitos se puedan utilizar para planificar el presupuesto y el proyecto entero.
Las historias de usuarios (cuando se utiliza según lo previsto por algunos expertos, p.ej: Cockburn) son demasiado vagas en formato para prestarse a una documentación completa. Pero si, por el contrario, el equipo está abierto a la colaboración con los usuarios, el cliente, los analistas de negocios y los patrocinadores del proyecto y se puede o se desea tolerar el cambio, las historias de los usuarios pueden ser el método de requisitos más apropiado que además ayuda a la colaboración.
Habrá proyectos o contextos en los que unas veces será mejor utilizar historias de usuario, otras será mejor utilizar casos de uso como técnica de captura de requisitos.
Resumen y ejemplo:
Backlog del Producto – Product Backlog (PB)
Es el conjunto de todas las necesidades de los consumidores y del negocio que el producto resolverá. Se mantiene valorado y priorizado por el Product Owner. No es obligatorio usar el formato de Historia de Usuario en el Product Backlog.
Épico (Epic)
Es una historia de usuario que aún no se ha detallado, es demasiado grande o todavía presenta mucha incertidumbre y, por lo tanto, no se puede transformar en un incremento del producto. Lo épico debe rebanarse en historias de usuarios más pequeñas. Un ejemplo de épico podría ser: Yo, como una persona con discapacidad visual, quiero que mi entorno de trabajo sea más accesible para que no depender tanto de otras personas.
Historia de usuario (User Story – US)
En resumen, la Historia de Usuario es un formato sucinto para escribir los requisitos necesarios para construir un producto. Debe ser comprensible para los clientes y consumidores. Ejemplos de historias de usuarios para el ejemplo épico presentado anteriormente:
Historia 1: Yo, como una persona con discapacidad visual, deseo que los lugares a los que tengo que ir sean accesibles para no tener que pasar por la vergüenza de preguntarle a la gente sobre los lugares a los quiero ir.
Historia 2: Yo, como una persona con discapacidad visual, quiero llegar fácilmente a la salida de emergencia, porque no quiero morir en un incendio.
Ten en cuenta que un buen Product Owner puede rebanar la historia aún más si intenta comprender la parte más importante del problema más importante del cliente más importante. Por ejemplo:
Historia 1.1: Yo, como una persona con discapacidad visual, quiero llegar fácilmente al cuarto de baño para no tener que pasar por la vergüenza de preguntarle a la gente sobre los lugares a los que quiero ir.
Historia 1.2: Yo, como una persona con discapacidad visual, quiero llegar fácilmente a los ascensores para no tener que pasar por la vergüenza de preguntarle a la gente sobre los lugares a los que quiero ir.
Historia 1.3: Yo, como una persona con discapacidad visual, quiero llegar fácilmente a las salas de reunión para no tener que pasar por la vergüenza de preguntarle a la gente sobre los lugares a los que quiero ir.
Puedes rebanar aún más. Digamos que la mayoría de las personas con discapacidad visual están en el quinto piso.
Historia 1.1.1: Yo, como una persona con discapacidad visual que trabaja en el quinto piso, quiero llegar fácilmente al cuarto de baño para no tener que pasar por la vergüenza de preguntarle a la gente sobre los lugares a los que quiero ir.
Tareas (Tasks)
Las tareas son elementos técnicos necesarios para que una Historia de Usuario se transforme en un incremento del producto. Ejemplo de tareas de la Historia 1.1.1:
- Adquirir un módulo de sensor de presencia;
- Adquirir altavoces;
- Diseñar las nuevas placas;
- Crear modelos de ingeniería;
- Montar las placas;
- Instalar las placas en los cuartos de baño del quinto piso, etc.
Jerarquía
La jerarquía que tenemos con las historias de usuario es esta:
- Backlog del Producto
- Épico
- Historia de Usuario
- Tareas
El Backlog del Producto es la colección de historias de usuarios que deberemos hacer. Un backlog del usuario tiene de 1 a N Historias. El backlog no tiene que contener épicos. Por lo general, los equipos que trabajan con un objetivo totalmente flexible y una validación constante de hipótesis mantienen un backlog extremadamente reducido.
Si hay épicos en el backlog, puede rebanarse en N historias de usuarios. Sin embargo, lo épico puede ser descartado si se concluye que no será capaz de traer los beneficios inicialmente imaginados.
Una historia de usuario se puede dividir en N tareas técnicas. No obstante, cuando el Product Owner hace una buena rebanada de las historias de usuarios, el Equipo tiene un flujo de valor muy bien mapeado en la Pizarra de Tareas, ya domina las herramientas y técnicas necesarias para la construcción y conoce el contexto en el que trabaja, menor es la necesidad de dividir las historias en tareas.
Artículo Fuente 1 | Artículo Fuente 2 | Artículo Fuente 3 | Artículo Fuente 4