¿Podemos asignar tiempo a los puntos de la historia?

Soy el maestro de scrum y uso el siguiente sistema de manera general:

  • 0,2 puntos aprox < 1 hora
  • 0,5 puntos aprox > 2 horas pero < 3 horas
  • 1 puntos aprox > 4 horas (medio día)
  • 2 puntos aprox > 8 horas (1 día)
  • 3 puntos aprox > 16 horas (2 días)

Utilizo las aproximaciones como una guía de cuánto tiempo tomaría aproximadamente la tarea. Usar esto como una guía para calcular el valor de una semana de trabajo vale la pena. Mis sprints suelen durar 4 días. Entonces, en ese caso, el equipo sumará los puntos correspondientes a la semana equivalente aproximadamente.

Después de hacer un seguimiento del progreso de mis equipos después de 3 o 4 sprints, descubro que asignar tiempo contra los puntos se está volviendo inútil, ya que la cantidad total de puntos de historia que pueden completar aumenta a medida que pasan las semanas. La semana pasada fueron 6,2 puntos, esta semana esa cifra aumentó a 9, por lo general esto varía y estoy tratando de encontrar la velocidad promedio del equipo.

¿Debo medir el rendimiento de los equipos por la cantidad promedio de puntos que pueden completar en el sprint o adjuntar el tiempo a los puntos como una aproximación?

Gracias

Los puntos de la historia se pueden relacionar con el tiempo, pero no directamente. Mike Cohn lo describe como una distribución, por lo que 3 puntos equivalen, por ejemplo, a cinco días con una desviación estándar de X. Pero para llegar al punto en el que puedas hacer esa aproximación, primero debes haber ejecutado varios sprints sin pensar en la conversión de tiempo. De esa manera, su factor de conversión surgirá de la experiencia y no al revés. scrumalliance.org/community/spotlight/mike-cohn/june-2014/…
Si podemos mapear puntos en el tiempo directamente, ¿para qué sirve la velocidad? ¿Cuál es nuestro circuito de retroalimentación basado en evidencia para la corrección de ese mapeo si no es la velocidad?
Estás confundiendo claramente las historias de usuario con las tareas. Puede estimar tareas en horas ideales si lo desea, pero si está tratando de convertir puntos de la historia en horas ideales, está haciendo Agile Estimation Wrong® .

Respuestas (4)

Los puntos de historia son una medida ABSTRACTA de la complejidad de un incremento de producto. La idea es que la complejidad sea la misma para todos, mientras que el esfuerzo necesario para completarla varía según las habilidades y la experiencia del desarrollador. Entonces, calcular el tiempo a partir de los puntos de la historia no tiene ningún sentido para mí. Como ya está experimentando una velocidad creciente mientras las horas de trabajo se mantienen estables, puede ver que no existe una relación directa entre los puntos de la historia y el tiempo. Y no recomendaría medir el desempeño de un equipo por tiempo o puntos de historia. En su lugar, recomiendo observar la capacidad de trabajo (cuánto puede completar con éxito el equipo dentro de un sprint) y el enfoque (cuánto de su tiempo se invierte realmente en el objetivo del sprint).

"En su lugar, recomiendo observar la capacidad de trabajo (cuánto puede completar con éxito el equipo dentro de un sprint)": ¿cómo mido eso?
@ bobo2000 Querrá ver los puntos de historia comprometidos frente a los puntos de historia completados. La capacidad generalmente se basa en puntos.
@bobo2000 aquí hay un método que funciona muy bien para mí. Simplemente mida cuánto se hizo y cuánto tiempo tomó. pm.stackexchange.com/a/18279/21039

Así que potencialmente hay una serie de cosas sucediendo aquí.

Antes que nada; los puntos de la historia no deben correlacionarse directamente con las horas porque fluctuarán en función de una serie de factores. Después de varios sprints, puede tomar el promedio de los últimos sprints para determinar la velocidad de los equipos y usar eso para proyectar el trabajo en el futuro. Esa proyección también terminará siendo una estimación porque algunos trabajos se realizan antes y otros se realizan más tarde.

Habiendo dicho eso, tengo un par de observaciones/pensamientos.

  1. Mis sprints suelen durar 4 días.

Creo que sus sprints son demasiado cortos para obtener una lectura precisa del rendimiento de sus equipos a lo largo del tiempo. Por experiencia personal, esperaría que con frecuencia tenga remanentes o esté completando historias que no están siendo probadas. Creo que la mejor práctica es que los sprints no duren menos de 1 semana ni más de 4 semanas; y lo más común es que los sprints sean de 2 semanas.

  1. Después de hacer un seguimiento del progreso de mis equipos después de 3 o 4 sprints, descubro que asignar tiempo contra los puntos se está volviendo inútil, ya que la cantidad total de puntos de historia que pueden completar aumenta a medida que pasan las semanas.

El comportamiento de la producción de puntos de historia que aumenta de sprint a sprint es normal. Eventualmente se nivelará después de X cantidad de tiempo. Esto se puede atribuir a las fases de formación, tormenta, normalización y desempeño del crecimiento del equipo. Básicamente, en resumen, su equipo está descubriendo cómo ser eficiente mientras trabaja en conjunto.

  1. Tu escala de puntos de la historia me parece fuera de lugar. Consideraría usar números de Fibonaci si debe usar números, o si puede salirse con la suya [Pequeño, Mediano, Grande, Extragrande] o alguna variación [Eficiencia, Apartamento, Condominio, Casa, Mansión] con la que se sienta cómodo. En mi opinión, menos de 1 punto/medio día es una cantidad demasiado pequeña para estimar y si su equipo está usando esos puntos/escala para estimar, es probable que se equivoquen porque los desarrolladores generalmente son demasiado optimistas sobre cuánto se puede hacer.
Hizo 'Pequeño', 'mediano' y 'grande' antes: no se rastrea en el gráfico de quemado. Solo los puntos lo hacen. También solía hacer sprints de 1 semana, no iba bien con la parte interesada, así que tenía que hacer 4 días, todo lo que significaba era que tenía que asignar 4 días de trabajo.
@ bobo2000 ¿Cuántos desarrolladores hay en su equipo? ¿El trabajo se somete a control de calidad antes de que se marque como terminado? ¿Por qué la parte interesada se muestra inflexible acerca de los sprints de 4 días? Podría introducir el concepto de un punto de contacto a mitad de sprint con la parte interesada.
@dmeel si y si. Quiere sprints de 4 días porque lo frustra no poder realizar solicitudes de cambio, es decir, agregar cosas a los sprints una vez que han comenzado. Tenemos 2 desarrolladores y 1 probador de control de calidad
@bobo2000 Parece que necesita acumular trabajo pendiente. Si ya tiene un backlog que contiene varios sprints de trabajo, parece que su parte interesada realmente no está aceptando el proceso ágil. Si 4 días en un sprint es la forma en que debe ser, creo que continuará experimentando una gran fluctuación en los puntos promedio de la historia debido a la forma en que deberán escribirse sus historias para que encajen en un sprint de 4 días.
@bobo2000, ¿has considerado dejarlo volver a priorizar a mitad del sprint? Sé que suena loco, pero aquí fuera. Su PO quiere volver a priorizar a mitad del sprint, por lo que lo acompaña al tablero y lo deja. Pero tienes que señalar que no va a agregar nada al sprint sin quitar algo y que no puede quitar nada que ya haya comenzado. Rápidamente comenzará a priorizar mejor la acumulación si siente directamente el dolor que está causando al interrumpir el sprint. También asegúrese de realizar un seguimiento de los cambios en la capacidad en relación con el número de cambios en la prioridad.
@RubberDuck Ya he estado haciendo eso, pero se siente sucio cuando lo hago, ya que he visto a personas aquí decir que 'no se puede cambiar la acumulación de sprint' una vez que el equipo se compromete.
No hay una verdadera forma Agile @bobo2000. En mi opinión, no hay nada de malo en volver a priorizar el trabajo atrasado sobre la marcha, dado que no estás abandonando el trabajo que ya está en progreso. Sin embargo, tómalo con un grano de sal, trabajo con Kanban, no con Scrum. No existe el concepto de compromiso de sprint o acumulación de sprint en mi flujo de trabajo. Solo una acumulación de productos constantemente preparada y priorizada donde hacemos lo siguiente más valioso. Todo lo que puedo decir es que funciona para nosotros.

"¿Debería medir el rendimiento de los equipos por la cantidad promedio de puntos que pueden completar en el sprint o adjuntar el tiempo a los puntos como una aproximación?"

Creo que la mayoría de las personas asignan un tiempo a los puntos en su cabeza al estimar. Sin embargo, si intenta medir el desempeño por puntos de la historia completados, está alentando la sobreestimación de las tareas. Puedo hacer un sprint de un millón de puntos de historia fácilmente. ¡Aunque no te gustarán mis estimaciones!

Olvídate del 'rendimiento del equipo'. Los puntos de la historia se tratan de estimar cuánto tiempo llevará completar el proyecto. Tome el promedio por sprint y divida el resto por ese número para obtener la fecha de finalización esperada.

La razón principal de los puntos de la historia y otros sistemas de medición abstractos es evitar que pienses en términos de tiempo. Si va a asociarlos con el tiempo, simplemente deshágase de los puntos de la historia y vuelva a las horas hombre.

Al intentar relacionar los puntos con el tiempo, está subvirtiendo todo el sistema.

Puede medir el tiempo frente a los puntos y averiguar cómo tienden a equipararse y luego usar un gráfico de quemado para calcular cuántos puntos necesita eliminar para hacer una fecha de entrega, pero se supone que ese es su único control.

No puede decir cosas como "necesitamos hacer esta cita con estas funciones y no puede asignar los puntos a las funciones".

Gran parte del material original de XP se trataba de arreglar la gestión de proyectos, no el desarrollo de proyectos, y los puntos más importantes como este son los que se han filtrado en las ramificaciones como scrum. Leer algunas de las cosas originales de XP puede ayudar a comprender por qué funcionan algunos de estos procesos.

¿Podemos asignar tiempo a los puntos de la historia?
RespuestasAquíPolítica de privacidad1y, 0v