¿Qué es una historia de usuario?

Una historia de usuario es una descripción corta (una oración o dos), simple y específica de una interacción con un producto en desarrollo, generalmente una aplicación o un sitio web. (Por supuesto, también pueden usarse para el desarrollo de otros proyectos). Las historias de usuario se usan como marco para guiar a desarrolladores, diseñadores, gerentes de productos y otras personas involucradas en la creación de un producto.

Las historias de usuario deben definir quiénes son los usuarios y qué harán con el producto o servicio. También deben contener un tipo de usuario, la acción deseada del usuario y el valor que obtiene el usuario cuando se finaliza la acción. Sin embargo, una historia de usuario no debe describir cómo implementar o desarrollar una característica o función. 

Las historias de usuario son una parte integral de la metodología de desarrollo de software Agile. En comparación con los métodos tradicionales de gestión de proyectos (es decir, en cascada), el proceso Agile es flexible e iterativo. La metodología Agile se ejecuta en ciclos, denominados iteraciones, que duran de una a cuatro semanas. En cada iteración, los desarrolladores trabajan para crear nuevas funcionalidades o mejorar las existentes. Las historias de usuario se usan para guiar cómo crear la funcionalidad.

¿Cuál es la estructura de una historia de usuario?

No existe un formato específico para las historias de usuario Agile, por lo que existen diversas variaciones (aunque solo varían ligeramente en terminología). La forma básica de una historia de usuario toma la perspectiva de un usuario particular del producto y describe lo que quiere hacer con el producto y qué valor obtendrá al realizar esa función:

“Como determinado usuario quiero realizar determinada acción para poder hacer una determinada operación. "

A continuación, mostramos algunas historias de usuario por ejemplo para un software de seguimiento de gastos empresariales:

·       Como persona a cargo de la entrada de datos, quiero cargar hojas de cálculo, para no tener que cortar y pegar datos.

·       Como representante de ventas itinerante, quiero importar imágenes de los recibos, para no tener que llevarlos por ahí.

·       Como gerente de finanzas, quiero poder hacer cambios en las plantillas de informes de gastos de acciones, para no tener que manipular los informes todos los meses.

Si bien este es un formato simple, es bastante flexible y permite una variedad casi ilimitada." 

¿Cómo se crean las historias de usuario?

Las historias de usuario a menudo se extraen de las épicas, que a menudo tienen un formato similar al de las historias de usuario. Sin embargo, las épicas son de mayor nivel y abarcan varias funciones. (También se pueden decir como frases cortas). Las épicas son demasiado amplias para completarse en una iteración Agile, por lo que deben desglosarse.

La idea no es eliminar nada de la épica, sino crear historias de usuario lo suficientemente granulares como para completarse en una sola iteración.

¿Qué son las Épicas?

Algunas épicas de ejemplo para una aplicación de calendario pueden incluir lo siguiente:

·       Como usuario, quiero gestionar todas mis citas desde mi teléfono.

·       Como usuario, quiero ver mi calendario familiar y mi calendario de negocios juntos.

·       Como usuario, quiero tener una funcionalidad completa en el recordatorio sin abrir la aplicación.

Inicialmente, puede ser difícil distinguir entre una épica y una historia de usuario, pero se vuelve más fácil con la experiencia.

Las épicas y las historias de usuario deben basarse en las necesidades de los usuarios en lugar de en la especulación, las entrevistas con usuarios o usuarios potenciales garantizan que las historias se basarán en la realidad.

Muchas organizaciones también usan personas tipo al crear historias de usuario. Una persona tipo es una breve biografía de un usuario ficticio que ayuda a los diseñadores y desarrolladores a centrarse en un tipo de usuario específico en lugar de en un usuario general e imaginario.

Algunas organizaciones dividen las historias de usuario en historias secundarias (también llamadas subhistorias) que encajan el trabajo necesario en una sola iteración. Sin embargo, algunos creen que si una historia de usuario se puede desglosar o no encaja en una iteración, en realidad es una épica.

 
¿Quién escribe las historias de usuario?

Cualquier persona de un proyecto puede escribir historias de usuario en cualquier momento durante el proyecto. Por lo general, una sesión para escribir historias ocurre antes de la primera iteración, lo que le da al equipo del producto un “backlog” de historias a abordar.

Hay algunos marcos útiles que le ayudarán a escribir historias de usuario sólidas.  Uno de los marcos más conocidos es INVEST, llamado así por sus siglas en inglés; fue creado por el consultor y desarrollador Bill Wake:

1.    Independiente (Independent): Debe ser autocontenido (es decir., no depende de otra historia de usuario).

2.    Negociable (Negotiable): Debería haber espacio para el debate.

3.    Valioso (Valuable): La historia debe aportar valor a los participantes.

4.    Estimable (Estimable): Se puede estimar la cantidad de esfuerzo por implementar la funcionalidad de la historia.

5.    Pequeña (Small): Se debe poder completar en un solo sprint.

6.    Comprobable (Testable): La historia debe incluir suficiente detalle para permitir la creación de pruebas que  verifiquen la funcionalidad de las direcciones narrativas.

 
¿Cuáles son algunos de los beneficios de las historias de usuario?

Las historias de usuario se han vuelto populares en las metodologías Agile y otras porque aportan valor y ayudan a los equipos de desarrollo de productos a trabajar hacia el objetivo de crear una funcionalidad que satisfaga las necesidades de los usuarios. A continuación, mostramos algunos de los beneficios de las historias de usuario:

·       Son una forma sencilla de ver qué nuevas funciones y capacidades se necesitan.

·       Aclaran la funcionalidad necesaria para resolver los problemas de los clientes.

·       Son fáciles de entender y recordar.

·       Se centran en el valor del negocio y las necesidades del cliente.

·       Facilitan la priorización.

·       Se centran en cómo los clientes potenciales utilizarán el producto.

·       Pueden ahorrar tiempo, ya que hay menos inicios falsos.

·       Se pueden usar para rastrear el historial del producto mediante el seguimiento de las funciones que se agregaron en cada iteración.

·       Cambian el enfoque de escribir requisitos a hablar de ellos.

·       Pueden tener diferentes niveles de detalle.

·       Al dividir el trabajo en fragmentos, permiten flexibilidad en la implementación.

·       Las especificaciones técnicas se dejan a los desarrolladores.

·       Impulsan la colaboración y las soluciones creativas.

·       Mejoran el ROI y la moral del equipo.

 

¿Cuáles son algunos de los desafíos de las historias de usuario?

Si bien las historias de usuario son útiles, como cualquier herramienta o proceso de negocios, no son perfectas.  A continuación, mostramos algunos de los desafíos asociados:

·       No abordan los recorridos de los usuarios, el diseño visual o los requisitos técnicos.

·       Los escritores suelen descuidar la cláusula final de las historias de usuario, a pesar de que es la parte más importante del proceso.

·       Si los escritores no tienen los datos adecuados o no ahondan en los datos que tienen para satisfacer las necesidades del usuario, las historias de usuario serán débiles.

·       No comprender completamente a los usuarios dará lugar a historias que no abordan sus necesidades reales.

·       Si los equipos de productos no tienen la experiencia adecuada, las historias de usuario no serán efectivas para responder a las necesidades de los usuarios.

¿Cómo se implementan las historias de usuario?

Las historias de usuario son un punto de partida para el debate en equipo. Este debate debe generar más detalles y algunas ideas específicas sobre cómo implementar la función descrita para que sea valiosa para el usuario. Si ha creado personas tipo, es útil usarlas durante estas conversaciones para mantener el enfoque centrado en el usuario.

Durante la discusión, las historias de usuario pueden mostrarse en un lienzo del producto, junto con personas tipo, épicas y otros elementos relacionados, a través de una herramienta como StoriesOnBoard o FeatureMap. Algunos equipos también crearán prototipos de baja resolución para permitir, a continuación, recorrer la funcionalidad que proporcionará una solución al problema abordado por la historia de usuario.

Una vez que se han creado y analizado las historias de usuario, deben asignarse. La asignación es un proceso en que se establece una cuadrícula de las historias de usuario en grupos lógicos relacionados con una característica o una función o tareas que los usuarios completan. Cada grupo puede llamarse un tema. Hay muchas maneras de asignar historias de usuario, como escribirlas en notas adhesivas y ponerlas en un muro o tener una caja llena de fichas y difundirlas en una tabla.

Como se mencionó anteriormente, las historias de usuario se recopilan en un backlog. El backlog es una lista con prioridades de la funcionalidad que se creará para el producto. El propietario del producto es responsable de garantizar que haya suficientes historias de usuario en el backlog para cada iteración. Si bien algunas organizaciones usan otros elementos en su backlog, las historias de usuario son el elemento más popular.

En la gestión de proyectos en cascada, un documento de requisitos describe qué características y funciones se incluirán en el producto final. Si bien las historias de usuario no son requisitos verdaderos, en la gestión de proyectos Agile, el backlog tiene un propósito similar al del documento de requisitos.

Debido a su estructura, un backlog en Agile es mucho más fluido que el de un documento de requisitos en cascada. Las historias del backlog deben tener identificadores únicos para facilitar la trazabilidad desde el origen de la historia (por ejemplo, un informe de error, entrevistas a usuarios, un ticket de soporte o la sugerencia de un desarrollador) a través de su desarrollo, pruebas y lanzamiento. Las herramientas comunes para dar seguimiento a las historias hasta el lanzamiento incluyen JIRA, GitHub, etc  o incluso una hoja de cálculo de Excel.

Después de que un equipo acuerde las historias iniciales, debe reunirse para elaborar el resto de la información necesaria para el desarrollo, las pruebas y otros pasos del proceso. También debe priorizar qué funcionalidad se describe en las historias de usuario que se desarrollarán primero. Y de nuevo, debido a la estructura de la metodología Agile, la priorización es fluida y cambiará en respuesta a las nuevas necesidades de los usuarios, nuevas historias de usuario y nuevas presiones competitivas.

¿Cómo saber cuándo una historia de usuario está lista?

Para cualquier historia, necesita una forma de verificar que la funcionalidad deseada se ha implementado correctamente. Hay algunas frases que se utilizan para describir esto, a saber, criterios de aceptación y condiciones de satisfacción. Algunos expertos dicen que estos dos términos son sinónimos; otros creen que las condiciones de satisfacción son más altas que los criterios de aceptación, y que los detalles de los criterios de aceptación se utilizan para verificar que se cumplen las condiciones de satisfacción.

¿Quién usa las historias de usuario?

Todo un equipo que utiliza la metodología Agile puede usar historias de usuario para su trabajo en un proyecto, pero aquí hay una lista de los miembros clave del equipo:

·       Propietarios de producto: garantizan la entrega de un producto que satisfaga las necesidades del usuario.

·       Desarrolladores: guían el trabajo del equipo.

·       Testers: verifican que el producto funcione según lo esperado.

·       Escritores técnicos: se aseguran de que cualquier material de soporte cubra casos de uso importantes.

Con la excepción de los desarrolladores, cada una de estas personas puede actuar como representante del cliente, situándose en el rol de un cliente o usuario.