Traducción del artículo «Product Backlog Building Canvas» de la página de Martin Fowler: https://martinfowler.com/articles/product-backlog-building-canvas.html
Una herramienta colaborativa para escribir historias de usuario.
Muchos equipos de software describen las funcionalidades deseadas del producto como un backlog de producto: una lista de historias de usuario. Estas historias captan quién necesita la funcionalidad, qué se espera de ella y por qué se necesita. Con frecuencia, los equipos esperan que el propietario de producto (Product Owner) sea la única persona que alimenta el backlog, pero cualquier persona podría (y debería) escribir historias de usuario. El Canvas de Product Backlog Building (PBB) proporciona un proceso simple para desarrollar historias de usuario, comenzando con la descripción de las personas para el producto y las actividades que realizan. Estas actividades dan lugar a funcionalidades: las interacciones del usuario con el producto. Las funcionalidades son divididas en elementos más pequeños en el backlog, los cuales pueden ser formulados como historias de usuario desde la perspectiva de las personas y las actividades que realizan.
Kent Beck introdujo el término Historia de Usuario como parte de Programación Extrema para fomentar un estilo de recopilación de requisitos más ágil y basado en conversaciones. Unos años más tarde, Mike Cohn publicó su libro “User stories Applied: For Agile Software Development (2003)”, que es considerado uno de los grandes referentes en el tema.
Originalmente, cualquier persona de un equipo ágil solía escribir Historias de Usuario para comunicar el trabajo que debía ser realizado. Sin embargo, con el paso del tiempo y en mayor medida por la expansión del marco de trabajo Scrum, el Product Owner se convirtió en el principal responsable de escribir estas historias y organizarlas en un backlog de producto. Sin embargo, cualquier persona puede (y debe) escribir una historia de usuario. Fábio Aguiar y Paulo Caroli escribieron el libro sobre la técnica de Product Backlog Building para ayudar a todo el mundo en el equipo a escribir buenas historias de usuario.
¿Qué hace una buena historia de usuario?
Antes de presentar el Canvas de PBB, es útil entender qué hace que una historia de usuario sea buena. Así que describiré varias heurísticas que se usan frecuentemente.
3W de la historia del usuario
Una historia de usuario es un formato textual para describir de forma concisa un requerimiento que busca responder a tres preguntas específicas a partir de las siglas conocidas como 3W: Who? (¿Quién?), What? (¿Qué?) y Why? (¿y por qué?)
- ¿Para quién es?
- ¿Cuál es la acción o actividad que la persona realiza con ella?
- ¿Por qué la persona lo usará (beneficio o razón)?
INVEST
En el libro , Extreme Programming Explored, William C. Wake creó el acrónimo INVEST, donde cada letra del representa una de las seis características importantes de una historia de usuario:
- Independiente (Independent): Una historia no depende de otra.
- Negociable (Negotiable): Una historia captura la esencia de lo que se desea. No es un contrato fijo. Las conversaciones y la negociación son bienvenidas.
- Valiosa (Valuable): Una historia claramente describe el valor para el cliente.
- Estimable (Estimable): La historia proporciona suficiente información para que el equipo de desarrollo la estime.
- Pequeña (Small): Una buena historia debe ser relativamente pequeña en tamaño para completarla en el periodo de tiempo más corto posible y que encaje en una iteración (Sprint), considerando el contexto del equipo.
- Comprobable (Testable): Una historia debe ser suficientemente clara como para que se puedan definir unas pruebas para ella.
Varios años después de la creación del acrónimo, Mike Cohn, renombró la letra “S” de “pequeño” (small) a dimensionada adecuadamente (sized), ya que algunas personas creaban historias que eran un tanto grandes, pero adecuadas para su propio contexto.
Modelo 3Cs
Tarjeta (Card): La descripción de la historia de usuario debe caber en un tarjeta, conteniendo suficiente información para identificar la historia de usuario. El formato más común es:
Como <rol/perfil>
Quiero <acción/actividad>
Para <beneficio/razón>
Un ejemplo:
“Como participante, quiero registrarme en el evento para que pueda atender”
Conversación: La descripción de una historia de usuario tiene que caber dentro de una tarjeta o ficha. La principal razón es que no hay mucho espacio para escribir y fuerza a que la descripción sea breve. Por lo tanto, se necesita mucha conversación para aclarar dudas y detallar el trabajo necesario para implementarla. Trabajar con historias de usuario significa aceptar que las conversaciones sobre el trabajo serán contínuas y no únicamente ubicadas al principio cuando se establece inicialmente el requisito. Los mejores documentos son aquellos que nos ayudan a recordar nuestras conversaciones, no a reemplazarlas.
Confirmación: Es aquí donde determinamos si el objetivo de la historia de usuario es alcanzado. Para ello, los criterios de aceptación confirman que la historia de usuario ha sido implementada correctamente y entregada con éxito. Los criterios de aceptación deben definirse para cada historia de usuario antes que el equipo comience a implementarla. De esa forma, no hay sorpresas cuando se verifique la entrega.
Escribiendo historias con PBB
Como hemos visto anteriormente, escribir una historia de usuario básicamente responde a tres preguntas principales: ¿Quién? ¿Qué? ¿Por qué?
El “¿Quién?” se refiere a la persona. El “¿Qué?» se refiere al elemento de trabajo para construir la acción o actividad que la persona necesita; y el «¿Por qué?» habla de los beneficios de usarlo.
En el libro de PBB, Fábio y yo compartimos un procedimiento paso a paso para identificar personas, características y elementos de trabajo para construir buenas historias de usuario a través del canvas de PBB. En este artículo, compartiré cómo completar el canvas y escribir una historia de usuario para un producto digital de ejemplo. Es sobre un producto denominado “La Colección de Charlas”, un producto digital creado por una comunidad ágil regional para preparar un portafolio de charlas y organizar eventos.
Imagen 1: El Canvas de PBB
A continuación, se muestra una descripción de los tres pasos para rellenar los bloques Persona, Funcionalidades y Elementos del Backlog de Producto del canvas de PBB. Utilizo algunas de las personas y funcionalidades de “La Colección echarlas” como ejemplo para ilustrarlo.
Describir la persona
Una persona representa a un usuario del producto, por lo que su descripción debe hablar no solo del rol de la persona, sino también de sus necesidades y objetivos. Esto crea una representación realista del usuario, lo que ayuda al equipo a describir las características desde el punto de vista de quién usará el producto.
Describe a las personas principales a partir de preguntas como: “¿Cuál es el perfil de esta persona? ¿Qué hace esta persona? ¿Qué espera esta persona?
Imagen 2: Ejemplo del bloque de Persona
En la actualidad, es relativamente común encontrar talleres de descubrimiento, inceptions, y otras actividades que generan artefactos y conocimiento sobre las personas, como, por ejemplo, el mapa de empatía . En el Canvas de PBB, el foco está en el perfil de las personas y sus actividades, que son puntos necesarios para el siguiente paso.
Entender las funcionalidades
Con un buen entendimiento de la persona y de sus actividades, es hora de analizar cada una de ellas, volverlas a leer y buscar las acciones o interacciones de las personas con el producto, para que puedas representar cada una de estas interacciones como una característica.
Imagen 3: de la persona a la funcionalidad
Describe las funcionalidades a partir de la respuesta a las siguientes preguntas: el usuario está tratando de hacer algo, por lo que el producto debe tener una funcionalidad para eso. ¿Qué es? ¿Qué problemas del usuario resuelve esta función? ¿Qué beneficios aporta a la persona?
Figura 4: Ejemplo de bloque de características
Escribe la descripción de la funcionalidad en un post-it grande, luego escribe los desafíos y beneficios en post-its más pequeños y colócalos al lado del post-it que describe la funcionalidad.
Las funcionalidades generalmente se describen en un nivel más alto que los elementos de trabajo que aparecen en un plan de desarrollo. Antes de comenzar a desarrollar una funcionalidad, se debe analizar dicha funcionalidad y describir y cuantificar sus elementos de trabajo. En el Canvas de PBB, primero se identifica, comprende y prioriza las funcionalidades y luego las detalla en los elementos de la cartera de productos.
Identifica los PBIs
Los Product Backlog Items (PBI) reflejan el trabajo de desarrollo que es necesario para mejorar el producto y satisfacer las necesidades del cliente o de los interesados. En el paso anterior, se describieron las funcionalidades junto con los retos y beneficios. Ahora es necesario desglosarlos aún más para conseguir elementos más pequeños y precisos. Estos elementos se llaman PBI.
Para identificar los PBI del backlog de producto, pide a los participantes que respondan a las siguientes preguntas: “¿Cuál es el primer elemento de trabajo (o paso) para esta funcionalidad? ¿Y el segundo? ¿Y los siguientes?”
Imagen 5: Ejemplo de bloque de los elementos del backlog de producto (PBI)
Cada PBI debe representar una acción realizada por un usuario en el producto. Por ejemplo: 1) «Comprar un libro» y 2) «Agregar un ponente a la conferencia». Estas acciones se describen en forma de texto para proporcionar contexto e identificar de manera única el elemento.
Conecta los bloques como una historia de usuario
Los Product Backlog Items forman la base de la lista de historias de usuario. Toma cada uno de los PBI y usa la persona y las funcionalidades para completar la típica plantilla de Historia de usuario. La siguiente figura muestra un ejemplo:
Imagen 6: Escribir una historia de usuario con PBB
- Rellena la sección “Como” , el quién, de la historia con el perfil de la persona, escrito en un post-it en el bloque “Persona” del Canvas de PBB. En el ejemplo es ´Orador´.
- Rellena la sección “Quiero” , la acción, con el post-it en el bloque “PBI: Elementos del Backlog de producto “ del Canvas de PBB. Representa uno de los pasos para crear la funcionalidad de publicar el trabajo. Para esta historia es “realizar la publicación del trabajo”.
- Rellena la sección “para”, el beneficio, con uno de los post-its junto a la funcionalidad “Publicar trabajo”. Representa uno de los beneficios de la funcionalidad, en este caso “hacer el contenido disponible”
La historia final quedaría:
Como Orador
Quiero realizar la publicación del trabajo
Para hacer el contenido disponible
Después de escribir los elementos principales de la historia de usuario, es hora de completarla con la información adicional sobre los criterios de aceptación, las tareas, la interfaz de usuario y los habilitadores (si hay alguno). Puedes hacerlo en el área de los Product Backlog Items del Canvas de PBB, o comenzar a documentarlo en tu herramienta preferida para registrar historias de usuarios.
Ejemplo de historia de usuario
A continuación, encontrarás algunos detalles sobre la descripción de tres funcionalidades para el producto digital “Talks Collection” con algunas historias de usuario, criterios de aceptación, tareas e interfaz:
Las siguientes son las tres funcionalidades de muestra con sus respectivas personas e historias de usuario.
PERSONA: PONENTE
FUNCIONALIDAD 1: Publicar una charla.
- HISTORIA 1.1: Como ponente, quiero acceder a un espacio de trabajo para gestionar mis charlas de forma privada
- HISTORIA 1.2: Como ponente, quiero publicar charlas para hacer que el contenido esté disponible.
- HISTORIA 1.3: Como ponente, quiero vincular la presentación externa para integrar charlas.
PERSONA: PARTICIPANTE
FUNCIONALIDAD 2: Participar en un evento.
- HISTORIA 2.1: Como participante, quiero poder encontrar los eventos disponibles para ver la programación.
- HISTORIA 2.2: Como participante, quiero inscribirme en un evento para poder asistir.
- HISTORIA 2.3: Como participante, quiero registrarme en el evento para confirmar mi asistencia.
PERSONA: ORGANIZADOR
FUNCIONALIDAD 3: Organizar el evento.
- HISTORIA 3.1: Como organizador, quiero definir la programación del evento para publicitar la programación.
- HISTORIA 3.2: Como organizador, quiero promocionar el evento en los medios para atraer a la audiencia.
- HISTORIA 3.3: Como organizador, quiero invitar a co-organizadores del evento para facilitar la organización
Rellenando la Historia de usuario
La plantilla que hemos visto es el núcleo de una historia de usuario, pero hay una serie de elementos adicionales que vale la pena escribir. Si bien el PBB Canvas no ayuda con estos detalles adicionales, aquí es útil describirlos. Puede agregarlos a los PBI en el lienzo o usar otras herramientas para el seguimiento de la historia.
Criterios de aceptación
Los criterios de aceptación pretenden describir cómo validar una historia de usuario. Al hacerlo, los criterios de aceptación proporcionan una lista de verificación que determina cuándo una historia de usuario está lista, completa y funcionando. A continuación se muestra una historia de usuario de ejemplo del libro Product Backlog Building:
“Como titular de la cuenta, quiero retirar dinero en el cajero automático para evitar la fila de gente del banco”.
A continuación se muestran unos posibles criterios de aceptación para este contexto:
- El titular de la cuenta con fondos suficientes pueden sacar dinero de su cuenta
- El titular de la cuenta con fondos insuficientes que no pueden sacar dinero de su cuenta
- El titular de la cuenta con fondos suficientes no puede sacar dinero de su cuenta si el cajero no tiene suficiente efectivo para realizar la retirada.
El formato presentado es similar a una lista de comprobación y es usado para verificar que la historia esté completa y funcionando, es decir, que ha pasado por todos los criterios de aceptación.
Dividir historias de usuario en tareas
Es muy común desglosar una historia de usuario en partes aún más pequeñas con el trabajo que se tiene que realizar, diciendo: “estas son las tareas”. Al enumerar las tareas necesarias para construir una historia, el equipo de desarrollo entra en los detalles técnicos sobre cómo se implementarán las piezas más pequeñas. A diferencia de las historias, las tareas no siguen un formato de texto definido. Son más directas, con un lenguaje muy técnico desde el equipo de desarrollo hacia ellos mismos.
Una tarea identifica algo que debe hacerse, algo necesario para una historia. Como tal, la tarea no tiene que ser necesariamente independiente y no demostrará valor de negocio. La mayoría de ellas tienden a ser tareas para programadores, descritas en términos usados por ellos. Algunos ejemplos de tareas son: cambiar los campos de entrada de la tabla, crear cuentas de prueba para los usuarios y automatizar los scripts de generación de datos.
Interfaz de usuario
No todo PBI está asociado con una interfaz. Pero para los ítems que estarán asociados con algún tipo de interfaz de usuario (UI – User Interface), necesitas aclarar esa asociación en el contexto de la historia de usuario.
Una interfaz se puede describir de varias formas: sketch (o bocetos simples en papel), wireframe, mockup o prototipo. La forma de describirlo varía entre un equipo y otro, dependiendo de la cultura del equipo y el tiempo empleado para detallarlo.
La pregunta que surge es ¿Cuánto debe definirse la interfaz para empezar a trabajar en la historia?
La respuesta a esa pregunta es básicamente el acuerdo del equipo para decidir si la historia está lista desde el punto de vista de la interfaz de usuario. Lo más importante es que el grupo esté alineado y cómodo con el trabajo a realizar.
Habilitador
A veces escribir una historia de usuario específica puede ser difícil. Por mucho que intentemos usar las técnicas de INVEST y las 3’C como guías, aún no podremos escribirlas satisfactoriamente. Si esto sucede, comprueba si se trata de uno de estos dos casos:
- La historia se basa en un estudio previo; o
- La historia se basa en algo muy técnico que requiere un esfuerzo considerable.
En ambos casos puedes crear una historia más grande y considerarla como parte de ella, o puedes desglosarla en algo separado: un habilitador. Este “algo separado” se denomina habilitador (enabler) porque no se adhiere al formato típico de historia de usuario. Es un PBI necesario, que habilita otra historia.
Habilitador de exploración
“Como desarrollador, quiero investigar cómo funcionan los mensajes asíncronos, para decidir cómo implementar el chat”. Esto no es una historia de usuario y no necesitamos describirla de esa forma. Eso es un habilitador de exploración, algo necesario antes de implementar una historia de usuario como:
“Como asistente quiero enviar mensajes en el chat del evento para interactuar con otros asistentes”.
Este ejemplo demuestra la necesidad de trabajar en un habilitador de exploración: «Investigar cómo funciona la mensajería asíncrona» antes de trabajar en la historia. Un habilitador de exploración sirve para realizar investigaciones, actividades antecedentes, aclaraciones y/o elección entre opciones para permitir un trabajo efectivo de una historia de usuario.
Spike es un sinónimo de un habilitador de exploración
Habilitador técnico
Los requisitos no funcionales, refactorizaciones, pipelines o mejoras en la infraestructura de tests: estos son algunos ejemplos de actividades que a veces requieren mucho esfuerzo como para ser consideradas parte de una historia de usuario. En estos casos, puedes describirlos como habilitadores técnicos. Debes indicar también qué historias dependen de ellos. Sin embargo, ten cuidado de no excederte y terminar con un backlog de solo habilitadores.
No hay necesidad de escribir los habilitadores técnicos en formato de historia de usuario. En lugar de “Como desarrollador, quiero migrar la suite de test automáticos para mejorar el rendimiento”, usa un formato de texto más directo, como: “Realizar la migración de los tests automáticos”
Ejemplo de una historia de usuario completa
Ahora, vamos a ver un ejemplo de historia de usuario y dos habilitadores de la funcionalidad “Publicar una charla” del producto “Talks Collection”. Proporciona un ejemplo completo de una historia de usuario con criterios de aceptación, tareas, interfaz de usuario y habilitadores.
HISTORIA DE USUARIO 1.3
Como ponente, quiero vincular la presentación externa para integrar charlas.
CRITERIO DE ACEPTACIÓN 1
ESCENARIO 1: Vincular la presentación a través de plataformas para compartir presentaciones.
- Dado que hay un enlace válido en la plataforma de SlideShare
- Cuando asocio el enlace de presentación externa
- Entonces se mostrará una vista previa de la presentación en la pantalla
CRITERIO DE ACEPTACIÓN 2
ESCENARIO 2: Asociar la presentación al publicar charlas.
- Dado que el enlace de la presentación es válido
- Cuando publique la charla
- Entonces se mostrará la presentación asociada en los detalles de la charla publicada.
TAREAS
Acceder al “endpoint” de la presentación.
Crear una UI para mostrar un fichero PDF con la presentación.
Crear la lógica en el backend para enlazar la presentación con la charla publicada.
Cambiar el parámetro de enlace público o privado.
Crear datos de prueba para verificar que el enlace es válido.
Cambiar la base de datos para incluir el enlace de la presentación.
BOCETO DE LA INTERFAZ
HABILITADOR DE EXPLORACIÓN:
Estudiar la integración de la API del “endpoint” con las plataformas en línea de compartición de presentaciones (SlideShare y Speaker Deck).
HABILITADOR TÉCNICO:
Consumir el “endpoint” oEmbed como una etiqueta de enlace en el encabezado para que pueda ser detectado automáticamente cuando se inserte la presentación.
Definición de Preparado y Listo
Definición de Preparado
La Definición de Preparado (DoR – Definition of Ready) es un acuerdo entre el equipo y el PO que indica cuándo el PBI está listo para entrar en un Sprint, es decir, cuándo tiene suficiente información para ir a la planificación, ejecución y entrega. La gente suele decir: “Este item está listo para empezar a trabajar en él”, y generalmente esto indica que el equipo:
- Tiene la información necesaria para trabajar en el elemento.
- Entiende el motivo por el que existe el item.
- Puede demostrar la finalización del item.
- Identifica cómo el item compone o está relacionado con la funcionalidad.
- Acuerdan que el item cabe en la duración de un Sprint.
En relación a cada candidato de PBI para el próximo sprint, el equipo comprueba la lista de verificación de un PBI (PBI Ready Checklist):
Lista de verificación para PBI:
El PBI está representado por una historia de usuario.
El PBI está cubierto por los criterios de aceptación y BDD.
Las pruebas de aceptación del PBI están identificadas (a ser mejoradas o creadas)
El PBI tiene los artefactos de experiencia de usuario necesarios.
Las dependencias del PBI están identificadas (si las hay).
Esta lista es un ejemplo de una lista de verificación para DoR. Todos los conceptos de esta lista de verificación se tratan en los siguientes capítulos. Generalmente, los equipos definen y mantienen su lista de verificación, mediante la cual demuestran su preferencia a la hora de preparar el trabajo.
El refinamiento del backlog de producto debe ser continuo. El PO estará continuamente trabajando en los siguientes items candidatos, preparándolos para el siguiente Sprint o interacción de trabajo. El uso de la Definición de preparado y hecho no está limitado únicamente a Scrum; también es una práctica muy útil cuando se trabaja con Kanban y otros métodos ágiles
Definición de Hecho
La “Definición de hecho” (DoD – Definition of Done) es el acuerdo que demuestra la calidad del PBI producido, en el que “hecho” confirma la satisfacción de todos con el trabajo realizado.
El DoD aclara la comprensión del trabajo completado como parte del incremento del producto. En el momento en el que el PBI cumple la Definición de hecho, quiere decir que el incremento está listo para ser entregado junto con el producto.
Si un PBI no cumple el DoD, no debe ser entregado, ni incluso ser presentado en el Sprint Review. Debe permanecer como trabajo en progreso (WiP) para el equipo.
Para cada PBI considerado como terminado, el equipo demuestra que el item:
LISTA DE VERIFICACIÓN DE PBI HECHO:
- Entrega un incremento del producto.
- Cumple con el criterio de aceptación establecido.
- Está documentado para su uso.
- Se adhiere a los estándares de codificación.
- Mantiene los índices de rendimiento de los productos.
Este es un ejemplo de lista de verificación para el DoD. Los equipos definen y mantienen las listas de verificación, que muestran sus preferencias para verificar el trabajo.
Otras lecturas
Gran parte de este contenido compartido en este artículo proviene del libro PBB que puedes leer para obtener más información sobre el uso del Canvas de PBB y cómo escribir historias de usuarios útiles. En este artículo se describe este enfoque en el contexto de Scrum. En el blog puedes encontrar más artículos.
