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).
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
- Debes pensar quién se va a beneficiar con la tarea que vas hacer
- Empatiza con el cliente colocandote en su lugar.
- Identificar quién es la rol, cliente o persona que le vas aliviar su dolor.
Por ello usa el COMO:
- Como cliente ….
- Como usuario final …
- Como médico…
- Como beneficiario …
QUIERO
- Piensa en el qué, quieres tu cliente en primer lugar,
- Que deseas lograr si tu haces su tarea
- Qué mejoraría en su vida
Para ello usa QUIERO:
- Como cliente quiero ….
- Como usuario final quiero …
- Como medico quiero …
- Como beneficiario quiero …
PARA
- ¿Para qué tu cliente quiere eso?
- ¿Cómo ayudará a mi cliente?
- ¿Por qué buscar esta solución?
Para ello usa PARA:
- Como cliente quiero comprar en linea para pagar con mi tarjeta de crédito
- Como usuario final quiero registrarme con mi cuenta de google para tener todo centralizado
- Como medico quiero que mis clientes agenden sus citas en línea para que elijan la fecha y la hora que más les convenga.
- Como beneficiario quiero recibir bonos de descuentos especiales para poder comprar en mi cumpleaños
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
- Ayuda a identificar que debe o no hacer la historia de usuario.
- Ayuda tener una claridad de las cosas que DEBE hacer.
- Limita el alcance de la historia.
- 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.
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
Carta
Conversacion
Una vez escrita de Historia de Usuario, esta debe generar conversaciones con los Miembros del Equipo, para tener claridad de su alcance
Confirmación
Los criterios de aceptación confirman la corrección de la historia y es entendiendo el valor que generará
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.
