Mejores prácticas para escribir historias de usuarios ágiles

Historias de usuario definidas

Whitney es una directora de proyectos con experiencia que ha estado utilizando Agile durante años. Ha sido contratada en una empresa para ayudar al equipo del proyecto en la transición a Agile. Una de las primeras cosas que hace es capacitar al equipo de desarrollo y a las partes interesadas sobre las historias de los usuarios. Si bien Agile tiene varios componentes, es la creación y finalización de historias de usuario lo que impulsa los proyectos. Decide comenzar con lo básico: ¿qué es una historia de usuario y de dónde vienen?

Una historia de usuario describe la funcionalidad para un individuo o usuario específico. También describe lo que logra esa funcionalidad. Las historias de usuario responden preguntas como quién, qué y por qué, pero no responden cómo. La intención es generar discusión y colaboración sobre la funcionalidad, en lugar de dictar cómo debe crearse.

Las historias de usuario suelen ser escritas por el propietario del producto , que es el único que toma las decisiones sobre los requisitos y la dirección del proyecto. Incluso si otras personas, como las partes interesadas o los miembros del equipo de desarrollo, escriben historias de usuarios, el propietario del producto determina si la funcionalidad es necesaria. Además, el propietario del producto da prioridad a las historias de los usuarios en una colección denominada backlog del producto . La mayoría de las historias de usuarios se escriben alrededor del comienzo de un proyecto, pero esto no es una regla. También se pueden escribir durante el proyecto.

Estructura de la historia de usuario

Una vez que Whitney ayuda a su equipo a comprender qué es una historia de usuario y de dónde proviene, pasa a describir su estructura. Cuando se trabaja en diferentes requisitos dentro de proyectos, así como en diferentes proyectos, es importante que las historias de usuario tengan una estructura coherente. Esto ayuda al equipo a concentrarse en comprender la funcionalidad deseada, la razón detrás de ella y para quién se desea.

La estructura más común para una historia de usuario nombra al usuario, la funcionalidad y el motivo. A menudo se escriben en el siguiente formato: “Como <tipo de usuario>, quiero <funcionalidad> para esta <razón>”. Por ejemplo, en un proyecto para crear un sitio web para un banco, una historia de usuario podría ser: “Como titular de una cuenta, quiero ver el historial de transacciones para poder rastrear los fondos en mi cuenta”. La atención se centra en el usuario final y el resultado final junto con el propósito.

Además del requisito de alto nivel proporcionado en la estructura de usuario / funcionalidad / motivo, las historias de usuario también contienen requisitos de bajo nivel. Los requisitos de bajo nivel proporcionados en una historia de usuario se denominan criterios de aceptación o condiciones de satisfacción . Los criterios de aceptación enumeran acciones y resultados específicos que demuestran la funcionalidad de la historia del usuario. Un ejemplo es, ‘Cuando deposito dinero, veo el débito de la cuenta’. Cada criterio de aceptación debe cumplirse antes de que el propietario del producto acepte la historia del usuario como completa. Es por eso que los criterios de aceptación también se conocen como la definición de hecho.

Cualidades de una buena historia de usuario

A medida que el equipo de Whitney comprende cómo escribir historias de usuarios, ella se asegura de que sepan que se necesita más que estructura. Otras cualidades de la historia del usuario son igualmente importantes. Para ayudarlos a recordar estas cualidades, Whitney les enseña un dispositivo mnemónico INVEST , que fue creado por Bill Wake. INVEST es sinónimo de independiente, negociable, valioso, estimable, pequeño y comprobable.

Las dos primeras cualidades, independientes y negociables, están relacionadas con la forma en que el equipo de desarrollo se relaciona con las historias de los usuarios. Independiente significa que la historia de usuario no se superpone con otra y no es necesario trabajar en ella junto con otras historias de usuario. Esto permite que el equipo de desarrollo ordene las historias de los usuarios de la forma que tenga más sentido. Negociable se refiere a la flexibilidad para que se puedan cambiar los detalles. Es por eso que el cómo no está en la historia del usuario.

La siguiente cualidad, valiosa, significa que la funcionalidad que se está creando debería proporcionar un beneficio al usuario final. Esto es importante tanto para el propietario del producto como para el equipo de desarrollo. El propietario del producto solo debe centrarse en proyectos que brinden valor al usuario final. Desde la perspectiva del equipo de desarrollo, no vale la pena trabajar a menos que tenga un propósito. Las historias de usuario valiosas ayudan al equipo a invertir por igual como propietario del producto.

Las cualidades restantes, estimables, pequeñas y comprobables, son los aspectos prácticos de una buena historia de usuario. Estimable significa que el equipo de desarrollo puede comprender fácilmente la historia del usuario y se puede cuantificar el esfuerzo para completarla. Las historias de usuario pequeñas se pueden completar en un sprint , que es el ciclo en Agile en el que se realiza, completa y revisa el trabajo que generalmente dura de 2 a 4 semanas. Esto incluye el desarrollo y las pruebas, lo que conduce a la calidad final; comprobable. Esto se relaciona principalmente con los criterios de aceptación, donde los resultados esperados son tangibles y pueden verificarse.

Completar historias de usuarios

La consideración final para Whitney y su equipo es saber cuándo las historias de usuario pueden considerarse completas y cuándo pueden iniciarse nuevas historias de usuarios. Las historias de usuario son revisadas por el propietario del producto, las partes interesadas y el equipo de desarrollo en una reunión llamada revisión de sprint . Aquí es donde el equipo de desarrollo demuestra los resultados tangibles de las historias de usuario comparadas con los criterios de aceptación. Si se cumplen todos los criterios de aceptación, se aprueba la historia del usuario.

Si se realizan solicitudes de cambio, se incorporan a una nueva historia de usuario. Una vez que una historia de usuario se lleva a un sprint, no debería cambiar. La pregunta de cómo se debe lograr es flexible, pero el usuario y la funcionalidad específica deben ser firmes.

Resumen de la lección

Una historia de usuario detalla la funcionalidad deseada para un usuario específico y el propósito de la funcionalidad. Están redactados principalmente por el propietario del producto y se compilan en una cartera de productos priorizada . Las historias de usuario generalmente se escriben en un formato de ‘Como <tipo de usuario>, quiero <funcionalidad> por <razón>’ e incluye criterios de aceptación que brindan acciones específicas y resultados esperados. Las cualidades de una buena historia de usuario se pueden recordar con INVEST , mnemónico, que incluye ser independiente, negociable, valioso, estimable, pequeño y comprobable. El propietario del producto considera que las historias de usuario están completasdespués de que el equipo de desarrollo demuestre que se cumplen todos los criterios de aceptación durante la revisión del sprint .