¿Se deben estimar correctamente las historias antes de incluirlas en un sprint en curso?

Estamos usando Jira en AOL en este momento, por lo que espero poder brindar algunas buenas prácticas y consejos prácticos.

En primer lugar, separemos esto en dos respuestas: nuevas historias de usuarios, defectos/errores

Defectos/errores agregados en un Sprint : no estimar: reducir la capacidad

Así que en AOL nos enfrentamos mucho a este problema. Ejecutamos un sistema de publicidad digital, por lo que tiene mucha escalada de clientes. No contamos con un equipo de mantenimiento, por lo que los errores terminan en los equipos de desarrollo de funciones. Reconociendo que interrumpir un sprint es malo, analizamos detenidamente los errores.

Hicimos un acuerdo con la empresa de que solo mostrar errores de detención (bloqueadores) podría interrumpir un sprint. Cuando entra un bloqueador, obtiene prioridad inmediata. No se estima y ni siquiera es parte de la cartera de pedidos oficial. Es un trabajo paralelo que se debe hacer e impacta la capacidad del equipo.

Todos los demás errores se asignan al trabajo pendiente. Ejecutamos sprints de dos semanas y tenemos al menos dos equipos por área característica, por lo que siempre hay un equipo que comienza un sprint cada semana. Estos errores se arreglan y estiman de forma normal.

Con Jira, mantenemos una acumulación separada de "Defectos" (específicamente problemas encontrados en producción). Este trabajo pendiente es preparado por un equipo de clasificación y luego todos los equipos de funciones tienen acceso a él. Durante la planificación del sprint, se indica a los equipos que tomen aproximadamente el 20 % de su capacidad si hay deuda técnica. La primera prioridad en Tech Debt son siempre los defectos de producción actuales. Esto generalmente se traduce en que nuestros equipos trabajan en 1 o 2 errores por Sprint, además de su trabajo con nuevas funciones.

Nuevas historias de usuarios en un sprint : SIEMPRE ESTIMACIÓN

Una acumulación de productos saludable debe tener dos o tres sprints de trabajo "Listo". Son historias que cumplen con los criterios de INVEST para una historia de usuario. Si no tiene esto, entonces es un problema mayor que abordar, lo que hará que su equipo sea mucho más efectivo.

Si no tiene un backlog bien arreglado, entonces lo que quiere hacer es tomarse el tiempo para preparar nuevas historias. Si está a la mitad del sprint y no hay trabajo por hacer, entonces tenga una reunión de una hora y prepare la parte superior de la acumulación.

Esto es fundamental, no solo porque desea estimar todas las historias. Tomar una historia que no está completamente definida es una excelente manera de desperdiciar esfuerzos.

• La historia ya no puede ser importante
• La historia podría estar mal definida y perder mucho tiempo en volver a trabajar para cumplir con "Terminado".
• La historia podría estar mal diseñada y dar lugar a errores en el sistema.

Las historias de usuarios mal escritas pueden tardar hasta 24 veces más en corregirse que lo que tardaron en escribirse la primera vez (según una investigación de Jeff Sutherland).

Más allá de los consejos anteriores, lo más importante que recomendaría es realizar reuniones periódicas de refinamiento de la cartera de pedidos. El equipo de desarrollo y el propietario del producto trabajan juntos para garantizar que sus historias cumplan con los criterios de INVEST. Muchos equipos están acostumbrados a tener una "Definición de Listo" . También necesita una " Definición de Listo" , qué debe tener la historia antes de que pueda comenzar el desarrollo.

Sí, debe estimar cualquier historia que se incluya en un sprint, especialmente si estima todas las historias de manera constante durante la planificación del sprint. El valor de la estimación radica principalmente en la discusión sobre cómo se deriva la estimación. El proceso de estimación ayuda al equipo a descubrir riesgos, requisitos y hace explícitos los supuestos implícitos.

En cuanto a los defectos, depende de su proceso. Si nunca estima los defectos, entonces no empiece a estimarlos. Si estima los defectos durante la planificación del sprint, también calcule los defectos cuando se presenten. La práctica constante de las técnicas de estimación (sin importar si son precisas o no) hará que su métrica de velocidad sea una herramienta útil para el equipo en su capacidad de planificar sprints en el futuro donde no se extraigan tantos elementos.

Si los errores y los problemas de producción ocurren con frecuencia, podría agregar tiempo no planificado a su sprint como se explica en el blog de Mike https://www.mountaingoatsoftware.com/blog/how-full-to-fill-a-sprint .

Debe estimar las nuevas historias que se incorporan antes de comenzar a trabajar en ellas. Esta debería ser una sesión más rápida y más corta que la planificación de sprint normal, ya que solo tiene en cuenta las nuevas historias. Cuando está haciendo la planificación de sprint, puede seleccionar un conjunto de candidatos potenciales (historias en la cartera de pedidos que tienen la máxima prioridad) para incorporar si su equipo se queda sin trabajo.

Pero si eso ocurre regularmente, entonces debe revisar su planificación, ya que es posible que no esté considerando la capacidad/velocidad total del equipo.

Suponiendo que le gustaría cumplir con la Guía Scrum.

¿Es importante tener estimaciones de puntos de historia sobre estos elementos antes de que se incluyan en un sprint en curso?

Por definición, todos y cada uno de los elementos de la cartera de productos deben ser estimados. Por lo tanto, todos y cada uno de los elementos del Sprint Backlog también deberían hacerlo.

[...] cuándo y cómo debe realizarse esta estimación?

La estimación puede ocurrir en cualquier momento durante el Sprint. Scrum Guide solo requiere Sprint Planning como obligatorio antes de que comience el siguiente Sprint . Esa es la última oportunidad de estimar nuevos elementos de la cartera de productos. No dice que no se le permite tener sesiones de planificación adicionales. Backlog Grooming o Refinamiento , como se le llama, es una práctica muy popular y recomendada.

[...] Supongo que es improductivo programar una reunión de planificación de sprint para cada error que traigamos.

Correcto. Para el manejo de errores en Scrum, eche un vistazo aquí .