¿Qué es una historia de usuario y qué no es?
Las historias de usuario surgieron como resultado de la programación extrema (XP), Kanban y la necesidad de Scrum de dividir los proyectos en segmentos más pequeños e incrementales para sprints e iteraciones. Se diferencian de los casos de uso en que se centran en la unidad de trabajo más pequeña posible. Los casos de uso, introducidos originalmente por Ivar Jacobson, pueden estar compuestos por varias historias basadas en un tema común. Las historias en sí mismas son narrativas simples que esbozan una única expectativa u objetivo del usuario. Puede desglosar la creación de una historia de usuario en tres etapas:
- Describir la necesidad.
- Planificar la iteración.
- Implementar y pruebar la finalización de la historia.
En cada etapa, la historia del usuario se puede refinar a la perfección.
Las historias de usuario no contienen una lista de requisitos o instrucciones de codificación, pero se asociarán a criterios o pruebas de aceptación. Sin embargo, el objetivo de una historia de usuario no es centrarse en cómo construir. En cambio, el enfoque está en quién quiere la función, qué hará y por qué es importante. Las historias aportan un elemento humano a las características que eventualmente conforman la lista de tareas pendientes de la actividad atrasada.
¿Por qué son importantes las historias de usuario?
Más que una simple lista de características, las historias llevan al usuario a la conversación. Las historias de usuario proporcionan contexto al desarrollo de software centrándose en el valor que experimentará el usuario. Este proceso centrado en las personas silencia el lenguaje de Agile, lo que permite a los no desarrolladores colaborar y participar en conversaciones.
Las historias de usuario ayudan a facilitar el diálogo constante en todo el proyecto de desarrollo de TI para ayudar en áreas como laplanificación de iteraciones/sprint y la priorización de la actividad pendiente de una publicación. En cambio, el desarrollo tradicional en cascada adopta el diálogo al principio y al final del proceso de desarrollo.
En su libro Historias de usuario aplicadas para Agile Software, Mike Cohn de Mountain Goat Software dice lo siguiente: "Tomamos decisiones en función de la información que tenemos en cuestión y lo hacemos con frecuencia. En lugar de tomar un conjunto integral de decisiones al comienzo de un proyecto, distribuimos la toma de decisiones a lo largo de la duración del proyecto. Para hacer esto, nos aseguramos de tener un proceso que nos brinde información lo antes posible y con la mayor frecuencia posible. Y aquí es donde entran las historias de usuario".
¿Quién escribe la historia de usuario?
Los propietarios de productos, las partes interesadas, los gerentes de productos y otros miembros del equipo de negocios participan en la redacción de historias de usuario. Muchos dirán; sin embargo, que quien las escribe es menos importante que quien participa en los debates y conversaciones que dan vida a las historias. Empiece por identificar quién utilizará la función (la persona), que puede ser tan detallada como sea necesario. El usuario puede definirse en términos de función o descripción del trabajo, como estudiante, viajero frecuentes o gerente de marketing.
Tener una comprensión sólida del usuario final limita los sesgos o suposiciones del desarrollador. Si los usuarios están disponibles, pueden participar, pero a menudo el equipo tiene diseñadores, gerentes, escritores y otros que actúan como representantes del cliente. Los participantes pueden variar en función del uso de la historia de usuario. Por ejemplo:
- Creación de historias de usuario: Los participantes pueden incluir clientes, gestión de productos, ingeniería y otras partes interesadas, como RR. HH., finanzas y ventas.
- Mantenimiento de historias de usuario: Los participantes incluyen la gestión de productos o el propietario del producto.
- Aplicación y uso de la historia de usuario: Los participantes incluyen ingenieros/desarrolladores, escritores técnicos y evaluadores de garantía de calidad.
Cómo escribir historias de usuario efectivas
Las historias de usuario son simples y únicas declaraciones de beneficios de una función valiosa. Antes de escribir la historia de usuario, realice encuestas y entrevistas de usuarios para consultar al usuario sobre la funcionalidad necesaria. Comience escribiendo un recorrido del cliente, expresado en historias incrementales, en tarjetas de 3x5 pulgadas o notas Post-it. Estas tarjetas pueden ponerse inmediatamente en producción o proporcionar contexto para la actividad atrasada.
En caso de asignación de historias de usuario, puede mostrar notas post-it a lo largo de una pared en la sala de conferencias para que todo el equipo pueda verlo y trabajar en la planificación a largo plazo.
Hay algunas técnicas que puede usar para ayudar a escribir las historias que necesita. Una técnica común es la estructura Rol-Característica-Razón o Beneficio (RGB) que se construye rellenando los espacios en blanco de esta oración:
- Como (usuario/persona/cliente), quiero (hacer algo) para que yo (reciba un beneficio).
Agregando a la pregunta RGB hay un método que inició Ron Jeffries que destaca su "enfoque de tres C"
- Tarjeta: Escriba la respuesta al RGB (descrita anteriormente) en la tarjeta.
- Conversación: El detalle limitado de la tarjeta es la base de una promesa cumplida por la segunda C. Durante esta fase, el equipo analiza los detalles y establece una definición de "hecho".
- Confirmación: Este es el resultado de los comentarios que determinan los criterios de prueba o aceptación. Este criterio de aceptación a menudo se escribe en la parte posterior de la tarjeta y se utiliza como la lista de verificación inicial durante futuras reuniones para determinar la finalización.
En un artículo de Bill Wake en 2003 y popularizado por el libro de Mike Cohn, Historias de usuario aplicadas para el desarrollo de software Agile, el acrónimo INVEST es un método para evaluar las historias de usuario. Los criterios INVEST son los siguientes:
- Independencia para desarrollar en cualquier secuencia.
- Capacidad de negociar el alcance de la historia para desarrollarse.
- Proporciona valor al usuario o al negocio.
- Se puede estimar para su finalización.
- Es lo suficientemente pequeño como para diseñar, codificar y probar en una sola iteración.
- Y, por último, se puede probar.
Escribir historias de usuario que siguen los métodos RGB y tres C son buenos puntos de partida. Evaluar la efectividad en función de los objetivos INVEST mantiene historias pequeñas, funcionales y pruebables.
Bennett Lauber, Chief Experience Officer with The Usability People, LLC, makes the following suggestions for someone preparing to write their first user story: “Make sure you do some research on your users and create personas. This will help the development team have empathy with the user.”
Plantilla de historia de usuario Agile
¿Listo para escribir una historia de usuario? Descargue una plantilla gratuita que lo ayude a definir claramente la función desde la perspectiva del usuario final. La plantilla incluye espacio para el tipo de usuario, lo que quiere y por qué lo quiere. Al crear estas historias de usuario cortas y únicas, el equipo de desarrollo puede desarrollar código que satisfaga los requisitos de la historia de usuario. Encuentre otras plantillas útiles de Agile que puede descargar aquí.
Descargar plantilla de historia de usuario Agile
Cómo escribir un caso de prueba a partir de una historia de usuario
Una historia de usuario proporciona las instrucciones para desarrollar pruebas o criterios de aceptación. Esta lista de verificación ayuda a los desarrolladores a determinar cuándo se realiza la función. Al igual que con todos los elementos de las historias de usuario, los criterios de aceptación también se escriben desde el punto de vista del usuario. Los criterios de prueba o aceptación describen los elementos necesarios para realizar con éxito la función requerida.
Estos criterios deben incluir lo siguiente:
- Los requisitos funcionales y no funcionales previstos
- Escenarios negativos de la funcionalidad
- Pautas de desempeño
- Flujo de trabajo adecuado para los usuarios
- Impacto en otras funciones
- Experiencia del usuario
Thomas Stiehm, CTO at Coveros, writes test cases using Gherkin Language. “This is the given, when, then (GWT) format,” he says. “I use test automation in Cucumber and that consumes Gherkin for automated testing. In addition, involving an experienced tester helps create better stories. They can ask important functionality questions while the story is being developed, which in turn results in more usable functionality.”
Utilicemos un registro de conferencias como caso de prueba de ejemplo: Un usuario envía un formulario que incluye su información de contacto, elige una opción de pago y se muestra una confirmación en la pantalla y se envía por correo electrónico. Estos se convierten en parte de la lista de aceptación. El caso de prueba también considera la facilidad y el flujo de la experiencia del usuario (UX). Al igual que la historia de usuario en sí, la cantidad de detalles probados refleja solo lo necesario para garantizar que la función ofrezca valor.
Hernan Santiesteban, of Great Lakes Web, shares his advice. “One of the best ways to write a test case is to use the given, when, then template, which establishes test conditions, user actions, and expected outcome. For example: given an administrative user signs in successfully, when the admin opens the user dashboard, then the admin will be presented with user management functions.”
Beneficios de escribir historias de usuario sólidas
Para algunos gerentes de producto y miembros del equipo de desarrollo, escribir historias de usuario en lugar de listas de requisitos puede parecer como agregar más pasos al proceso de Agile. Sin embargo, un beneficio clave de las historias de usuario es que dependen de la colaboración y mantienen a todos informados y en la misma página. Las cosas pueden cambiar durante los procesos de desarrollo mediante comentarios de descubrimientos y partes interesadas, como resultado, las historias de usuario pueden cambiar o adaptarse a estas circunstancias.
Algunos de los beneficios más comunes incluyen los siguientes:
- Demuestre el progreso rápidamente dividiendo el panorama general en proyectos más pequeños.
- Motivar al equipo y mantener el proyecto avanzando con éxitos rápidos.
- Ponga en primer lugar a los usuarios finales y, por lo tanto, fomente una mayor aceptación y satisfacción del usuario.
- Priorice las funciones de alto valor.
- Proporcione la plataforma para tener conversaciones colaborativas que permitan planificar soluciones creativas.
- Fomente altos niveles de cooperación que mantengan al equipo centrado en los resultados que, a su vez, crean mejores productos generales.
Cómo escribir una buena historia de usuario
Parece contrario a la intuición que el desarrollo de grandes iniciativas de software goce de éxito y eficiencia siguiendo la vieja escuela. Las tarjetas simples de 3x5 de diferentes colores y un marcador permanentes proporcionan la base intuitiva para la autoría de historias de usuario que aportan contexto a un proceso de desarrollo de Agile. Las pequeñas tarjetas fomentan las descripciones básicas basadas en beneficios que se descubren a través de la colaboración en equipo.
Todas las historias de usuario son únicas y deben complementarse con mapas de historias, diagramas, guiones gráficos y maquetas, pero a continuación se indican algunas prácticas recomendadas que pueden ayudarle a redactar una historia de usuario eficaz:
- Conozca a su usuario: Defina y comprenda a sus usuarios.
- Incluya a todas las partes interesadas: Asegúrese de incluir a todas las partes interesadas relevantes en el proceso de redacción de historias de usuario. El equipo de pruebas puede incluso perfeccionar la historia.
- Céntrese en el usuario: Los debates y las conversaciones desde la perspectiva del usuario proporcionan contexto y una definición de lo que constituye "hecho".
- Sea breve y sencillo: Describa una única funcionalidad en cada historia de usuario. Si una historia es demasiado extensa para desarrollarla en poco tiempo, divídala en incrementos más pequeños o cree condiciones específicas que limiten la función. Una buena regla general es que una historia de usuario debe ser lo suficientemente corta como para que el equipo de desarrollo pueda completarla en una iteración.
- Debata y colabore: Los debates sobre el tamaño del proyecto, el producto mínimo viable (PMV), quién lo utilizará, qué hará y por qué aporta valor ayudan a tomar decisiones sobre su inclusión y alcance.
- Evite los detalles técnicos: No escriba tareas técnicas o frases del tipo "cómo construir" en las historias de usuario, ya que pueden impedir la creatividad y la colaboración. Los detalles técnicos vendrán más adelante en el proceso y se incorporarán los desarrolladores, evaluadores y arquitectos de sistemas. Una plantilla puede ayudar a guiar a distancia de los detalles técnicos.
- Céntrese en los 3 interrogantes: Quién la utilizará, qué es y por qué es importante.
- Fomente la visualización: Utilice los métodos (dibujos, historias y mapas de impacto, guiones gráficos y maquetas o prototipos) que sean adecuados para visualizar el producto terminado.
- Aclarar el valor y el beneficio: Asegúrese de que el propósito de la historia sea claro, se señala la urgencia y se completa la historia.
Desafíos y obstáculos comunes de escribir historias de usuario
Una historia de usuario responde preguntas como quién utilizará la función, qué hará la función y por qué es importante. Los detalles de la historia proporcionan el contexto empresarial, el valor del usuario e impulsan las conversaciones del equipo. Un desafío común al escribir historias de usuario es garantizar que la historia sea lo suficientemente completa como para articular el valor, pero lo suficientemente simple como para entregarla en un corto período de tiempo, como un sprint (que suele ser de entre una y cuatro semanas). La historia no debe contener detalles técnicos de cómo se construirán o codificarán instrucciones. Estos detalles no son necesarios en este punto de desarrollo.
Si una historia es demasiado grande o demasiado amplia, puede dividirse en partes pequeñas.
A continuación, le presentamos un buen ejemplo:
- Como cliente bancario, quiero poder ver mi saldo, para que pueda planificar los pagos de facturas.
Puede ser tentador agregar más detalles u otras funciones, pero eso creará una narrativa difícil de manejar. Este tipo de historia sería algo así:
- Como gerente de ventas, quiero obtener mi previsión, ventas e informes de personal, para que pueda establecer mi presupuesto para todo un año.
Este ejemplo tiene varios componentes (generar informes individuales: previsión, ventas y personal) que deben dividirse en varias historias de usuario más pequeñas.
Además, asegúrese de incluir criterios de aceptación, que identifican lo que constituye "hecho". Como se ha mencionado anteriormente, los criterios de aceptación a menudo se escriben como una lista de verificación en la parte posterior de la tarjeta de historia de usuario.
Los desafíos adicionales al escribir criterios de aceptación incluyen los siguientes:
- La tendencia natural a centrarse en cómo construir. Sin embargo, dejar este detalle técnico fuera del diálogo impulsa conversaciones más significativas que conducen a soluciones creativas, y también permite la inclusión de usuarios y miembros del equipo no técnicos en las discusiones.
- El diálogo y las conversaciones pueden llevar mucho tiempo y a menudo se olvidan, lo que limita el impacto positivo de las historias de usuario.
- La falta de datos o una comprensión real del usuario o persona pone en peligro la aceptación de la funcionalidad cuando se ponga en manos del usuario final.
- Limitar las historias al mínimo incremento no es fácil, pero un exceso de detalles hace que la historia de usuario resulte difícil de manejar.
- Dejar fuera la información esencial, como los criterios de aceptación o los beneficios del cliente, puede dejar preguntas sin respuesta durante el proceso de desarrollo.
El libro Historias de usuario de Mike Cohn Aplicadas para Agile Software identifica el problema central en el desarrollo de software con esta sencilla observación: "Los requisitos de software son un problema de comunicación".
El lenguaje técnico asociado al desarrollo de software y las metodologías Agile pueden ser un obstáculo para muchos. A lo largo del proceso de desarrollo, la escritura de historias de usuario incorpora diálogos y conversaciones abiertas, desglosando las tareas para mantener el impulso fluyendo y proporcionando definiciones sólidas de hecho. Crear software es un proceso a gran escala y que requiere mucho tiempo con muchas partes interesadas y altas expectativas. Sin embargo, al seguir algunas pautas simples y algunas técnicas a la antigua, las complejidades del desarrollo de software se vuelven más visibles para todo un equipo y, al final, más fáciles de hacer.
Domine la redacción de historias de usuario con Smartsheet para el desarrollo de software
Empodere a sus empleados para que vayan más allá gracias a una plataforma flexible, diseñada para satisfacer las necesidades de su equipo y capaz de adaptarse cuando esas necesidades cambien. La plataforma Smartsheet facilita la planificación, la captura, la gestión y la creación de informes sobre el trabajo, desde cualquier lugar, lo que ayuda a su equipo a ser más eficiente y lograr más. Cree informes sobre las métricas claves y obtenga visibilidad en tiempo real acerca del trabajo en curso gracias a informes, paneles y flujos de trabajo automatizados diseñados para ayudar a su equipo a mantenerse conectado e informado. Cuando los equipos tienen claridad sobre el trabajo en curso, pueden lograr mucho más en el mismo tiempo. Pruebe Smartsheet gratis hoy mismo.