Estimar elementos de trabajo dependientes en Scrum

Escenario: Digamos que hay dos elementos A y B en la cartera de productos de un equipo Scrum. Desde el punto de vista de la OP, B tiene más valor para el cliente que A y, por lo tanto, tiene una clasificación más alta. Cuando le pregunta a un desarrollador el tiempo estimado para trabajar en estos elementos, proporciona la siguiente información:

  • A tarda 2 dias
  • B tarda 2 días; pero si A se hace antes, entonces B solo toma 1 día (ya que también se realiza un trabajo de requisito previo en A)

Esto significa que, cuando B se hace primero y luego A, el tiempo total para esos dos elementos de trabajo es de 4 días. Pero cuando A se hace antes que B, el tiempo total de trabajo será de 1 día. Pero esto estará en contra de las prioridades ya que B está clasificado más alto que A.

Suponga que ambos elementos de trabajo no se pueden completar en el mismo sprint. De lo contrario, no hay necesidad de esta pregunta :)

Pregunta real: ¿Deben las estimaciones incorporar dicha información?

Nuestro pensamiento: Hemos estado discutiendo esto ayer sobre si las estimaciones para los elementos de trabajo deben tener esto en cuenta. ¿Debe una OP tener esta información para reordenar la cartera de productos en función de esta información? Llegamos a la conclusión de que las estimaciones no deben contener esta información, es decir, B toma 2 días, punto.

Las razones para eso son:

  • La cartera de productos se ordena en función del valor del cliente
  • Cuando B comparte una tarea con A, ¿qué pasa con los otros elementos? Probablemente habrá más tareas como esa que deben ser analizadas. Esto dará lugar a discusiones de larga duración sin un resultado fiable.

¿Nos estamos perdiendo algo? o es nuestro pensamiento correcto? Probablemente haya más razones para agregar a esa lista.

Respuestas (3)

Yo diría que tu pensamiento es correcto.

Sus estimaciones deben basarse en el código base existente actualmente y no en escenarios hipotéticos. En su ejemplo, es posible que la Historia A nunca se complete y que continúe siendo empujada hacia abajo en la lista de prioridades a medida que haya nueva información disponible.

Además de eso, también sería lógico que hacer A antes de B hace que B sea más rápido porque se completa el trabajo preliminar que hacer B antes de A haría que A sea más rápido debido a ese trabajo preliminar común.

Idealmente, los elementos de la cartera de pedidos son independientes entre sí, en cuyo caso no surgiría esta pregunta.

Cuando hay dependencias técnicas, el equipo de desarrollo y el propietario del producto deben decidir cuál es el mejor enfoque.

Algunas cosas a considerar al decidir sobre un enfoque:

  • Si un artículo de mayor valor se mueve más adelante en la cartera de pedidos, también se retrasará el momento en que comienza a entregar valor comercial. Depende del propietario del producto decidir sobre el impacto de ese retraso.
  • Por lo general, es mejor haber entregado valor que trabajo en progreso. Por lo tanto, retrasar la entrega de valor para aumentar la eficiencia general de la entrega a veces puede ser un error.
  • La eficacia de comenzar con el elemento B antes del elemento A supone que ambos elementos se completarán. Siempre existe la posibilidad de un cambio en las prioridades y, como resultado, es posible que el elemento A no se realice.

Vale la pena recordar que el enfoque Agile enfatiza la optimización de la entrega de valor comercial en lugar de optimizar la eficiencia del desarrollo.

Estas dos cosas pueden sonar igual, pero al responder al cambio pueden no serlo. A veces es más efectivo comprometer la eficiencia del desarrollo para responder más rápidamente al cambio.

Acabo de actualizar mi pregunta porque no estaba lo suficientemente claro acerca de las dependencias. Lo siento por eso. En realidad, no estoy hablando de dependencias, sino de tareas/requisitos previos compartidos (más o menos).
Eso puede ser incómodo. Por ejemplo, cuando se trabaja con informes comerciales, hay muchas tuberías antes de que se complete el primer piso. Los equipos con los que he trabajado normalmente han tenido una 'historia de arranque'. Esa es una historia que proporciona una pequeña cantidad de valor comercial (por ejemplo, proporciona una medida menor en un informe) y esa historia termina siendo bastante grande, ya que anticipamos poner mucha plomería al completarla. Las historias posteriores son más simples y, por lo tanto, terminan teniendo estimaciones más pequeñas. Incluso este enfoque es cuestionable. El peligro es que terminemos con historias que no se pueden hacer fuera de turno.

Esto lo decidiríamos en la planificación del sprint. Si B realmente depende de A, entonces la respuesta es fácil.

Si hacer A hace que B sea menos "doloroso", intente ponerlos en el mismo sprint, teniendo eso en cuenta y reduciendo el esfuerzo para B en consecuencia.

Entonces sí, la dependencia se incorporaría a la estimación, en mi humilde opinión.

Si A y B siguen siendo iguales... bueno, haz lo que quieras.

Acabo de actualizar mi pregunta porque no estaba lo suficientemente claro acerca de las dependencias. Lo siento por eso. En realidad, no estoy hablando de dependencias, sino de tareas/requisitos previos compartidos (más o menos).
Estimar elementos de trabajo dependientes en Scrum
RespuestasAquíPolítica de privacidad1y, 0v