Artículo revisado por: Carlos Marín Pascual.
Las Historias de Usuario son esenciales. Conocer las necesidades reales de los usuarios y desarrollar funcionalidades acordes con esta realidad son factores clave para construir productos de éxito. En este artículo, descubrirá más detalles sobre este tema, especialmente sobre técnicas para escribir historias de usuario asertivas y de calidad, ejemplos de aplicación y otros aspectos de las Historias de Usuario, que también se abordan en el libro Product Backlog Building (PBB), de los autores Fábio Aguiar y yo, Paulo Caroli.
Aparición de Historias de Usuario
Cuando hablamos de Historias de Usuario, no podemos olvidar un nombre importante: el autor Mike Cohn. Es considerado uno de los grandes referentes en lo que a Historias de Usuario se refiere.
En su libro User Stories Applied: For Agile Software Development, Mike Cohn señala que la mejor manera de crear un producto que se ajuste a las necesidades de los usuarios es haciendo uso de las Historias de Usuario.
Fue Mike Cohn quien popularizó las siglas INVEST, que verás con más detalle a continuación. Para Cohn, es fundamental identificar los roles de cada usuario, porque, a partir de eso, hay una conexión con el dolor o necesidad que tiene ese usuario y, por lo tanto, la creación de productos valiosos.
Método de Cascada y Métodos Ágiles
El Método o Modelo en Cascada (del inglés Waterfall), también llamado Método Tradicional, es un modelo de gestión basado en fases, donde el final de una fase indica el comienzo de la siguiente. Por ejemplo: planificación, ejecución, validación y entrega.
Sin embargo, a pesar del éxito del siglo pasado, hoy en día, el Modelo en Cascada parece ser un modelo desfasado y en algunos casos arriesgado, considerando que solo se avanza en el proyecto desde el final de cada etapa y, el avance a la siguiente fase depende de la aprobación del artefacto generado en la fase anterior.
Los Métodos Ágiles llegaron para cambiar esta realidad. Con un modelo mucho más flexible, el equipo trabaja en ciclos cortos y frecuentes, entregas rápidas y centradas en el usuario. Otra gran diferencia radica en el hecho de que se pueden realizar cambios a lo largo del desarrollo del producto, mientras que en el método en Cascada los cambios no son tan bien recibidos.
Formatos de Historias de Usuario
Originalmente, las Historias de Usuario nacieron con el propósito de que la propia persona afectada escribiera dichas Historias. Sin embargo, con el tiempo y, en gran medida por la expansión del marco Scrum, el Propietario del Producto (PO de Product Owner, en inglés) se convirtió en la principal persona que escribía estas historias y las organizaba en un Backlog de producto. Sin embargo, cualquiera puede (y debe) escribir una historia de usuario. Por cierto, PBB le ayuda a escribir buenas Historias de Usuario. Puede obtener más información en este artículo y en el libro PBB.
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 su libro Extreme Programming Explored, William C. Wake creó el acrónimo INVEST, donde cada letra representa una de las seis características importantes de una historia de usuario: independiente, negociable, valiosa, estimable, pequeña y comprobable.
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.
- 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.
- VALIOSO (Valuable): Una historia describe claramente el valor para el cliente.
- ESTIMABLE (Estimable): Una historia proporciona suficiente información para que el equipo realice una estimación de alto nivel.
- PEQUEÑA (Small): Una buena historia debe ser relativamente pequeña para completarse en el menor tiempo posible y encajar en una iteración dado el contexto del equipo.
- COMPROBABLE (Testable): Una historia debe ser lo suficientemente clara como para que se puedan definir pruebas para ella..
Por lo tanto, el acrónimo INVEST ayuda a escribir buenas historias, con las siguientes preguntas: ¿es independiente? ¿Negociable? ¿Valioso para el negocio? ¿Estimable? ¿A medida? ¿Comprobable?
Modelo 3Cs
Además del modelo INVEST, una buena Historia de Usuario también consta de tres elementos, llamados las 3C:
TARJETA (Card): La descripción realizada para la historia de usuario debe caber en una ficha, con información breve y suficiente para identificarla. El formato más común es:
- COMO <función/perfil>
- QUIERO <acción/objetivo>
- PARA <beneficio/motivo>
CONVERSACIÓN (Conversation): Para aclarar dudas y detallar el trabajo para la implementación, es necesario tener muchas conversaciones. En las historias de usuario, las conversaciones serán continuas, no solo al principio cuando se define el requisito. Los mejores documentos son aquellos que nos ayudan a recordar nuestras conversaciones, no a reemplazarlas.
CONFIRMACIÓN (Confirmation): En este paso se determina si se ha logrado el objetivo de la historia de usuario. Para esto, los criterios de aceptación son importantes y deben definirse para cada historia antes de que el equipo comience a implementarla.
Criterios de Aceptación
Los Criterios de aceptación pretenden describir cómo validar una historia de usuario. Generalmente, una historia tendrá algunos criterios de aceptación, también llamados AC (Acceptance Criteria en inglés). Al hacerlo, los AC proporcionan una lista de verificación que determina cuándo una historia de usuario está completa y con el funcionamiento esperado.
Del libro Product Backlog Building, traemos como ejemplo la siguiente historia: “Como cliente, me gustaría sacar dinero en el cajero automático para evitar la fila del banco”. Aquí hay una lista posible de Criterios de Aceptación para esta situación:
- El cliente con saldo suficiente puede retirar dinero de su cuenta.
- El cliente sin saldo suficiente no puede retirar dinero de su cuenta.
- El cliente con saldo suficiente no puede retirar dinero de su cuenta si el cajero automático no tiene suficiente dinero para retirar.
El formato presentado se compara con una lista de verificación utilizada para verificar que la historia esté completa y funcionando, es decir, si cumple todos los Criterios de Aceptación. Si hay más de cinco criterios, se recomienda dividir la historia en dos.
Dividir Historias en Tareas
La descomposición de historias en pedazos más pequeños da lugar a tareas. Con ellas, el equipo de desarrollo entra en detalles técnicos sobre cómo se implementarán las piezas más pequeñas. A diferencia de las historias, las tareas son más directas y con lenguaje técnico, no siguiendo un formato textual definido.
Las tareas identifican algo que debe hacerse como parte de una Historia. Como ejemplos de tareas tenemos: cambiar campos en la tabla de inicio, crear cuentas de prueba para usuarios, automatizar scripts de generación de datos, etc.
Interfaz de Usuario
La forma de describir la interfaz de una Historia varía según la decisión del equipo y esto se puede hacer de las siguientes maneras: boceto (o dibujos simples en papel), wireframes, maquetas o prototipos.
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.
Escribiendo Historias con el Canvas PBB
El Canvas PBB nos ayudará a escribir Historias de Usuario. Como se vio anteriormente, escribir una Historia de Usuario responde básicamente a tres preguntas principales: ¿Quién? ¿Qué? ¿Para qué?
En vista de esto, el Canvas PBB viene a ayudar en la redacción de Historias de Usuario. El método tiene el «¿quién?» qué es la persona; ¿qué?» cuáles son los PBI (abreviatura de Product Backlog Items); y el «¿para qué?» que está en los beneficios de la funcionalidad.
Ejemplo de Historia de Usuario
En el libro de PBB, compartimos algunos ejemplos de Historias de Usuario, como la creación del producto digital “La Colección de Charlas”. Creado por la comunidad Tá Safo, tiene como objetivo preparar un portafolio de conferencias y organizar eventos. A continuación, verá algunos detalles sobre la descripción de tres funcionalidades del producto con algunas Historias de Usuario, criterios de aceptación y tareas.
Persona, Feature, Historias
A continuación, se muestran tres features de muestra con sus respectivas personas e Historias de Usuario.
PERSONAJE: Ponente
FEATURE 1: Publicar una charla.
HISTORIA 1.1: Como ponente, puedo acceder al escritorio para administrar de forma privada.
HISTORIA 1.2: Como ponente, puedo publicar trabajos para que el contenido esté disponible.
HISTORIA 1.3: Como ponente, puedo vincular la presentación externa para integrar trabajos.
PERSONA: Participante
FEATURE 2: Participar en el evento.
HISTORIA 2.1: Como participante, puedo encontrar el evento disponible para ver el cronograma.
HISTORIA 2.2: Como participante, puedo registrarme en el evento para consumir contenido.
HISTORIA 2.3: Como participante, puedo registrarme en el evento para confirmar la asistencia.
PERSONAJE: Organizador
FEATURE 3: Organizar evento.
HISTORIA 3.1: Como organizador, puedo establecer el horario del evento para dar a conocer la grilla.
HISTORIA 3.2: Como organizador, puedo publicitar el evento en los medios para atraer audiencias.
HISTORIA 3.3: Como organizador, puedo invitar a coorganizadores del evento para facilitar la organización.
Historias, Criterios de Aceptación, Tareas
Ahora, mostramos un ejemplo de una historia de la funcionalidad “Publicar una charla” del producto “Colección de Charlas”.
HISTORIA 1.3
Como ponente, puedo vincular la presentación externa para integrar trabajos.
CRITERIOS DE ACEPTACIÓN 1
ESCENARIO 1: Asociación de presentaciones en plataformas para compartir presentaciones.
– Dado que existe un enlace válido en la plataforma SlideShare
– Cuándo se vincula el enlace de presentación externa
– Entonces se mostrará una vista previa de la presentación en la pantalla
CRITERIOS DE ACEPTACIÓN 2
ESCENARIO 2: Asociar la presentación con obra editorial.
– Dado que el enlace de presentación es válido
– Cuándo se publique la charla
– Entonces se mostrará la presentación asociada en los detalles de la charla publicada.
TAREAS
– Consumir el punto final de presentación.
– Crear la interfaz de usuario para mostrar el archivo PDF de la presentación.
– Cree una lógica de back-end para vincular la presentación con el trabajo publicado.
– Cambiar parámetro a enlace público o privado.
– Cree datos de prueba para verificar que el enlace sea válido.
– Cambiar base de datos para incluir enlace de presentación.
TAPAs para Comprobar la Calidad de las Historias de Usuario
Incluso usando PBB para generar tus historias, necesitas verificar su calidad, es decir, la alineación del equipo con los principales atributos de la historia. Fue con esta intención que Manoel Pimentel creó la técnica TAPAs.
Según él, TAPAs ayuda a enriquecer el análisis y la comprensión de los principales atributos de una historia de usuario, que forman el acrónimo TAPA: tangible, atómica, preciosa, accesible:
- TANGIBLE: La historia es palpable, concreta y específica.
- ATÓMICA: La historia es pequeña e independiente.
- PRECIOSA: La historia resuelve un problema importante para el usuario.
- ACCESIBLE: La historia es clara y fácil de entender.
Similar a una comida en un restaurante de tapas español, Manoel Pimentel explica que comerás varias tapas, que se entregan con frecuencia (Sprint to Sprint). A diferencia de los restaurantes tradicionales (no ágiles), que trabajan con un plato principal que tardará más en servirse, y probablemente necesitarás un tenedor y un cuchillo para cortarlo en trozos más pequeños.
Facilitadores en PBB
En una sesión de PBB, es fundamental definir quién será la llamada persona facilitadora. Entre las misiones del facilitador están: ayudar a decidir cuánto durará la sesión; adaptar la facilitación de PBB de acuerdo con el contexto y la realidad del equipo y la organización; provocar la colaboración de todas las personas del equipo; además de fomentar la comunicación activa de todos los participantes en la ideación, comprensión, análisis y creación de incrementos de producto.
La persona facilitadora puede ser cualquier persona que tenga interés en ayudar a construir un buen Backlog de Producto. Por lo general, alguien del equipo ya asume el rol de facilitador de los talleres colaborativos. Esta persona es una buena candidata para una primera facilitación de PBB. En este sentido, también tenemos varias personas interesadas en una buena facilitación, como por ejemplo, el Product Owner, el Scrum Master, el Agile coach, el product manager y el desarrollador.
Definición de Preparado
La Definición de Preparado (DoR – Definition of Ready, en inglés) 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.
Para cada candidato de PBI para el próximo Sprint, el equipo verifica que:
- El PBI está representado por una Historia de Usuario.
- El PBI está cubierto por los criterios de aceptación.
- El PBI se asigna a una interfaz (cuando es necesario).
- Se identifican las dependencias de PBI (si las hay).
El refinamiento del backlog de producto debe ser continuo. 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, en inglés) es el acuerdo que demuestra la calidad del PBI producido, en el que “hecho” confirma la satisfacción de todos con el trabajo realizado.
Con esto, en relación a cada PBI considerado hecho, el equipo demuestra que el ítem:
- Ofrece un incremento de producto.
- Contempla los criterios de aceptación establecidos.
- Está documentado para su uso.
- Se adhiere a los estándares de codificación.
- Mantiene los índices de rendimiento de los productos.
Historias de Usuarios en Scrum
Scrum es considerada la metodología ágil más famosa y se basa en el concepto de Sprint -ciclos cortos (una o dos semanas)- para mantener la cadencia de un equipo. Por ello, se recomienda que cada Sprint comience con una reunión de planificación (Sprint Planning) y finalice con una reunión de revisión del trabajo realizado (Sprint Review).
Antes del Sprint Planning, la funcionalidad deseada se detalla en las Historias de Usuario. Para esta construcción, el método PBB ayudará a dividir estas funcionalidades (features en inglés) en historias, es decir, las funcionalidades de su Canvas de PBB se detallarán en las Historias de Usuario.
De esa forma, durante el Sprint, el equipo Scrum trabaja en las Historias de Usuario. En el Sprint Review, el equipo verificará el progreso de estas historias, sus funcionalidades y el incremento del producto. Posteriormente, el equipo Scrum entrega el incremento y el equipo sigue trabajando en las próximas funcionalidades e Historias para el próximo incremento del producto.
Historias de Usuarios en Kanban
Otro método ampliamente reconocido es Kanban, creado por David J. Anderson. Es ampliamente utilizado para gestionar el flujo de trabajo de un proceso incremental y evolutivo. Así, es posible tener una visión compartida de todas las fases del flujo de trabajo, las personas y las tareas a realizar.
Kanban recomienda limitar el trabajo en curso (work-in-progress o WIP en inglés). Como resultado, se produce un «sistema de extracción», es decir, un nuevo trabajo solo avanza a una nueva etapa cuando hay capacidad disponible dentro del límite WIP. Esto favorece la organización, la planificación, la agilidad y no sobrecarga al equipo.
En un tablero Kanban simplificado, ensamblarás y dividirás tu trabajo con las próximas funcionalidades e historias de usuario a implementar (To Do), las que están siendo implementadas (Doing) y, en la última columna, las funcionalidades que ya están terminadas (Hecho). Cuando terminas todas las Historias de Usuario de una funcionalidad, haces espacio en el tablero y añades la Historias de Usuario de la siguiente funcionalidad.
¿Te gustó este contenido?
Gran parte de este contenido proviene del libro PBB, un poco del libro Lean Inception y, un poco más, en otras publicaciones en el blog de Caroli.org.
Este contenido fue escrito y compilado por mi, Paulo Caroli, y fue revisado por Carlos Marín Pascual.
>> Consulte el libro PBB y Formación PBB.
>> En la página del libro PBB también encontrará excelente material (DoR, DoD, ACs, etc.) para descargar en formato PDF.
>> Vea también: El Canvas de PBB
En Caroli.org hay, entre otras cosas, varios materiales relacionados con el tema. Accede ahora y continúa con tu proceso de aprendizaje, además de construir un producto exitoso.