¿Cuándo crear y refinar las User Stories?

Después de haber hablado del por qué, qué y cómo de las historias de usuario, ahora nos toca entender el cuándo. Para eso hay que entender el proceso de escribir las Historias de Usuario a lo largo de un desarrollo ágil. ¿Cuándo y cómo obtener la primer gran lista de Historias? ¿Hasta qué nivel de detalle conviene llegar? ¿Para todas hay que llegar al mismo detalle? ¿En qué momentos conviene trabajar en el refinamiento?

Por si no viste los puntos anteriores, estos son los posts anteriores:

  1. User Stories – Entendiéndolas para poder usarlas lo mejor posible
  2. Por qué las User Stories en un contexto ágil
  3. Qué son las User Stories
  4. ¿Cómo escribir User Stories?

¿Dónde está el backlog?

El primer objetivo a la hora de crear las historias de usuario es tener la lista inicial de nuestro backlog, que nos permita empezar a construir y además sabiendo que empezamos por donde más valor aportamos. Es muy fácil decirlo, pero no tanto conseguirlo. Tenemos que conseguir no perdernos en los detalles y a la vez intentar no dejar nada clave fuera.

Una de las técnicas que más me gusta para esto es el User Story Mapping , ya que este ejercicio inicial nos permite identificar las actividades que los usuarios necesitan para conseguir su objetivo y a partir de ellas podemos detallar que tareas harán los usuarios como parte de estas actividades. Incluso si lo combinamos con un Impact Mapping, podemos comenzar el ejercicio a partir de qué objetivo/s queremos conseguir con el producto y de ahí identificar sus actividades, tareas y User Stories asociadas (no voy a entrar en más detalle porque da para otro post, pero en este video la gente de Kleer explica de forma fácil qué es un story map y como construirlo).

Ahora que ya tenemos más claro el conjunto de historias que contendrá nuestro producto, tenemos que pensar en las prioridades, para saber por dónde empezaremos y así poder detallar más las  historias más prioritarias. Para esto el User Story Map también nos ayuda, ya que el eje vertical representa la prioridad de cada historia para una actividad o tarea del usuario. Por lo que podemos definir cuáles serán los posibles releases del producto. Si estamos en el inicio del producto, nos centraremos en conseguir el “walking skeleton” de nuestro producto en los primeros sprints, por lo que podemos empezar priorizando y refinando el conjunto de historias que nos ayudan a conseguirlo.

¿Cuántas necesitamos? ¿Cuánto detalle tienen que tener?

Ahora sí! Tenemos un backlog bastante completo y priorizado. ¿Puedo empezar a desarrollar mi primera historia? Hmmm… Creo que no está lista…

Ahora es el momento de dejar de trabajar con vista de pájaro y pasar al detalle. Ya hicimos un buen trabajo de inception, pero ahora necesitamos hacer el refinamiento antes de empezar con el primer sprint. Lo que haremos es detallar las primeras historias hasta que estén listas y tengamos suficiente trabajo para el primer sprint (si trabajamos con Scrum).  Algo que suele pasar al crear el User Story Map es que el tamaño de las historias varía mucho y algunas son más bien épicas y otras historias pequeñas. Para esto habrá que dividir las historias como ya hablamos en el post anterior. ¿Cómo escribir User Stories?

Si estamos empezando nos podemos centrar en el walking skeleton, ya que te ayudará a tener una solución end to end que incluso técnicamente te haga trabajar en los principales componentes. A partir de ahí ya iras trabajando en los releases que hayas podido identificar en el User Story Map.

La cantidad de historias que el PO y equipo quieran tener listas va a depender de muchas variables. Lo mejor es ir aprendiendo. Lo importante es entender que lo que buscamos es minimizar la cantidad de trabajo que tenemos adelantado en el backlog, para reducir la posibilidad de desperdiciar tiempo de trabajo y tener la mayor flexibilidad que nos permita adaptarnos a posibles cambios, pero a su vez que el equipo no se quede sin historias lo suficientemente listas para comenzar a trabajar. Este es uno de los aspectos que el PO y el equipo tienen que ir trabajando juntos para encontrar su nivel adecuado.

El detalle que necesitamos en el backlog varía según la prioridad de las historias. Para las historias que se trabajarán en los próximos días o iteraciones  vamos a querer tener las historias listas (DoR), con toda la información que el equipo necesita para comenzar a desarrollarla. Para el resto el detalle ira disminuyendo. Algo importante a mencionar, es que mientras más extenso sea el DoR, antes necesitaras ponerte a refinar y detallar cada historia (en este post comento más en profundidad esto).

Algunas de las variables que pueden influir en cuando refinar las historias son:

  • Prioridad
  • Tamaño
  • Velocidad o burnRate
  • Cantidad de trabajo necesario para conseguir el DoR
  • Variabilidad de los requerimientos (qué tanto cambian y con qué frecuencia)
  • Dependencias en el refinamiento

¿Y cuándo es el momento de hacer todo esto?

El refinamiento es una actividad que se hace constantemente. Es el proceso de gestionar el backlog teniendo en cuenta todas las variables mencionadas (y más). Pero si bien esto es así y generalmente hay una persona responsable de que esto suceda (el Product Owner en Scrum), cómo el backlog es una herramienta más de comunicación entre producto y desarrollo, es importante que haya colaboración a la hora de refinar las historias. Es por esto que en Scrum es una  práctica común el hacer una reunión de refinamiento entre PO y equipo de desarrollo. Sirve para que el equipo no tenga que ser interrumpido constantemente durante el sprint, y para asegurar que el backlog y las historias son entendidas por todos. También es buena práctica hacer un taller de escritura de historias (“User Story writing workshop” para googlearlo 🙂 ) con cierta periodicidad, que nos permita ir extendiendo el backlog a medida que el producto evoluciona.

Lo importante de estas reuniones es entender que lo que buscamos es mantener un backlog con salud (que cumpla con las características DEEP: detailed appropriately, emergent, estimated, and prioritised).

Las actividades que se suelen hacer en estas reuniones son:

  •  Escribir nuevas User Stories
  • Dividir User Stories muy grandes en más pequeñas
  • Mejorar aquellas que no estén bien escritas o definidas
  • Estimar los nuevo ítems del backlog
  • Agregar criterios de aceptación
  • Mirar “en profundidad” para tener una idea a más largo plazo de lo que vendrá y sus implicaciones técnicas.
  • Etc.

El mayor desafío es encontrar el ritmo adecuado de trabajo que nos asegure no tener mucho desperdicio (trabajo hecho sobre el backlog que está en espera) y por otro lado que el equipo siempre tenga trabajo listo para empezar en caso de necesitar más. Es la comida que le llega al equipo, que tiene que haber suficiente, pero también tiene que llegarle fresca!

 

Anuncios

¿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. Sigue leyendo

Qué son las User Stories

Ahora que ya entendemos porque existen y cuál es el objetivo que buscan, veamos qué son exactamente estas tan famosas User Stories.

Se dice que las User Stories son una “promesa de una futura conversación”. Esto es porque en un principio cuando se crean suelen ser una simple frase o breve descripción de una funcionalidad que aporta valor al usuario o al negocio y que si no es prioritaria en ese momento no se entra en más detalle. Es por esto que queda en el backlog como un recordatorio de un requerimiento, para en el futuro trabajar sobre ella entre el Product Owner (PO) y el equipo (PO en el contexto Scrum o responsable de producto y/o definición de necesidades y prioridades como rol más genérico). Esto nos permite enfocarnos en lo que hoy es importante sin miedo a olvidarnos de algo en el futuro.

Una User Story se compone de tres partes. Tarjeta, Conversación y Confirmación (CCC por sus siglas en inglés). Sigue leyendo

Por qué las User Stories en un contexto ágil

Para entender el por qué de las User Stories creo que es bueno ir un paso atrás e intentar entender que en el desarrollo de software ágil (contexto en el que las User Stories han nacido y en el que viven actualmente) se intenta cambiar (entre otras cosas) hacia una forma de desarrollo que se adapte a las necesidades cambiantes del cliente o producto. Esto es un punto muy importante y que considerando la velocidad a la que cambian actualmente las tecnologías, cada vez toma más protagonismo. Un estudio1 realizado hace pocos años indica que entre 1980 y 1990 la mitad de los requerimientos de un sistema  dejaban de ser válidos después de diez años, que en el 2000 ese tiempo de vida de la mitad de los requerimientos pasó a ser de unos dos años y actualmente se estima que ese tiempo es de seis meses. Esto quiere decir que si estamos escribiendo un requerimiento que va a ser desarrollado en unos meses, tenemos una probabilidad muy alta de que incluso antes de empezar a desarrollarlo el requerimiento ya no sea válido y haya que cambiarlo.

Lo anterior está directamente relacionado con el valor del manifestó ágil de Respuesta ante el cambio, pero para tener una buena captura de requerimientos ágil también necesitamos un método que se adapte a los valores que ponen el foco en Individuos e interacciones, Software funcionando y Colaboración con el cliente. Sigue leyendo

User Stories – Entendiéndolas para poder usarlas lo mejor posible

Este es el primer post de una serie que voy a escribir sobre User Stories (Historias de Usuario) con la intención de entender bien qué son (y qué no), por qué usarlas, cómo usarlas, cuándo trabajar en ellas y por último como podemos practicar para ser mejores escribiéndolas.

Elegí este tema como primer serie de mi blog ya que creo que muchos equipos que empiezan a trabajar con frameworks de desarrollo de software ágil (más conocido como Agile ☺ ) utilizan User Stories como elementos de su Backlog (o por lo menos así les llaman) sin antes entender bien qué son y por qué se utilizan. Supongo que el hecho de que las User Stories estén tan ampliamente usadas en los equipos ágiles hace que por facilidad o incluso falta de tiempo un equipo adopte esta práctica sin cuestionarse mucho el por qué. Pero bueno, no estoy acá para juzgar a los equipos, así que mejor me concentro en intentar ayudar con este post. Sigue leyendo