Historias de usuario con ejemplos y plantilla

Las historias de usuario son tareas de desarrollo que se suelen expresar como "persona + necesidad + propósito".

Max Rehkopf Max Rehkopf
Buscar temas

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 contextualizar 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.

¿Qué son las historias de usuario ágiles?

Una historia de usuario es la unidad de trabajo más pequeña de un marco ágil. Es un objetivo final, no una función, expresado desde la perspectiva del usuario del software.

El propósito de una historia de usuario es articular cómo entregará un trabajo específico un valor particular al cliente. Ten en cuenta que los "clientes" no tienen que 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. 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 scrum, las historias de los usuario se añaden a los sprints y se "queman" a lo largo del sprint. Los equipos kanban introducen las historias de usuario en su backlog y las hacen avanzar a través de 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, del inglés "work in progress") 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 cuerpos 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 (las historias) contribuya a los objetivos organizacionales incorporados en los epics y las iniciativas.

Más información sobre los epics e iniciativas

Épicas frente a historias y frente a temas ágiles | Orientador ágil de Atlassian

¿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 añadido. ¿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.

Los relatos de los usuarios aportan una serie de beneficios clave:

  • Las historias mantienen el foco en el usuario. Una lista de tareas pendientes mantiene al equipo centrado en las tareas que necesitan ser marcadas, pero una colección de historias mantiene al equipo centrado en la resolución de problemas para usuarios reales.
  • Las historias permiten la colaboración. Con el objetivo final definido, el equipo puede trabajar en conjunto para decidir cuál es la mejor manera de servir al usuario y alcanzar ese objetivo.
  • Las historias impulsan soluciones creativas. Las historias animan al equipo a pensar de manera crítica y creativa sobre la mejor manera de resolver un objetivo final.
  • Las historias crean impulso. Con cada historia que pasa, el equipo de desarrollo disfruta de un pequeño desafío y una pequeña victoria, lo que fomenta el impulso.

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 de producto o el gestor de 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 póquer de planificación 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

Ten en cuenta lo siguiente al escribir historias de usuario:

  • Definición de "Hecho": La historia se suele considerar "hecha" cuando el usuario puede completar la tarea designada, pero asegúrate de definirla.
     
  • Designa las subtareas o tareas: decide cuáles son los pasos específicos que deben completarse y quién es el responsable de cada uno de ellos.
     
  • Perfiles de usuario: ¿para quién? Si hay varios usuarios finales, piensa en crear varias historias.
     
  • Pasos en orden: escribe una historia para cada paso de un proceso más amplio.
     
  • Ten en cuenta los comentarios: habla con tus usuarios y detecta cuál es el problema o la necesidad según su perspectiva. No hay necesidad de adivinar las historias cuando puedes obtenerlas de tus clientes.
     
  • Tiempo: el tiempo es un asunto delicado. Muchos equipos de desarrollo evitan hablar del tiempo, y confían en sus marcos de estimaciones. Como las historias deben poder completarse en un sprint, las historias que pueden tardar semanas o meses en completarse, deberán dividirse en historias más pequeñas o deberán considerarse su propio epic.
     

Una vez que se han definido claramente las historias de usuario, asegúrate de que sean visibles para todo el equipo.

Plantilla y ejemplos de historias de usuario

Las historias de usuario suelen expresarse en una sencilla frase, y estructurarse de la siguiente manera:

"Como [perfil], yo [quiero], [para que]."

Al desglosar esta idea: 

  • "Como [perfil]": ¿para quién lo estamos creando? No solo buscamos un cargo, sino que buscamos el perfil de una persona. Max. Todos los miembros del equipo deben comprender quién es Max. Es muy probable que hayamos entrevistado a muchos Max. Entendemos cómo trabaja esa persona, cómo piensa y cómo se siente. Tenemos empatía hacia Max.
  • "Quiere": aquí describimos cuál es su intención, y no las funciones que utiliza. ¿Qué es lo que intenta conseguir realmente? Esta afirmación no debería estar condicionada por ningún aspecto relativo a la implementación; si estás describiendo cualquier parte de la interfaz de usuario y no el objetivo del usuario, es que no has entendido de lo que se trata.
  • "Para que": ¿cómo se adapta su deseo inmediato de hacer algo al conjunto global? ¿cuál es la ventaja general que está intentando conseguir? ¿cuál es el gran problema que necesita resolverse?

Por ejemplo, las historias de usuario pueden parecerse a esto:

  • Como Max, quiero invitar a mis amigos para que podamos disfrutar de este evento juntos.
  • Como Sascha, quiero organizar mi trabajo para que pueda sentir que lo tengo todo controlado. 
  • Como gestor, quiero poder comprender el progreso de mis compañeros para poder informar mejor de nuestros éxitos y fracasos. 

Esta estructura no es obligatoria, pero resulta útil para definir el concepto de que algo está hecho. Cuando ese perfil puede capturar el valor deseado, la historia está completa. Animamos a los equipos a definir su propia estructura y a ceñirse a ella.

Introducción a las historias de usuario ágiles

Las historias de usuario describen el por qué y el qué hay detrás del trabajo diario de los miembros del equipo de desarrollo, a menudo expresado como perfil + necesidad + propósito. Entender su papel como fuente de verdad para lo que tu equipo está entregando, pero también el por qué, es clave para que el proceso se desarrolle correctamente.

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 perfilarlo mejor. Una vez que expongas tus historias donde todo el equipo pueda verlas, estarás listo para empezar a trabajar.

A continuación
Estimation