metodologia - Scrum: ¿Cuándo calcula el esfuerzo para los elementos del Backlog del producto?

que es un sprint en scrum (3)

¿En qué parte del proceso de Scrum realiza su equipo estimaciones prudentes sobre el esfuerzo requerido para completar un ítem acumulado del producto?

Por ejemplo, supongamos que tiene un elemento atrasado del producto que dice "El usuario podrá proporcionar su dirección de correo electrónico y recibir un correo electrónico con un enlace para restablecer su contraseña" programado para Sprint 1.

¿Empiezas el sprint con un cálculo aproximado y lo refinas? ¿Cuándo se convierte esta "historia del usuario" en elementos de acción granulares que un programador puede estimar a tiempo? (ejemplo: "Crear formulario web con un cuadro de texto y botón de enviar" = 2 horas)

¿Hace las estimaciones más precisas antes de que comience el sprint? Al comienzo del sprint? ¿O durante el sprint cada vez que el diseñador / programador finalmente tropieza con la tarea?

Por el momento, producimos un desglose detallado de tareas y estimaciones antes de que comience el sprint. Esto es por 2 razones:

1) Nuestro negocio quiere las estimaciones para ayudarlas a decidir la prioridad.

2) Los equipos de desarrollo están bajo presión para cumplir con las estimaciones y no desviarse del agotamiento natural.

En mi opinión, este es el enfoque equivocado, ya que elimina la capacidad de ser ágil. Creo que el proceso debería ser más así ...

1) La empresa debe usar los números de Fibonacci producidos durante la reunión de planificación para ayudarlos a determinar la prioridad. O al menos solo se espera una estimación de "dedo en el aire" del equipo de desarrollo.

2) El gráfico de reducción debería verse como una guía de cómo avanza el proyecto para indicar si se deben agregar más PBI o si se deben eliminar los de menor prioridad y no como un "objetivo" firme de lo que se completará.

Trabajar de esta manera nos permitiría invertir mucho menos tiempo en planificación y diseño. Todavía produciríamos una estimación de alto nivel al comienzo del sprint que podría refinarse a medida que avanza el sprint.

Estaré interesado en obtener comentarios sobre esto antes de tener la batalla con mi negocio.

Por lo general, la estimación debe hacerse en 2 niveles al comienzo de cada sprint: nivel de historia y nivel de tarea. Para obtener los mejores resultados, el propietario del producto y el equipo deben hacer ambas cosas juntos, todas las veces, aunque a veces es aceptable para el equipo estimar en el nivel de tarea sin la presencia del propietario del producto.

Estimación del proyecto / Construcción de la hoja de ruta (Nivel de la historia)

En su primer sprint, debe estimar al menos el 80% de los elementos atrasados (supongo que el propietario del producto ya lo tenía priorizado) para crear un mapa del proyecto razonable, que consistirá en historias agrupadas en sprints y una proyección inicial estimada de la longitud del proyecto.

En este momento, la estimación de cada historia se hace usando, no horas, días o semanas, sino una unidad relativa para el tamaño (que abarca el esfuerzo, la complejidad y el riesgo, todo al mismo tiempo), como los puntos de la historia. Usamos la escala Fibonnaci y Planning Poker para esta fase. Es importante que todo el equipo participe activamente en este proceso.

Después de eso, el equipo tiene que adivinar cuántas historias pueden completar en el primer sprint, que será su velocidad inicial estimada (puntos / iteración). Por lo general, es mejor no usar sprints de 1 mes sino más bien una duración de 2 semanas o 1 semana para mejorar la precisión de la estimación. La primera planificación por lo general tomará todo el día o incluso 2 días, dependiendo del tamaño de la cartera, el tamaño del equipo y la duración de los sprints.

Después de esta primera ronda de estimación de la historia, el propietario del producto junto con el equipo podría querer volver a priorizar la acumulación de pedidos para optimizar la relación costo / beneficio, por lo que podría haber un vaivén hasta que haya un acuerdo.

Deberías terminar con algo como esto:

PROJECT ACME ROADMAP SPRINT 1 (38 points) <= estimated velocity -------- Story 1 (21 points) Story 2 (13 points) Story 3 (4 points) SPRINT 2 (40 points) -------- Story 4 (13 points) Story 5 (13 points) Story 6 (8 points) Story 7 (5 points) SPRINT 3 (39 points) -------- ...

En los siguientes sprints, esta hoja de ruta se revisará una y otra vez, al comienzo de cada sprint, ajustando la velocidad a la velocidad real que el equipo está obteniendo y volviendo a calcular la longitud del proyecto según sea necesario. A veces, volver a estimar las historias también es necesario, a medida que el equipo evoluciona y los requisitos cambian. Sin embargo, el tiempo para revisar la hoja de ruta no debe ser más de medio día.

El progreso en este nivel debe ser visible para las partes interesadas mediante el uso de un cuadro de comparación, donde los ejes X son los sprints y el eje Y son los puntos de la historia.

Estimación de Sprint (Nivel de Tarea)

La segunda parte de la fase de planificación para cada sprint se usa para dividir cada historia en tareas. Aquí, las tareas deben ser de naturaleza altamente técnica y se estiman utilizando horas. Tenemos una política que establece que si la tarea se estima en más de 8 horas, debe dividirse en tareas más detalladas sin importar qué. El resultado será la acumulación de sprints, con tareas agrupadas por historia, y el gráfico de puesta a punto del sprint, donde el eje X / Y debería ser días del sprint y horas respectivamente.

Debe tener un aspecto como este:

Sprint 8 -------- Story 17 Task 1: 8 hours Task 2: 6 hours Task 3: 2 hours Story 18 Task 1: 8 hours Task 2: 6 hours Story 19 Task 1: 6 hours Task 2: 3 hours ...

Básicamente, estos son los 2 tipos de estimación que debería hacer al inicio de cada sprint, donde generalmente el primer sprint requiere un poco más de esfuerzo para construir la hoja de ruta inicial del proyecto.

La estimación aproximada debe hacerse antes de la planificación del sprint donde este equipo en particular es elegido por un equipo. Por lo general, verificamos el retraso del producto durante los cambios de contexto o el tiempo de inactividad durante un sprint para hacer estimaciones aproximadas de nuevos elementos en "puntos de la historia", por lo que el propietario del producto puede priorizarlos adecuadamente antes de la próxima planificación de sprints.

Nuestra planificación de sprint suele tener un intervalo de tiempo de 2 horas al comienzo de un nuevo sprint. Aquí es cuando nos reunimos con los propietarios del producto y seleccionamos los elementos de la cartera de pedidos, la mayoría de ellos estimados aproximadamente y con la prioridad correcta. Las estimaciones faltantes se hacen sobre el terreno y luego hacemos la tarea "detallada" de las historias dentro de esta ventana de tiempo (que generalmente es un trabajo bastante intenso) aprovechando el hecho de que el resto de la empresa está al tanto de esto y de las OP y los interesados están disponibles para resolver los detalles no contabilizados.

Por supuesto, a veces la secuencia de tareas de implementación diferirá de la tarea planificada, luego debe ajustarse y es posible que sea necesario reajustar el diagrama de reducción.

Burndown en tareas
Simplemente usamos la cantidad de tareas para nuestra medida de reducción. Normalmente haces algo así como las horas reales o las horas ideales, pero esto fue lo suficientemente bueno para nosotros y aparentemente lo suficientemente interesante como para necesitar alguna aclaración.

No calculamos el tiempo en estas tareas, todo lo que importa es el cálculo del punto de la historia (la estimación aproximada) de la historia, que colocamos en días ideales para el hombre.

La forma en que esa historia se divide en tareas es más una cuestión de distribución de equipos e indicador de progreso general y no tanto como estimaciones de horas exactas para nosotros.

Al final hemos manejado x cantidad de puntos de la historia y obtenemos nuestro factor de enfoque a partir de eso en relación con los días disponibles para el hombre real en el equipo que corre.

Al final, la estimación aproximada en los puntos de la historia es en lo que basamos nuestra selección de historia (es decir, cuántos SP podemos hacer en un sprint). Tendemos a mejorar en la estimación aproximada, y creo que esto es importante porque el propietario del producto prioriza los artículos en la acumulación principalmente basados en esto, y nunca en función de las estimaciones de la tarea de todos modos, porque ese es el equipo interno.

Como las tareas no tienen una estimación de tiempo explícita en sí mismas, la atención se centra en la estimación aproximada de los puntos de la historia. Si las tareas en conjunto toman más tiempo que los puntos de historia estimados * factor de enfoque, simplemente hicimos el cálculo aproximado incorrecto o deberíamos haberlo corregido durante la planificación del sprint cuando la mayoría de la información debería haber estado disponible u ordenada.