¿Cómo escribir User Stories?

Como ya dije en el post “Que son las User Stories”, lo importante es que una historia de usuario (si, voy a intentar llamarlas por su nombre en castellano J ) permita entender de una manera simple lo que el usuario quiere conseguir. Cuando una historia se crea, generalmente solo tiene esta descripción (la primera ‘C’ –Card), ya que luego, en el momento que sea prioritaria, será refinada y se le agregaran más detalles o incluso se dividirá en varias historias de usuario más pequeñas.

Entonces para escribir buenas historias de usuario es importante buscar la mejor forma de escribir esta descripción, ya que es la que nos recordará lo que el usuario necesita y nos ayudará a hacer las preguntas correctas a la hora de entenderlas mejor. La forma más extendida de escribirlas es utilizando el formato “As a [who/role] I want [what/goal] So that [why/benefit]” o “Como [quien/rol] Quiero [que/acción] Para [razón/beneficio]”. Si desglosamos un poco esto para entender realmente por qué se utiliza esta forma de escribir las historias luego nos será más fácil escribirlas correctamente e incluso adaptarla a nuestro contexto.

Como verán siempre me centro mucho en entender bien las cosas, sabiendo por qué algo es como es, que objetivo se busca en una práctica concreta, etc. Creo que es la mejor forma de sacarle el máximo rendimiento a lo que hacemos. Si no entendemos por qué hacemos algo de una determinada manera estaremos siempre muy limitados.

Volvamos a las historias de usuario que me voy por las ramas J. Vamos a ver qué quiere decir esto del Como, Quiero, Para.

Como [quien/rol]: Definir el rol o Persona que necesita una cierta funcionalidad que le beneficie en su trabajo es muy valioso ya que nos pone en el contexto de la persona que usará esa funcionalidad. De esta forma podemos entender mejor el por qué necesita dicha funcionalidad y tener algo de empatía con ese hipotético (o no tanto) usuario.

Tip: Si no están definidos los roles o Personas de tu producto o aplicación, ignora esta parte y no pongas siempre “Como usuario”. Tener “como usuario” en todas las historias no aporta valor! Y lo que no aporta valor no tiene sentido hacerlo.

Quiero [que/acción]: Aquí podría ser acción u objetivo. En esta parte se describe lo que el usuario quiere hacer, la acción concreta o el objetivo que busca. Pero no nos interesa saber cómo lo quiere hacer, porque estaríamos entrando en demasiado detalle y no dejando lugar a que se busque la mejor solución posible y/o más innovadora.

Por ejemplo si quiero acceder a mis cuentas bancarias para operar con ellas, probablemente tengamos una historia que nos diga que “Como cliente del banco quiero acceder a mis cuentas para poder operar” y de esta después derive alguna historia que diga que “Como cliente me quiero identificar para acceder a mis cuentas” (el login J). Aquí no tendría sentido decir que el usuario quiere identificarse poniendo su usuario y contraseña para poder ingresar a las cuentas, ya estaríamos diciendo cómo solucionar el problema. Y probablemente haya muchas otras formas de identificarse que sean más rápidas y hasta más seguras.

Para [razón/beneficio]: Esta para mi es la parte más importante de la historia de usuario. Aunque muchas veces se deja de lado (incluso por los “gurus” de las historias de usuario). Entender que es lo que realmente busca el usuario y por qué necesita hacer algo nos da muchísima información ya sea para proponer la mejor solución o incluso para entender si realmente eso que está pidiendo es realmente necesario para obtener el beneficio que quiere.

Por ejemplo si tenemos una historia que dice “Como responsable de ventas quiero un reporte con el top de ventas semanales para enviárselo a mi superior” al saber que el objetivo es enviárselo al superior, probablemente podríamos crear una funcionalidad que cada semana envíe el reporte al superior, sin necesidad que el responsable de ventas tenga que crearlo y enviárselo. Si en esta historia no teníamos el “para”, nunca hubiésemos planteado el envío automático. Este es un ejemplo muy sencillo simplemente para que se entienda mejor el concepto.

Una vez tenemos la historia de usuario escrita de esta forma, se pueden agregar tantos detalles como se quiera asociados a la Uuser Story, pero no son la historia en sí, sino que es información que el equipo decidió que era necesaria. La parte que sí forma parte de la historia de usuario es la Confirmación, que es la que nos permite saber cuándo una funcionalidad cumple con lo que se esperaba.

Esta Confirmación genera a medida que se va trabajando o refinando la historia a través de lo más importante que es la Conversación (entre el equipo y quien sea que tenga la información que ellos necesiten). En el ejemplo de la imagen de abajo vemos la idea de que la conversación entre el equipo y quien tenga la información necesaria va a generar que se definan los criterios de confirmación necesarios.

Capture

Tips:

  • Si a medida que refinamos una historia terminamos teniendo una lista muy grande de criterios de aceptación (confirmación), probablemente signifique que esa historia de usuario es muy grande y convenga dividirla.
  • Los puntos de la confirmación deben ser SMART
  • Cuando te sientas cómod@ con escribir los criterios de esta forma, explora la especificación por ejemplos y la forma de escribir los puntos de aceptación con Gherkin.

Hay dos temas relacionados con cómo escribir las historias de usuario que voy a profundizarlas más en siguientes. Uno es el refinar las historias, cómo refinarlas y en qué momentos. El refinar es el momento de “negociación” (te acuerdas del INVEST?) donde nos ponemos de acuerdo en que hacer, que dejar para después, cómo dividir las funcionalidades, etc. Este documento es un buen recurso como guía para dividir historias. La regla de oro es dividir las historias verticalmente (como si fueran una porción de torta/pastel) y no horizontalmente por componentes técnicos.

El otro tema que relacionado que también escribiré sobre él es el definir qué información adicional es necesaria en una historia para considerarla “lista”. Esto se conoce como “Definition of Ready” (DoR) y es importante lograr que sea lo más pequeño posible, para que completar todo lo necesario no se convierta en una etapa de análisis. Que tanta distancia hay entre el DoR y el DoD nos muestra si realmente el equipo es cross-funcional y aporta valor desde el comienzo hasta el final del proceso de desarrollo.

Eso es todo, espero que con esto ahora puedan ir a escribir historias de usuario como locos! 🙂

Anuncios

Un comentario en “¿Cómo escribir User Stories?

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s