Blog Agilidad, Innovación y Creatividad - GioSyst3m

Haz que las historias de usuario realmente funcione - GioSyst3m

Escrito por GioSyst3m | Jul 15, 2021 9:07:52 PM

En el mundo de agilidad que nos movemos hoy en día, las Historias de Usuario [HU] son la clave de todo para poder lograr que el producto genere valor e impacte a tus clientes.

En los últimos años he trabajado con metodologías ágiles donde las Historias de Usuario juegan un papel importante y es el trabajo diario de las unidades ágiles, en éste post quiero compartir algunos tips para tengas en cuenta para crear una buena historia que funcione.

Una de las definiciones que encontramos en internet y que expresa claramente lo que significa:

Una historia de usuario es una representación de un requisito escrito en una o dos frases utilizando el lenguaje común del usuario. Las historias de usuario son utilizadas en las metodologías de desarrollo ágiles para la especificación de requisitos (acompañadas de las discusiones con los usuarios y las pruebas de validación).

Link https://es.wikipedia.org/wiki/Historias_de_usuario

Ten en cuenta la recomendación de Jeff Sutherland, el creador de SCRUM:

Cuando escribas tus historias de usuarios, sin embargo, no olvides recuerda que deben ser cortas y precisas para poder evaluarlas.

Libro: El arte de Hacer el Doble del Trabajo en la mitad del Tiempo. p.121

Autores: Jeff Sutherland y J.J. Sutherland

Estructura de una Historia de Usuarios

Para la creación de una Historia es muy sencillo, aquí aplica la frase

Menos es mas

Como puedes observas la estructura de una historia de usuarios es sencilla

COMO <persona, sujeto, cliente, rol>

QUIERO <acción, deseo, necesidad, objetivo>

PARA <motivación, razón, próposito>

Los Criterios de Aceptación

  1. Ayuda a identificar que debe o no hacer la historia de usuario.
  2. Ayuda tener una claridad de las cosas que DEBE hacer.
  3. Limita el alcance de la historia.
  4. Ayuda tener una claridad que tan compleja es la Historia de usuario.

Para ello existe una técnica bastante sencilla para crear un criterio de aceptación puedes usar el formato Dado … Cuando … Entonces

Puedes usarlo de la siguiente formato:

  • Dado <cierta condición>
  • Cuando <ocurre un evento o acción>
  • Entonces <sucederá una consecuencia>

Siguiendo un de los ejemplos anteriormente

  • Como cliente quiero comprar en linea para pagar con mi tarjeta de crédito

Un criterio de aceptación seria:

  • Dado que el cliente quiere comprar en la pagina cuando da clic en pagar y coloca los datos de su tarjeta de crédito entonces el sistema valida que todo este correcto y tenga el cupo para pagar la transacción y sea aprobada.

Definition of Ready (DoR)

Definition of Ready o Lista de de Listo es recomendado tenerla, ya que ésta te ayuda a saber cuando una Historia de Usuaria esta lista para el Sprint planning, y adicionalmente te da una visión clara que la historia ha pasado por su respectivo refinamiento.

Todas las condiciones de los criterios de listo (Definition of Ready DoR) que deben cumplirse para que la historia se pueda incluir en el Sprint Planning

Ejemplo de DoR

  • Entregar la historia de usuario en el formato propuesto
    • COMO <rol>
    • QUIERO <objetivo>
    • PARA <motivación>
  • Criterios de aceptación de las historias de usuario y su formato
    • Dado <cierta condición>
    • Cuando <ocurre un evento o acción>
    • Entonces <sucederá una consecuencia>
  • Valor de negocio identificados claramente
  • Lista de dependencias identificadas y gestionadas.
  • La Historia de Usuario debe cumplir con el método INVEST

Si aún no has usado este artefacto te recomiendo que hables con tu SCRUM Master para que la creen en conjunto con el equipo, llagar acuerdos y sean más asertivos los Refinamientos y Planning.

Definition of Done (DoD)

Documenta el conjunto de reglas que aplican para todas las historias de usuario con el fin de que se adhieran a las normas de calidad obligatorias para que el producto se considere como terminado

Se diferencian de los criterios de aceptación en un aspecto clave; mientras los criterios de aceptación son únicos para historias de usuario individuales, los criterios de terminado son un conjunto de reglas que son aplicables a todas las historias de usuario

Al igual que con los criterios de aceptación, todas las condiciones de los criterios de terminado (Definition of Done DoD) deben cumplirse para que la historia del usuario se considere como hecha.

Ejemplo

  • Prueba unitaria exitosa de la historias de usuario.
  • Todos los errores han sido corregidos.
  • El producto se encuentra en ambiente de pruebas si no hay release y en ambiente productivo si hay release.
  • Ajuste a colores corporativos

  • Que todos los criterios de aceptación se cumplan

Método INVEST para Historia de Usuario

Es un acrónimo en ingles que ayuda mucho a tener claro como crear tu Historias de Usuario, es una técnica que recomiendo mucho a los Product Owner al momento de crear sus historias.

Cada historia de usuario pueda ser planificada e implementada en cualquier orden. No dependen unas de otras, si ocurre se deben dividir o combinar. Una Historia debe hacerla una sola persona del Equipo. Evitar que tenga Dependencias.

Las historias deben ser negociables ya que sus detalles serán acordados por el cliente/usuario y el equipo durante el <<Refinamiento y Planeación>>. Que le equipo pueda dar sugerencia al Product Owner, y viceversa para poder entender el valor.

Una historia de usuario tiene que ser valiosa para el cliente o el usuario. Esta debe impactar al usuario, mercado generando valor en su desarrollo, ejecución e implementación.

Una buena historia de usuario debe ser estimada con la precisión suficiente para ayudar al cliente o usuario a priorizar y planificar su implementación. Si no podemos estimarla debemos indicir en la fase de conversación o dividirla. Si tienes sprint de 1 semana que no sea mayor a 3 puntos/días.

Pequeñas. Solemos hacerlas de tal modo que ocupen como máximo un sprint, Fácil de entender y desarrollar, y que genere valor.

La historia de usuario debe poderse probar. Tanto el usuario como el equipo tienen que poder probarla para saber cuando está finalizada. Pueda ser probadas por el clientes, tener un feedback rápido para garantizar la entrega de valor.

Las 3 C para las Historias de Usuarios

Recomendaciones para las Historias de Usuarios

En los últimos años trabajando como Agile Coach he visto que la creación y adopción de las Historias de usuarios para los proyectos, no es tarea fácil; sin embargo, cuando comienzas a crear y usar, empiezas a entender el valor que ella generan.

En el mundo de la agilidad, una buena historia de usuario ayuda a que logres impactar a tu cliente cubriendo sus necesidades en el momento adecuado.

Considero que esto es de práctica y constante aprendizaje, hoy puedo darte unas recomendaciones generales pero te aseguro que en un futuro te daré más.

Una recomendación que te puedo dar es que use los DoR y DoD trabaja en ello con tu Scrum Master y todo el equipo de trabajo, que sea una lista donde todos propongan y lleguen acuerdos para se genere el compromiso y lo más importante la apropiación, sea usada y actualizada periódicamente.

Por ello siempre buscar apoyo de los Agile Coach y/o, Scrum Master quienes te darán la guía para puedas ver el sentido a las historias de usuarios, y podrás aplicar en todos los aspectos de tu vida.