Construir una historia de usuario

Objetivos de aprendizaje

Después de completar esta unidad, podrá:

Destacar la importancia de establecer criterios de aceptación.
Resumir el concepto de INVEST para redactar una historia de usuario.
Identificar errores comunes que se deben evitar al redactar una historia de usuario.

Equipo de proyecto: ¡Reunión!

Se recomienda realizar un taller de redacción de historias de usuarios cerca del inicio de un proyecto. Los talleres de redacción de historias se organizan para incluir al equipo de proyecto: gerentes de proyecto, desarrolladores, administradores, diseñadores de UX, usuarios, etc. Los participantes proponen ideas para generar historias. A medida que se desarrollan las historias de usuarios, se debe implicar la creatividad de todo el equipo. Estas historias de usuarios iniciales no se escriben en piedra. Su encanto reside en la capacidad de fomentar el desarrollo repetitivo y ser ajustadas tantas veces como sea necesario.

Al formular historias de usuarios con su equipo de proyecto, no realice conjeturas sobre la forma en que se implementarán las historias, como los componentes o servicios que se verán afectados. El equipo de desarrollo/implementación toma esas decisiones durante las reuniones de planificación.

Aceptar la necesidad de criterios

Es natural que, cuando se reúne un grupo de proyecto, el mismo problema sea visto desde diferentes ángulos. Estas diferentes perspectivas son sumamente necesarias y útiles, pero pueden ser desesperantes si no existe una medida de éxito acordada, también conocida como criterios de aceptación. Los criterios de aceptación son un conjunto de declaraciones, cada una con un resultado de aprobación/error, que se agrega a una historia de usuario. Dicho sencillamente, los criterios de aceptación especifican las condiciones en las cuales se completa una historia de usuario. Se deben expresar de manera clara, en un lenguaje simple, sin ambigüedades acerca del resultado esperado. Los criterios de aceptación bien redactados benefician a varias etapas y partes interesadas de un proyecto. Esto abarca:

Aclarar el alcance para el equipo de proyecto
Asistir al equipo de desarrollo/implementación
Garantizar que los evaluadores sepan lo que se debe evaluar

Los criterios de aceptación deben indicar la intención, pero no una solución. Piense en el qué, no en el cómo.

Mal ejemplo de criterio de aceptación debido a que se enfoca en la solución: Un gerente de distrito puede hacer clic en un botón Aprobar/Desaprobar para aprobar un precio de producto con descuento.
Buen ejemplo de criterio de aceptación debido a que se enfoca en la intención: Un gerente de distrito puede aprobar o desaprobar un precio de producto con descuento.

Una vez finalizado el taller de declaración de una historia de usuario, es momento de agregar los criterios de aceptación. Regresemos a la historia de usuario de la unidad anterior.

Ejemplo de historia de usuario: Como representante de atención al cliente, espero poder asumir la propiedad de casos nuevos y comunicarme con los clientes para brindar experiencias de cliente de alto contacto.

Algunos ejemplos de criterios de aceptación para esta historia de usuario pueden ser:

Asumir la propiedad de casos desde la cola.
Enviar emails a los clientes desde la página de casos.
Actualizar los detalles del caso: estado, asunto, descripción.

Los criterios de aceptación también se pueden formatear como declaraciones de condición. Estos son los criterios de aceptación anteriores redactados como declaraciones de condición: Si se utiliza una página de caso, es posible acceder a la función de envío de emails a clientes. Independientemente del formato, cada historia de usuario debe tener al menos un criterio de aceptación. Cada criterio debe ser comprobable por separado y respondido como verdadero o falso.

¿Se siente bien con respecto a los criterios de aceptación? Es momento de realizar un pequeño ejercicio. Seleccione los criterios de aceptación correspondientes para el ejemplo de historia de usuario indicado.

Es posible que piense: “¿Cómo recordaré todos estos detalles al redactar historias de clientes y criterios de aceptación?”. Sugerencia: Es hora de invertir en memorizar un acrónimo.

Invertir en la historia de usuario

Si su lista de tareas personal incluye “aprender sobre una nueva lista de comprobación”, ¡buenas noticias! Justo ahora va a tachar eso de su lista. Los analistas de negocio de Salesforce pueden utilizar la lista de comprobación INVEST (creada por Bill Wake en 2003) para evaluar la calidad de una historia de cliente. Si una historia de usuario no cumple con una de las comprobaciones, es probable que deba ser reescrita.

Una historia de usuario exitosa es:

Independiente: Las historias de usuarios deben ser independientes y sus conceptos no se deben superponer con los de otras historias.
Negociable: Una historia de usuario no es un contrato. Una historia es una invitación para una plática. Debe capturar la esencia, no lo detalles.
Valiosa: La historia de usuario debe ser útil para el usuario final. No se deben crear historias que no tengan valor.
Calculable: Debe ser posible calcular el cronograma de una historia de usuario exitosa. No se requiere una estimación exacta, solo lo suficiente como para priorizar y programar el desarrollo y la implementación de la historia.
Sintética: Las historias de usuarios más efectivas son pequeñas. Las historias de usuarios reducidas suelen producir estimaciones cronograma más precisas. Recuerde: los detalles pueden ser explicados en las pláticas.
Comprobable: Una buena historia de usuario se puede probar. Para que una historia sea exitosa, un miembro del equipo de proyecto puede examinar la historia de cliente y afirmar: “Sí, comprendo esta historia de usuario tan bien que puedo redactar sus criterios de aceptación”.

Errores que se deben evitar

Al igual que en otros procesos con múltiples pasos, se pueden cometer errores y las historias de usuarios no son inmunes a los pasos en falso. Afortunadamente, las historias de usuarios se pueden ajustar y siempre hay margen para la repetición. ¿Pero por qué no hacer todo lo posible para evitar los errores desde el minuto cero? Estos son algunos errores comunes en las historias de usuario y sugerencias para que los analistas de negocio de Salesforce los puedan evitar.

El equipo de proyecto no se implicó en la redacción de la historia.

Resultado: La historia de usuario no representará las múltiples perspectivas del equipo de proyecto. Es inevitable reescribir la historia de usuario muchas veces.
Cómo evitar esto: Programe una sesión de redacción de historias al inicio del proyecto. Revise constantemente y analice la historia de usuario con los miembros del equipo de proyecto.

El quién de la historia de usuario es un usuario indeterminado.

Resultado: El equipo de desarrollo tendrá dificultades para comprender la función de las motivaciones y necesidades de este usuario, ya que es una persona no definida. La historia de usuario no producirá el resultado deseado.
Cómo evitar esto: Antes de crear una historia de usuario, cree una lista de perfiles de usuarios definidos. Es posible consultar estos perfiles bien definidos al crear una historia de usuario, desarrollar o implementar la solución y realizar las pruebas.

El porqué de la historia de usuario es específico de una característica.

Resultado: La historia de usuario es demasiado técnica y se enfoca en datos específicos. Parece más una descripción de la herramienta que una historia. No se abordan las necesidades del usuario.
Cómo evitar esto: Mantenga las necesidades del usuario como la prioridad número uno. Revise la historia de usuario después de su redacción para comprobar si se enfoca demasiado en datos específicos. Siempre reciba con gusto los comentarios del equipo de proyecto.

Los criterios de aceptación son demasiado confusos.

Resultado: Sin criterios de aceptación comprobables y específicos, no existe una manera confiable de medir la finalización exitosa de una historia de usuario.
Cómo evitar esto: Compruebe que todos los criterios de aceptación sean independientes y se puedan responder como verdaderos o falsos. Trabaje con el equipo de proyecto en la redacción de criterios de aceptación que se alineen con el objetivo del usuario.

La historia de usuario se asignó al equipo de implementación sin discutir esto con el equipo.

Resultado: Las probabilidades de que las historias de usuarios se malinterpreten durante el desarrollo aumentan considerablemente. El producto final puede desviarse de la intención original.
Cómo evitar esto: Revise las historias con el equipo al asignarlas. Revise los detalles, destaque la intención y verifique que el equipo se encuentre en sintonía.

Como puede ver, es posible evitar todos estos errores si se sigue correctamente el proceso de la historia de usuario. No se deben tomar atajos. Confíe en el proceso y el resultado final será una solución enfocada en el éxito del cliente/usuario final.

La definición obvia de que las historias de usuarios son historias acerca de los usuarios no parece tan desatinada ahora, ¿verdad? Aprendió mucho acerca de las historias de usuarios: su propósito, sus partes, los participantes que se deben implicar, la forma de probarlas, los errores que se deben evitar e incluso un acrónimo para evaluarlas. Ahora utilice los conocimientos recién adquiridos sobre este nuevo aliado y redacte algunas historias sobre los usuarios.