Es la reunión en la que el dueño de producto y el equipo se reunen para revisar la pila de producto y añadir, retirar o reestimar historias de usuario.

¿Para qué se hace?

• Para que el dueño de producto tenga las conversaciones necesarias con el equipo antes de introducir una historia de usuario en el backlog.
• Para que el dueño de producto pueda estimar las historias con el feedback proporcionado por el equipo.
• Para evitar que el equipo se quede sin historias en las que trabajar.
• Para incorporar al backlog el feedback proveniente de las demos y del producto en producción.

¿Cómo se hace?

• No tiene por qué ser una única reunión, pero debe atenderse al espíritu de la misma y cuidar el backlog frecuentemente.
• El equipo y el dueño de producto acuerdan una reunión periódica (una por iteración). También se puede publicar en el tablón junto a la hora de la reunión diaria.
• No debe ser una reunión demasiado larga (1 hora): dependerá del número de nuevas historias.
• El dueño de producto trae escritas las historias de usuario, pero se pueden reescribir o matizar en esta reunión con ayuda del equipo.
• El dueño de producto explica cada historia en orden de importancia para él. Es muy importante que el equipo aclare para qué quiere el dueño de producto esa historia de usuario.
• Se estima cada historia atendiendo a su complejidad, cantidad de esfuerzo requerido o incertidumbre.
• Es el momento de distinguir entre un “defecto” (bug) o una funcionalidad nueva y mejorar la manera de describir las historias de usuario.

Malas prácticas

• Que no esté presente el dueño del producto
• Salir de la reunión sin haber estimado y priorizado todas las historias de usuario (aunque se hayan estimado con “infinito”) o sin que cada historia tenga su criterio de aceptación.
• Dejar historias de usuario con estimaciones muy altas demasiado arriba en el backlog. Una historia muy grande suele indicar que necesita ser redefinida y posiblemente se puede separar en más de una.

Referencias

• Backlog Grooming: Who, When and How artículo (en inglés) en el portal InfoQ

DEFINICIÓN:Un Plan de “release” es un conjunto de historias de usuario (normalmente épicas), priorizadas, con las que se elaborará un producto entregable con un incremento de valor respecto a la anterior.

DEFINICIÓN:Un Plan de proyecto es una hoja de ruta del proyecto, similar al plan de “release” pero a más alto nivel aún.

¿Para qué sirve?

Elaborar un plan de proyecto es necesario porque:

• ayuda, al dueño de producto y al equipo, a decidir cuánto se debe desarrollar y cuánto tiempo se tardará antes de tener un producto entregable
• comunica las expectativas sobre lo que se puede desarrollar y en qué tiempo (para que el resto de la organización pueda hacerse una idea)
• sirve para tener una idea del progreso

El concepto de “release” ayuda al equipo a enfocarse, les da un contexto y evita moverse sin rumbo de una iteración a otra. El fin del “timebox” es la oportunidad para pararse y buscar oportunidades de mejora. Como siempre, para eso se usa la técnica de la retrospectiva (cambiando el foco en el proyecto/release/iteración), según corresponda.

¿Cómo se hace?

Se puede estimar a partir de una fecha y ver cuánto se puede hacer hasta entonces, o se puede empezar por un conjunto de historias de usuario y estimar cuándo se podrían terminar. En ambos casos es necesario tener una estimación de la velocidad del equipo.

Si el equipo suele hacer 20 puntos por iteración y las iteraciones son de 2 semanas, para desplegar una “release” de 200 puntos serán necesarias 10 iteraciones, e.d., 20 semanas aproximadamente.

El compromiso del equipo no es con la fecha de entrega sino con la prioridad marcada por el dueño de producto.

Malas prácticas

• Considerar el plan como un contrato. Se construye en base a estimaciones.
• No tener un criterio de aceptación para cada “release”.
• No revisar nunca el plan.

Bibliografía:

• El libro “Agile Estimating and Planning” de Mike Cohn.

Es una lista de Historias de Usuario, ordenadas según el valor de negocio que establece el Dueño del Producto, y que trata de cubrir todas las funcionalidades necesarias.

¿Para qué se hace?

• Se hace para tener una perspectiva de todo lo que se quiere hacer y tener claras las prioridades del cliente.
• Ayuda a que el equipo sea más autodisciplinado y respete las prioridades del cliente.
• También permite que el cliente pueda introducir cambios durante la vida del proyecto.
• Ayuda a manejar la incertidumbre durante el proyecto porque empuja a describir con más detalle las historias más importantes y a relativizar la importancia de detallar historias de menor prioridad.
• Es más ligero que un documento de requisitos exhaustivo.

¿Cómo se hace?

• Las historias de usuario de mayor prioridad estarán más detalladas que las que se abordarán más adelante.
• Se revisa frecuentemente (en la reunión de revisión del backlog)
• Es frecuente agrupar las historias usando el método MoSCoW.
  • “imprescindibles” (Must have),
  • “importantes” (Should have),
  • “interesantes” (Could have) o
  • “opcionales” (Won’t have now but Would be later).
• Nuestro compromiso con el cliente es desarrollar en este orden.

Malas prácticas

• Considerar la pila de producto como un contrato. Sólo es una herramienta de planificación.
• Cambiar prioridades sin el consentimiento del dueño del producto.
  Introducir en el backlog historias de deuda técnica. Los defectos del equipo no los paga el cliente, sino que reducen la velocidad.
• Preocuparse por describir con mucho detalle historias que están muy abajo en el backlog.
• No actualizar el plan de proyecto (¿qué pretendemos entregar en cada release?) cuando introducimos nuevas historias o reestimamos las existentes.

Para ampliar

• El libro “Agile Estimating and Planning” de Mike Cohn.
• Prioritizing the Product Backlog (artículo en el blog Agile Software Development)

DEFINICIÓN: Una historia de usuario (o user story en inglés) describe una funcionalidad que, por sí misma, aporta valor al cliente (representado por el dueño de producto).

Se compone de:

• una descripción escrita de la historia usada como recordatorio y para planificar. (Debe ser breve)
• conversaciones acerca de la historia que sirven para aclarar los detalles
• un criterio de aceptación (idealmente automatizado) que permita determinar cuándo la historia ha sido completada

Una vez estimadas y priorizadas pasan a formar parte de la pila de producto (product backlog).

Podemos usar tarjetas grandes para las historias de usuario y tarjetas pequeñas (o post-its) para destacar tareas importantes que no deben olvidarse durante el desarrollo de una “tarjeta grande”.

Es aconsejable usar el formato: “Como [rol] quiero [funcionalidad] para [beneficio]“

Como [cliente habitual], quiero [ver productos relacionados con mis compras anteriores] para [ver si hay otros productos que me puedan interesar].

Los criterios de aceptación suelen anotarse en el reverso de la tarjeta.

INVEST

• Independent : se pueden hacer en cualquier orden (no dependen unas de otras)
• Negotiable : no son contratos, sino promesas de comunicación
• Valuable : siempre debemos dar valor al cliente (no crear historias técnicas)
• Estimable : si no podemos estimarlas es porque debemos conversar más
• Small : pequeñas (pero no demasiado)
• Testable : si no puedes probarla, ¿cómo puedes saber que está acabada?

En nuestro ejemplo, los criterios de aceptación se pueden expresar como restricciones:

• Los productos estarán ordenados por valoración y margen de beneficio.
• Cuando el usuario haga clic en un producto, se desplegará el detalle.
• Etc.

Las restricciones que acordemos pueden influir mucho al coste de construcción.

Malas prácticas

• Escribir historias que dicen cómo se hará en vez de qué se debe hacer (p.ej. CRUD de Clientes)
• Una Historia de usuario no es un Caso de uso porque no se centra en el cómo ni tampoco es una definición exhaustiva de los requisitos.
• No escribir el criterio de aceptación o no ser suficientemente explícito.
• No estimar una tarjeta puede crear falsas expectativas y dificulta la autodisciplina.
• Fiar todo a lo escrito en la tarjeta: a veces es necesaria documentación externa. (Wiki)
• Dar una historia por hecha cuando está “prácticamente hecha” en vez de “hecha-hecha”.

Bibliografía

User Stories Applied by Mike Cohn

Temas avanzados

• personas
• iconos para marcar prioridades, “impedimentos”, etc
• requisitos no funcionales

En mi blog

• Historias de Usuario
• Salvando las Distancias
• XGN 2011

Además de conocer una de las técnicas más poderosas de eXtreme Programming (XP), los alumnos se pondrán en diferentes situaciones cotidianas e irán empleando las técnicas recién aprendidas para consolidar el aprendizaje cuanto antes.

Durante este taller también verán diferentes técnicas de estimación y planificación o una introducción a la automatización de los criterios de aceptación e incluso se familiarizarán con algunos conceptos de Scrum como la construcción de la pila de producto o el rol del dueño de producto.

Dónde: Okuri Spaces (Bravo Murillo, 244, Madrid)
Cuándo: Sábado, 11 de Junio de 2011 (de 9:30 a 17:00)
Cuánto: 150 € + IVA (177 €) (Descuentos para grupos)
Plazas: 15

Ya os podéis registrar aquí, donde tenéis todos los detalles. Si tenéis cualquier duda o sugerencia, no dudéis en poneros en contacto conmigo para cualquier aclaración.