Mejores Historias de Usuario para Scrum
Las Historias de Usuario son una herramienta muy usada en el mundo de la Agilidad, vienen de Extreme Programming y han sido adoptadas en marcos de trabajo ágiles como Scrum. Pero… ¿Cómo escribimos mejores Historias de Usuario para Scrum?.
Hay que decir primero que las Historias de Usuario no son solo para la Agilidad, sino más bien son algo que describe lo que hace un usuario en el sistema para completar una determinada tarea.
Nacieron precisamente de una carencia de los requerimientos, los requerimientos funcionales anteriormente tenían un enfoque desde el sistema. Por ejemplo:
El sistema debe permitir …
Las Historias de Usuario por otro lado sacan del contexto al sistema y expresan que necesita el usuario. Por ejemplo:
Ana como ejecutiva de cuentas requiere … para …
La gran diferencia es que el usuario nos transmite así su necesidad… desde su óptica, con libertad de expresarse, sin lenguajes restrictivos, para luego ser traducido a una perspectiva del sistema por un analista de negocios.
Para escribir mejores Historias de Usuario para Scrum, debemos regresar a ver los principios de la agilidad.
Manifiesto por el Desarrollo Ágil de Software y su conexión con las Historias de Usuario
El Manifiesto ágil nos dice: “Estamos descubriendo formas mejores de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A través de este trabajo hemos aprendido a valorar: …”.
Individuos e interacciones sobre procesos y herramientas
Las Historias de Usuario crean un entendimiento compartido de una conversación, para los miembros del equipo, los stakeholders y los usuarios finales.
Software funcionando sobre documentación extensiva
Un solo documento de acuerdos reemplaza a mil redacción de actas.
Colaboración con el cliente sobre negociación contractual
Queremos deleitar al cliente… y una negociación contractual no es la mejor manera. La colaboración continua y fluida es clave en los productos y esto representa un Historia de Usuario.
Respuesta ante el cambio sobre seguir un plan
Es necesario tener un plan pero debe ser flexible, general y permitir reaccionar al cambio. El feedback del cliente es el único que nos marca el éxito de un Producto, más allá de cumplir funcionalidades, tiempos y presupuestos.
¿Cómo se relacionan las Historias de Usuario con los principios de la Agilidad?
La más alta prioridad es satisfacer al cliente mediante la temprana y continua entrega de software de valor, mismo valor que se expresa en la historia de usuario.
Los cambios son bienvenidos incluso si es tarde en desarrollo, y si dividimos bien las historias de usuario reducimos los impactos en desarrollo.
Entregar software frecuentemente, desde un par de semanas hasta máximo un par de meses, para esto hay que trabajar en historias pequeñas completas que realmente agreguen por si solas.
Las personas de negocio y los desarrolladores deben trabajar juntos diariamente a lo largo del proyecto, y las Historias de Usuario son por naturaleza escritas en colaboración continua y fluida.
Construir proyectos alrededor de gente motivada, darles el ambiente y soporte que necesitan, y confiar que van a realizar el trabajo, y aquí la colaboración y apropiación de la solución motiva a las personas alrededor de las conversaciones de la Historia de Usuario.
La forma más eficiente y efectiva de transmitir información hacia y dentro del equipo es una conversación cara a cara, parte de la dinámica de las Historias de Usuario.
El software funcionando es la principal medida de progreso, mismo progreso que se madura, prioriza, simplifica y entrega a través de mejores Historias de Usuario.
Un proceso ágil promueve un desarrollo sustentable, las Historias de usuario nos permite mantener un ritmo predecible de entrega de valor constante.
Poner continua atención a la excelencia técnica y un buen diseño mejora la agilidad.
Simplicidad, el arte de maximizar la cantidad de trabajo no hecho es esencial, hay que enfocarse en los resultados (valor expresado en la Historia de Usuario) y no en las salidas.
La mejor arquitectura, requerimientos y diseño emergen de equipos auto-organizados.
En intervalos regulares, el equipo reflexiona en como ser mas efectivo, luego hace ajustes en su comportamiento acorde a las conclusiones.
Escribiendo mejores Historias de Usuario para Scrum
Como se dijo anteriormente las Historias de usuario no son solo para Scrum pero es cierto que dado las dinámicas y artefactos de Scrum se pone énfasis en ciertos detalles que hacen que las mismas sean más adecuadas para implementar en los ciclos iterativos e incrementales de la propuesta Scrum.
En las siguientes secciones vamos a revisar en detalle las Historias de Usuario sus componentes, características y mejores pŕacticas.
Contenido:
Introducción a las Historias de Usuario
¿Qué son las Historias de Usuario y por qué estas son usadas?
Es una pequeña unidad para trabajar, que dice desde la perspectiva del usuario cual es la funcionalidad deseada.
Mueve el foco de escribir requerimientos a conversar sobre los requerimientos, es decir el principal objetivo es habilitar la conversación y fomentar la colaboración.
Las Historias de Usuario ponen a los usuarios finales en el centro de la conversación.
Historias de Usuario además, nos provee un contexto no técnico para el equipo de desarrollo. El equipo después de participar en una Historia de Usuario sabe porque ellos están construyendo lo que están construyendo y que valor la solución provee.
Una Historia de Usuario escrita efectivamente incrementa la colaboración, la creatividad y el producto en general.
Al escribir la Historia de Usuario debes preguntarte tres cosas básicas:
¿Quién es tu cliente?
¿Qué lo satisface? y,
¿Qué necesita?
La Historia de Usuario ayuda a entregar el más alto valor enfocándose en pequeñas y urgentes necesidades del cliente.
Cuando la necesidad del cliente es descompuesta en pequeñas funcionalidades es posible entregar valor en días o incluso en horas.
Partiendo de un enfoque de entregar el más alto valor en cada Historia de Usuario, conseguimos que:
- el equipo esté empoderado
- el equipo esté conectado
el equipo pueda colaborar con el usuario final.
Al enfocarse y brindar el mayor valor con cada historia de usuario, los equipos están empoderados, están conectados y pueden colaborar con el usuario final. Y cuando se conectan directamente con el usuario final, los desarrolladores tienen una oportunidad de entender realmente desde la perspectiva del usuario, sus desafíos, sus puntos de dolor, y reciben esa retroalimentación temprana con cada entrega, para que puedan asegurarse que están construyendo un producto adecuado.
Formato de una Historia de Usuario:
[who] as as <type of user>
[what] I would like <goal>
[why> So that <reason> or <why>
Siempre se expresa una Historia de Usuario desde la perspectiva del cliente “As a/an…”.
¿Quién escribe las Historia de Usuario y cuando estas son escritas?
Todos los integrantes del equipo pueden escribir Historias de Usuario sin embargo la mayoría del tiempo lo hace el Product Owner o el Analista de Negocio (Business Analyst), esto es más porque ellos están más tiempo cerca del cliente/usuario pero en realidad todo el mundo puede hacerlo.
Una de las mejores prácticas es que el equipo debe ser experto acerca del cliente y del producto por tanto estén en la capacidad de escribir Historias de Usuario. No deben necesariamente hacerlo pero deberían tener esa capacidad y además la capacidad de conversar qué es lo siguiente que viene del Product Backlog.
Por ejemplo el Product Owner y analista de Negocio escriben la primera versión del Historia de Usuario, pero luego el equipo ayuda a madurarla, mejorándola y añadiendo detalles y cosas.
¿Cuando son escritas? Pues en todo momento que llegan o surgen de conversaciones, a lo mejor en primera instancia es un borrador que se debe ir iterando con el equipo y priorizando pero lo importante es tomar nota de aquello que el usuario nos cuenta.
Hay que tomar en cuenta que una idea por si no es una Historia de Usuario, por lo que hay que tomar un tiempo para conversar y transformarla a una Historia de Usuario. Por esta razón es muy común que se manejen documentos alternativos al Product Backlog (donde ya están las Historias de Usuario) para ir desarrollando esas ideas.
Uno de esos momentos es los Demo de productos en donde hay feedback de lo que se hizo y se expresan además cosas que se esperan tener del producto. Estas conversaciones pueden llevarnos a nuevas Historias de Usuario y/o ajustes a Historias de Usuario existentes.
Otro instrumento que se suele tener en los equipos son los Talleres de Historias de Usuario (Story Workshops), que son sesiones cada cierto periodo de tiempo (2 o 3 meses) para escribir Historias de Usuario para los siguientes tres meses (al menos su versión inicial).
Hay otras sesiones importantes como el Backlog Refinement o (Grooming) en donde se crean nuevas Historias de Usuario, se descartan otras, y se estiman o se ajusta la estimación de Historias de Usuario faltantes. Incluso en estas sesiones se Divide (Splitting)” las Historias de Usuario.
3 C's para escribir historias de usuario
Las 3 C’s son las recomendaciones al escribir Historias de Usuario: Tarjeta (Card), Conversación (Conversation) y Confirmación (Confirmation).
La Historia debe ser lo suficientemente pequeña para que entre en una tarjeta y que invite a una conversación.
Hay que recordar que en un enfoque ágil de desarrollo no tienes que tenerlo todo perfectamente definido por adelantado antes de llevarlo al equipo. El equipo y el negocio realmente pueden trabajar juntos para descubrir la necesidad mientras trabajan juntos, y esto puede acordarse a través de la conversación y colaboración alrededor de las Historias de Usuario.
La tarjeta conduce a una conversación entre el Product Owner y los equipos, y esto debe suceder en persona tanto como se posible, y finalmente debe incluir una especie de confirmación.
Ese momento es cuando el equipo sabe realmente qué se debe hacer y en este momento es cuando entran los criterios de aceptación.
Diferencias entre Requerimientos y Historias de Usuario
Muchas veces las solemos intercambiar pero no son lo mismo de ninguna manera.
Existen 4 diferencias básicas:
Perspectiva:
El requerimiento tiene perspectiva desde el sistema o desde la solución (el sistema debe…).
La Historia de Usuario lo mira desde el problema descrito desde el punto de vista del cliente (como supervisor… quiero… para..).
Cuando estas son usadas:
Los Requerimientos tradicionales se utilizan en proyectos no ágiles, por ejemplo en metodologías en espiral o cascada.
Las Historias de Usuario se usan en proyectos ágiles mayormente.
Cómo son obtenidas/definidas:
Para los requerimientos tradicionales los Analistas de Negocio usan técnicas como entrevistas, encuestas u otras que extraigan respuestas en reacción a las acciones o preguntas, para luego documentarlas en los instrumentos que usen en la organización (ejemplo un BRD – Business Requirement document). Suele ser una actividad única, el Analista de Negocio obtiene las respuestas las documenta y cambia a la siguiente cosa
En Agil la Historia de Usuario es una discusión y un esfuerzo colaborativo. La manera en que son escritas ayudan a empujar una conversación, terminando en cosas como porque la necesitan realmente?, cuales son los detalles?, que sabemos y que no sabemos? cuales son los matices que la componen?. Esto es un trabajo de salida constante de información y de conversaciones constantes que aseguran que se consideren todas esas pequeñas piezas desde la perspectiva del usuario.
Quien es el dueño:
Los requerimientos tradicionales normalmente pertenecen a quien lo escribió, dado que lo hizo en su lenguaje y en su entendimiento y más allá de eso lo hizo desde la perspectiva de sistema o solución, lo que los hace confusos si no entiendes el contexto desde donde fue escrito. Generalmente el analista de Negocio es el dueño de esos requerimientos con su estructura y normalmente esto implica que se “deba” explicar el documento a otros lectores y de como hacer cambios en el mismo, sintaxis, etc.
En enfoque Ágil, el dueño es el Grupo ya que se escribió en grupo con muchas conversaciones y desde la perspectiva del usuario con lenguaje natural y propio del problema. Todos sienten su piel en el juego y que han ayudado a desarrollar esa Historia de Usuario.
Diferencias entre Casos de Uso y Historias de Usuario
Ambas describen una misma meta pero tiene diferentes propósitos: los Historias de Usuario son acerca de necesidades, mientras que los Casos de Uso ayudan a explicar el comportamiento que el sistema debe tener para ser exitoso.
Las Historias de Usuario son realmente pequeñas y concisas, su alcance es muy delgado y específico, en cambio las Casos de Uso describen las interacciones de todo el sistema y a veces con otros sistemas.
Roles de Usuario
Cuando escribes Historias de Usuario tu vas a querer conocer a los usuarios de esas Historias de Usuario, saber qué rol cumplen, como operan, etc.
Al tener esta información sueles tener muchos roles y no tiene sentido y se vuelve inmanejable describir a cada uno en una historia de usuario.
Se recomienda crear grupos de usuarios/roles sobre los cuales discutir las características a implementar.
Según Scrum Alliance los Roles de Usuario son usuarios que comparten:
necesidades comunes
intereses
expectativas
comportamientos
Son entonces una manera de pensar en ciertos usuarios y conversar sobre ellos porque comparten cosas.
Aquí la recomendación siempre será hacer una lluvia de ideas de todos los roles y refinar esta lista y agruparla según los criterios de Roles de Usuarios de Scrum Alliance por ejemplo. Esto podría ser parte de la Incepción Ágil.
Personas
Una vez que tengas los roles puedes crear los “Personas”, de forma que pueda visualizar mejor esa clase de persona:
Persona, es una representación ficticia del usuario, es como la figura Persona que se usa por ejemplo en procesos Customer Journey Map.
Más de las Historias de Usuario
Ojo que las Historias de Usuario son como un punto de partida en donde puedes tener dentro cosas como documentos de respaldo, wireframes, maquetas de UI, diagramas de flujo, y una serie de estas representaciones visuales de requisitos.
Es importante esto porque a menudo significan un entendimiento común para todos los stakeholders así que no subestimes esta parte.
No asumas que una Historia de Usuario tiene una funcionalidad implícita, esto por ejemplo en el caso de una Historia de Usuario que habla de crear registros, a menudo se suele omitir la actualización de esa información, pero esto puede causar problemas ya que la actualización puede implicar por ejemplo connotaciones de recálculo de otros valores, o reprogramación de otras actividades.
Es importante ser explícito en las funcionalidades para describir que una Historia de Usuario incluye el CRUD completo o que hay otras Historias de Usuario que especifican tal feature.
Otro detalle importante es el “Porqué?”, ya que nos da el contexto del valor que representa la Historia de Usuario para el cliente y el negocio, y, nos ayuda a priorizarla en el Backlog.
A menudo las Historias de Usuario quedan mal documentadas y no proveen los suficientes detalles, no para estimarlas, pero si para entenderlas tanto que el “que busca”, así como el “porqué es importante” ya que es probable que después de un tiempo al regresar a retomar una conversación no podamos identificar realmente lo que quisimos expresar.
Hay veces que una Historia de Usuario involucra una funcionalidad compartida entre dos o más roles. Por ejemplo dar de alta a un usuario, esta funcionalidad involucra crear un usuario en el sistema, que lo puede hacer el mismo usuario que desea darse de alta o un administrador de usuarios; sin embargo aunque las pantallas e input son similares no tienen los mismos detalles y accesos por lo que está bien y es correcto tener dos o más Historias de Usuario que representen cada caso con sus particularidades aunque cierta funcionalidad podría ser implementada por la otra Historia de Usuario.
Criterios de Aceptación
Entendiendo los Criterio de Aceptación
La Historia de Usuario no provee suficientes detalles por sí sola para que alguien pueda tomarla y crear algún tipo de solución.
Es por eso que tenemos los criterios de aceptación, que son una serie de condiciones que un producto debe cumplir para ser aceptado por un usuario, un cliente o otro sistema.
Provee estándares y requerimientos que el resultado final debe cumplir para ser exitoso.
Hay cuatro beneficios principales de los criterios de aceptación:
Crea un entendimiento común: provee detalles necesarios en una solución como criterio compartido por los stakeholders.
Define el alcance: le dice a los creadores de la solución dónde empezar y dónde terminar, y que es lo importante.
Valida que una Historia de Usuario está completada: provee un checklist o condiciones que al ser alcanzadas nos indican que finalizó de una forma certera.
Muestra que probar y si pasa la prueba la solución entregada.
Normalmente obtenemos esos detalles faltantes para figurar una solución a través de preguntas poderosas como por ejemplo:
Cuál es la información más relevante a mostrar?
Cómo se va a obtener esa información?
A qué se refiere tal o cual término mencionado?
Quién puede obtener esa información?,
etc.
Su definición pasa por un proceso evolutivo en donde las preguntas fluyen conforme varias conversaciones suceden.
Escribiendo un Criterio de Aceptación
Hay varias formas de escribir los criterios de aceptación entre los cuales mencionamos las siguientes:
Checklist Format, listando esos detalles que hacer la solución exitosa.
Given-(And)-When-Then-(And) que es otro enfoque especialmente usado en pruebas BDD (Behavior Driven Development).
¿Quién escribe los Criterios de Aceptación y cuando son escritos?
El Product Owner generalmente escribe la Historia de Usuario inicial y luego suele recaer la responsabilidad de escribir los criterios de aceptación en el Analista de Negocios, en donde él aplica todo su expertise de análisis de negocios y elicitación (traspaso de información de forma fluida de un ser humano a otro por medio del lenguaje) para el fin.
Aquí el Analista de Negocios suele usar muchas cosas como entrevistas, sesiones de brainstorming, talleres, etc. de forma que pueda documentar con precisión los criterios de aceptación.
Normalmente al crear una Historia de Usuario no se escriben los criterios de aceptación, y la misma se va a iterando en conversaciones en el tiempo. La idea es que la Historia de Usuario esté en un punto sólido de forma que el Analista de Negocios pueda en ese momento trabajar en los criterios de aceptación.
Ninguna Historia de Usuario debería entrar en el Sprint Backlog si la misma no tiene criterios de aceptación.
Mejores prácticas para los Criterios de Aceptación
Escríbelos en texto simple, evita tecnicismos y modismos de forma que sea legible por todos los integrantes del equipo.
Explica la intención no la solución que se necesita.
Mantenlos medibles evita puntos grises, es decir, debe haber criterios blanco o negro porque el gris es sujeto a quien lo usa y como lo usa.
Listas extensas de criterios de aceptación son aceptables, luego preocúpate de dividir la Historia de Usuario; esto, al mismo tiempo significa para los stakeholders interiorizar cuan complejo puede ser la solución y entender que se requiere dividir dicha Historia de Usuario para poder cumplirla en un Sprint.
Escribir mejores Historias de Usuario con INVEST
¿Qué es INVEST?
Una buena práctica al escribir Historias de Usuario es chequearlas con el criterio INVEST.
INVEST significa:
Independiente: la idea es ver si hay dependencias con otras Historias de Usuario ya que puede resultar en problemas de planificación. Incluso afecta a la prioridad ya que una dependencia puede tener baja prioridad pero bloquea una de alta prioridad.
Negociable: la idea es que no es un contrato sino una invitación a una conversación en donde se acuerdan los detalles, los tiempos y los criterios de aceptación entre todo el equipo.
Valiosa: el valor de esa historia debe estar realmente claro para todo el equipo, no solo desde la perspectiva del cliente sino en términos de negocio, y como todas estas Historias de Usuario trazan el camino a los metas del negocio.
Estimable: debe tener los detalles suficientes para que el equipo las pueda estimar, no todos los detalles pero si lo relevante a la Historia.
Pequeña (Small): si la Historia no puede ser completada en un Sprint es muy grande y debería ser dividida, de igual forma si no es necesario hacer una Historia más pequeña pues evite hacerlo ya que al dividirla puede quedar la sensación de trabajo incompleto en un todo.
Por ejemplo separar un CRUD no tiene mucho sentido a menos que haya algo específico que cause una acción en particular.
Comprobable (Testable): de modo que podamos decir que la implementación está finalizada correctamente.
Más del criterio INVEST
Una de las cosas más importante de una Historia de Usuario es mantenerla negociable, es decir que se permita cambios en la misma. Recuerda que no es un BRD, esto especialmente si hablamos de un ambiente ágil, no tiene sentido hacer algo que nadie quiere por cumplir un BDR.
Otra cosa muy importante es siempre cuestionar si aporta valor, ya que muchas historias parecen aportar valor pero no es relevante frente a las prioridades funcionales y los objetivos de negocio por lo que no debería ser implementada.
Mantenerlas pequeñas por otro lado es crucial porque pueden liberarse al uso rápidamente y retornar la inversión al negocio.
Recuerda que INVEST es una guía y no son reglas estrictas así que hay que tomarlas en cuenta para construir nuestro Backlog pero no tratar de forzar todas las ideas.
Non-Historias de Usuario
Entendiendo los Spikes
Hay aspectos en la solución que no se relacionan al negocio en sí, como por ejemplo la arquitectura, que de acuerdo a los principios de Scrum debe evolucionar según sigue el desarrollo o la implementación del producto. Esto significa que no toda la infraestructura como toda la arquitectura debe estar prediseñada antes de arrancar el Producto.
Spike es una investigación de un conocimiento o incluso la producción de un nuevo conocimiento que da una respuesta para la solución de algo en el Backlog.
Los Spikes son usados para responder a estos retos técnicos e incluso a problemas de diseño.
El resultado de un Spike puede derivar en una nueva Historia de Usuario o una actualización a una existente.
Una de las razones por las que los Spikes pueden ser usados es la investigación, cuando una Historia de Usuario es muy grande para ser estimada, así se analiza el comportamiento esperado, se divide la Historia en otras más pequeñas y se reduce significativamente el riesgo y la incertidumbre en una story.
Recuerda que no por estar en un enfoque ágil vas a dejar de necesitar analizar ciertos aspectos técnicos, de diseño o incertidumbres.
Debes ser documentados como cualquier Historia de Usuario (pero no son Historias de Usuario realmente), deben tener criterios de aceptación para saber qué preguntas tiene que responder o qué preocupaciones tiene que aclarar, y así mismo ir al Backlog ser priorizado y eventualmente incluido en un Sprint Backlog.
La diferencia principal es que en lugar de generar valor para el negocio debe responder preguntas al equipo, preguntas como:
Es esto factible?
Podemos hacer eso con nuestra actual tecnología?
Es esta la mejor opción o hay otras que deberíamos considerar para entregar la misma característica/valor?
Cuáles son los riesgos de tomar cierto camino?
Entendiendo las Historias de Usuario Técnicas y de Infraestructura.
Hay necesidades en la implementación de un producto que no tiene que ver con sus usuarios o el negocio, sino que son necesidades para poder crear el mismo Producto, esto incluye por ejemplo:
Implementación de herramientas de testing.
Implementación de automatizaciones de despliegues.
Implementación de servidores.
Implementación de esquemas de seguridad externos, etc.
Estas Historias de Usuario de Infraestructura o Técnicas tiene el mismo tratamiento que las de negocio e igualmente con criterios de aceptación, adicionadas al Backlog, priorizadas y eventualmente incluidas en un Sprint.
La parte “como … “ (as a …) en la Historia de Usuario es confusa en esta clase de Historias pero a menudo el usuario que requiere dicha feature es el programador, el arquitecto, o incluso el equipo de desarrollo.
Estimando Historias de Usuario
Conceptos Generales de Estimación
En la metodologías tradicionales como cascada las estimaciones son absolutas y van en métricas como horas o días.
En proyectos ágiles son muy importantes las estimaciones pero tienen una diferencia… en los proyectos ágiles las estimaciones no son absolutas sino relativas. Estas estimaciones son producto de comparar tareas unas con otras y así poderlas agrupar según el grupo la complejidad en la que cada una se ubique.
Una métrica bastante conocida es la T-shirt technique (tallas de camiseta) con medidas como pequeña, mediana o grande. Esto nos permite ubicar en un determinado conjunto a tareas que son parecidas unas con otras.
Otra técnica es la serie de Fibonacci que permite una una estimación relativa con un número que determina la complejidad.
Entendiendo la técnica de estimación Fibonacci
Aquí los valores de la serie de Fibonacci representan el tamaño de la Historia de Usuario
Cada Historia de Usuario es comparada con otras y se les asigna un número de la serie de Fibonacci que representa el tamaño más adecuadamente. Este número asignado es conocido como “Puntos de Historia” (Story Points).
Cuando nos encontramos con Historias de Usuario con asignación mayor a 8 como tamaño deberíamos dividirla antes de pasarla a un Sprint Backlog.
En una iteración (Sprint) se implementa un número determinado de “Puntos de Historia” por parte del equipo y el promedio de este número en varias iteraciones viene a ser la velocidad del equipo.
Obviamente al principio, es decir en las primeras iteraciones, la velocidad del equipo no la vamos a tener porque va a depender del desempeño del mismo en el tiempo.
Las Historias de Usuario Épicas
Suele haber casos en que una Historia de Usuario es tan grande o compleja que no se puede estimar tan solo como una definición de “Grande” o con un número Fibonacci como 13, 21, 55 o superior, en este caso es mejor no estimarla y nombrarla como épica (Epic)
Epica marca a un Historia de Usuario, como una conversación pendiente acerca de un análisis más profundo de su complejidad, fases y partes para llegar a una definición derivada de 3, 4 o muchas más Historias de Usuario que permitan su implementación.
Dividiendo las Historias de Usuario
Introducción al concepto de División (Splitting)
A menudo los equipos deben trabajar con Historias de Usuario grandes y muy grandes que no se pueden terminar en una iteración, aquí es cuando es necesario dividir esa gran Historia de Usuario en varias más pequeñas de forma que sea posible implementarlas en una iteración y que por supuesto traten de estar lo más cercano a los principio INVEST.
¿Por qué dividir la Historias de Usuario?
Una de las ventajas principales de dividir una Historia de Usuario es que las Historias de Usuario resultantes explican de mejor manera el todo y a menudo se las puede priorizar y evaluar en cuanto a qué valor aporta, así es probable que muchas de estas pierdan prioridad en el todo o no se las deba implementar realmente.
Al final esta actividad deriva en optimizar y enfocar el esfuerzo en el 20% del trabajo que tiene una alta aportación de valor, y, asignar una priorización más baja a esas stories que no aportan tanto.
La otra gran razón, como ya lo mencionamos, es que una Historia grande no se puede implementar en una iteración (1 o 2 semanas), y dividirla permite implementar parte de ella con un valor determinado en una iteración.
La idea es: algunas historias de Usuario implementadas es mejor que ninguna Historia de Usuario implementada.
La última razón más importante es que una estimación de una Historia de Usuario grande a menudo es errónea ya que no se entiende la complejidad o tamaño de la misma. Dividirla ayuda al equipo a clarificar algunos detalles que son importantes para tener una estimación real del esfuerzo, y así no dar falsas promesas.
Tener divididas las Historias de Usuario también ayuda a que estas sean testeables, y se evidencia con el cómo testear las mismas por ejemplo en ambientes e2e, ambientes mock y/o prueba unitarias solamente.
Dividiendo con simplicidad
Hazlo simple al principio y luego empieza con variaciones.
La idea es que uses primero opciones simples respecto a una solución, y luego las complejas.
Las opciones más complejas puedes escribirlas en las siguientes iteraciones pero al principio mantenlo simple.
Por ejemplo:
Historia de Usuario A: como comprador quiero poder hacer transferencias bancarias entonces puedo cancelar mi pedido.
Dividiéndola:
Historia de Usuario A-1: como comprador quiero poder hacer transferencias bancarias manuales entonces puedo cancelar mi pedido.
Historia de Usuario A-2: como comprador quiero poder hacer transferencias bancarias a través de un link de pagos de mi banco entonces puedo cancelar mi pedido.
Historia de Usuario A-3: como comprador quiero poder hacer transferencias bancarias conectando automáticamente a mi banco entonces puedo cancelar mi pedido.
Dividiendo con un Workflow
Las Historias de Usuario grandes a menudo están compuesta de pasos para ser implementadas.
Por ejemplo una Historia de Usuario como “Comprar en la Tienda en línea” involucra cosas como:
Buscar productos,
Comparar productos,
Seleccionar forma de pago,
Crear una cuenta,
Especificar dirección de entrega, etc.
Cada uno de estos pasos son en sí una Historia de Usuario por lo que una forma de muy evidente de dividir Historias de Usuario es discutir en el proceso que envuelve su cumplimiento.
Dividiendo con CRUD (Crear, Leer, Actualizar y Borrar)
Se puede dividir una Historia de Usuario pensando en las operaciones normales del registro de información: crear, leer, actualizar y borrar.
Tiene sentido si alguna de estas operaciones tiene una complejidad particular y/o son usadas por diferentes roles.
En la mayoría de casos un CRUD es una sola Historia de Usuario aunque operaciones relacionadas como búsquedas, reportes o clasificaciones pueden resultar en otras Historias de Usuario.
Dividiendo por el Método de Ingreso
Hay Historias de Usuario que involucran una entrada de información y esta entrada se puede hacer por varios canales.
Un ejemplo es la función de “añadir fotos en Word”, se puede hacer subiendo las fotos del sistema de archivos, se puede hacer referenciando a un URL, se puede hacer usando un servicio como Pexels, etc. Cada una de estos métodos de ingreso representa una Historia de Usuario en particular y forman parte de una Historia de Usuario más grande que es “añadir fotos en Word”.
Dividiendo con Spikes
Considera una Historia de Usuario en donde necesitas hacer una investigación previa de las alternativas de implementar una solución, es decir un Spike.
Por ejemplo: quieres “pagar con la integración a un Gateway de pagos”, pero no sabes cómo se integra y que necesitas.
En este caso parte de la Historia de Usuario, es esta investigación y debe ir como una Historia de Usuario, la idea es que esa Historia esté planteada con criterios de aceptación de manera que clarifiquen esas dudas que necesitan respuesta antes de la implementación de la funcionalidad.
Ojo debe hacerse un <timebox> en la investigación porque de lo contrario es muy fácil entusiasmarse en más y más investigación de alternativas y dilatar los objetivos de la Historia de Usuario.
Más acerca de Dividir las Historias de Usuario
No trates de agrandar una iteración para lograr implementar una Historia de Usuario.
No dividas las Historias de Usuario en fases: diseño, desarrollo y testing.
No partas con la mentalidad fija que una Historia de Usuario no se puede dividir, a menudo tener la mente abierta y pensar y hacer preguntas, te llevan a técnicas con las cuales llegas a dividir esa Historia de Usuario.
Retos Comunes al gestionar las Historias de Usuario
Proporcionando el Quién y el Porqué?
No olvides que especificar con precisión quién necesita la funcionalidad en una Historia de Usuario es útil para el enfoque de la solución, el equipo así sabrá quien es esa persona y cuál es su comportamiento normal.
Poner algo como “Como Usuario…” es decir genérico no ayuda al entendimiento de la necesidad.
El “Porqué” en la Historia de Usuario es extremadamente fundamental, y a veces olvidamos describirlo o detallarlo con precisión.
El “Porqué” da el contexto de la necesidad y suele llevar a preguntas adicionales que clarifican la solución.
Manejando defectos y bugs
Es normal que aparezcan de cuando en cuando defectos o mal funcionamientos en el Software, pues se considera que estos al final son parte de la solución o de la creación de la solución.
Muchos equipos tratan de resolver mágicamente estos problemas encontrando tiempo al parecer de la nada, pero hay que recordar que el equipo tiene ya una carga de trabajo asociada a las Historias de Usuario que se hayan comprometido entregar en la iteración que transcurren en ese momento.
Este enfoque es frecuentemente erróneo ya que no terminan de completar las Historias objetivo del Sprint, afectando a su velocidad y expectativas del cliente. La mejor forma es documentar estas incidencias como cualquier otra Historia de Usuario de forma que nos lleve a una conversación, a su estimación y a una definición de criterios de aceptación que expliquen cuando esta incidencia ha sido superada, y, que de igual forma se priorice en el Backlog.
Hay que recordar que hay varios tipos de incidencias, unas que a lo mejor son inhabilitantes o otras que son de forma que no tienen porque ser resueltas de manera urgente.
Lidiando con las dependencias
La mejor forma de lidiar con las dependencias es no tenerlas, y esto en un primer momento es usar prácticas o guías como INVEST que ya la conversamos anteriormente. Aquí el principio de INDEPENDENCIA es un control sobre la definición de una Historia de Usuario que marca que la misma está lista para incluirla en una iteración (Sprint Backlog).
El típico ejemplo es una story que añade funcionalidad o complementa a otra story; aquí evidentemente la story a ser modificada debe existir antes y haber sido implementada en una anterior iteración, pues si las planificamos ambas en una misma iteración vamos a tener un inevitable tiempo muerto para el equipo y por consiguiente un desperdicio de su velocidad.
Combinando Historias de Usuario
Al encontrarnos con Historias de Usuario que son dependientes podemos intentar re-enfocar las mismas de forma que esa o esas dependencias se eliminen. La práctica aquí es combinar las Historias y crear una sola gran Historia de Usuario y a partir de ella pensar en otras formas de dividirla, como por ejemplo encontrar hacerla en fases y no por segmentos de funcionalidad.
Intercambiando algunos de esos requisitos
La idea es que si tenemos dependencias entre Historias de Usuario, podemos identificar esos detalles que componen la dependencia y moverlos de una story a otra de forma que lleguen a un punto que sean independientes.
No hacer nada
Hay veces que estas dependencias no se pueden disolver, incluso aplicando los anteriores métodos.
En estos casos monitorear estas Historias de Usuario es clave para asegurar que su implementación no esté causando problemas al negocio mientras se implementan las Historias dependientes.
Cambiando las Historias de Usuario en medio de un Sprint
Hay que diferenciar el Product Backlog con el Sprint Backlog, ambas contienen Historias de Usuario pero el Sprint Backlog tiene solo aquellas Historia de Usuario priorizadas, estimadas, verificadas (con INVEST por ejemplo) y acordadas con los Stakeholders, antes de iniciar una iteración.
Una iteración (Sprint), normalmente de 2 semanas, tiene como base de trabajo estas Historias de Usuario que han pasado por un proceso y que son el compromiso del equipo. No tiene que y no debe incluirse otras stories una vez comenzada la iteración pues esto genera varios problemas al equipo como por ejemplo: afecta a su velocidad ya que existe más trabajo, afecta a la solución pues no se ha conversado los detalles previamente y afecta la planificación comprometida a los stakeholders.
Si hay una necesidad urgente de una Historia de Usuario esta debe pasar por su proceso de maduración y ser priorizada en el Product Backlog para luego ser incluida, tras el descubrimiento de detalles e implicaciones, en el Sprint Backlog.
El Sprint es un compromiso de trabajo del equipo con los stakeholders.
Retos usando estimación Ágil
Mentalidad relativa a horas
Hay que apoyar a los miembros del equipo que piensa aún en términos de horas (pues sabemos que están acostumbrados a esa referencia), y hacerlos estimar comparando esfuerzo de una story a otra.
Recuerden que la estimación se hace al tener los detalles suficientes sobre la Historia de Usuario, es decir deben haberse ejecutado esas conversaciones que la definen antes, así como tener esos criterios de aceptación.
Comparación de estimaciones entre proyectos o equipos
La estimación en agilidad es relativa a la comparación de stories, al contexto del proyecto y a la base que se haya tomado como métrica.
Por tanto, una estimación en “Puntos de historia” de una misma Historia de Usuario es diferente entre equipos pues su base o perspectiva es acordada en sus conversaciones. 21 Puntos de Historia como velocidad del equipo A puede significar más entrega de valor (funcionalidades) del Producto que 50 Puntos de Historia de velocidad del equipo B en el mismo Producto.
Incluso la velocidad de un mismo equipo puede ser diferente entre implementación de productos ya que son otros los puntos de vista y conversaciones que se acordaron en ese Producto en el equipo.
No es sano y no agrega valor comparar velocidades en ningún caso pero las estimaciones son relativas en proyectos ágiles.
Pensamientos Finales
Las Historias de Usuario son una herramienta muy utilizada en el mundo de la Agilidad, que viene en sus inicios desde el marco de trabajo «Extreme Programming (XP)«, y que ha sido adoptada por varios otros marcos como Scrum.
La idea principal es recordar que la misma provoca varias conversaciones acerca de la necesidad del cliente y se robustece en el tiempo con otra información como diagramás, flujos, documentos, etc. que maduran la necesidad y sirven como datos para una solución efectiva.
Al final esta Historia de Usuario derivará en otras más pequeñas, hasta que tengamos una Historia de Usuario de un tamaño que puede implementarse en un Sprint.
La habilidad de escribir mejores Historías de Usuario para Scrum u otro framework es un conjunto de pasos y técnicas que se interiorizan en el tiempo por el equipo y que al final les permite crear funcionalidades de valor y con entendimiento común.
Esperamos que esta guía robusta de Historías de Usuario les ayude a mejorar esta habilidad y poder entregar cada vez mejor valor a su cliente.
Equipo de SOFTWARE EVOLUTIVO, excelente artículo, mil gracias por esta información tan valiosa, ha sido de mucha utilidad para un Inception que estoy realizando en este momento. Más completo no se puede!!
Hola Leonardo excelente que bueno que sea útil, si puedes compartirlo en redes nos ayudas mucho gracias!