Historias de usuario con ejemplos y plantilla

Resumen: una historia de usuario es una explicación general e informal de una función de software escrita desde la perspectiva del usuario final. Su propósito es articular cómo proporcionará una función de software valor al cliente.

Es tentador pensar que las historias de usuario son, en pocas palabras, requisitos del sistema de software. Pero no lo son.

Un componente clave del desarrollo de software ágil es poner a las personas en primer lugar, y las historias de usuarios ponen a los usuarios finales reales en el centro de la conversación. Las historias utilizan un lenguaje no técnico para ofrecer contexto al equipo de desarrollo y sus esfuerzos. Después de leer una historia de usuario, el equipo sabe por qué está compilando lo que está compilando y qué valor crea.

Las historias de usuario son uno de los componentes centrales de un programa ágil. Ayudan a proporcionar un marco centrado en el usuario para el trabajo diario, lo que impulsa la colaboración y la creatividad y mejora el producto en general.

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 van realizando a lo largo del sprint. Los equipos de kanban incorporan 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 de sprints, 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.

Más información sobre epics e iniciativas

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 (el 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.

Descubre cómo funcionan las historias de usuario en Jira Software

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.

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.

Las historias de usuario suelen expresarse con una frase simple con la siguiente estructura:

“Como [perfil], [quiero] [para].”

Desglosemos esta estructura:

• “Como [perfil]”: ¿para quién desarrollamos esto? No solo buscamos un puesto, buscamos el perfil de la persona. Max. Nuestro equipo debería comprender quién es Max. Con suerte hemos entrevistado a muchos Max. Comprendemos cómo trabaja esa persona, cómo piensa y cómo se siente. Sentimos empatía por Max.
• “Quiere”: aquí describimos su intención, no las funciones que usan. ¿Qué es lo que están intentando lograr realmente? Esta descripción debería realizarse con independencia de las implementaciones; si describes algún elemento de la IU y no el objetivo del usuario, estás cometiendo un error.
• “Para”: ¿cómo encaja su deseo inmediato de hacer algo en la perspectiva general? ¿Cuál es el beneficio general que intentan lograr? ¿Cuál es el gran problema que debe resolverse?

Por ejemplo, las historias de usuario pueden tener este aspecto:

• Como Max, quiero invitar a mis amigos, para que podamos disfrutar de este servicio juntos.
• Como Sascha, quiero organizar mi trabajo, para poder sentir que tengo un mayor control.
• Como gestor, quiero poder comprender el progreso de mis compañeros, para poder informar sobre nuestros éxitos y fallos.

Esta estructura no es obligatoria, pero resulta de ayuda para establecer una definición de "hecho". Cuando ese perfil puede alcanzar su valor deseado, la historia está completa. Recomendamos a nuestros equipos definir su propia estructura, y que no se desvíen de ella.

Las historias de los usuarios describen el por qué y el qué que hay detrás del trabajo diario de los miembros del equipo de desarrollo; a menudo las historias de usuario se expresan de la siguiente manera: perfil + necesidad + propósito. Entender su papel como fuente de verdad para lo que el equipo está entregando, pero también el por qué, es clave para un proceso sin problemas.

Empieza por evaluar el siguiente gran proyecto o el más apremiante (por ejemplo, un epic). Divídelo en historias de usuario más pequeñas y trabaja con el equipo de desarrollo para mejorarlo. Una vez que tus historias están fuera, donde todo el equipo puede verlas, ya tienes todo listo para empezar a trabajar.