Me di cuenta en las reuniones de scrum, que los desarrolladores a menudo dan estimaciones realistas sobre las historias. Sin embargo, incluso las historias más simples requieren mucho esfuerzo para la configuración, la configuración de componentes de terceros, las pruebas y la compilación final, y el sistema ha acumulado bastante deuda técnica, por lo que las estimaciones a menudo parecen demasiado altas para el propietario o la administración del producto.
La orden de compra con frecuencia trata de vencer esas estimaciones, como: "¿Qué, quieres 13 puntos de historia [4 días] por esta historia, esto no puede ser! No puedo explicar esto a la gerencia, alguien debería poder codificar esto con 3 SP [en 4 horas] ". Como resultado, los desarrolladores se tuercen los brazos para comprometerse con una estimación de 5 u 8 puntos de historia [1.5 a 2 días] (las estimaciones de Scrum todavía se toman como compromisos, no solo como pronósticos).
Por supuesto, sin ningún plan para reducir las expectativas (principalmente en pruebas y calidad), estos sprints frecuentemente fallan. La estimación de los desarrolladores es honesta y realista, y superar la estimación no supera el trabajo real que se debe hacer.
Uno puede decir: "¡No debes hacer un compromiso imposible, solo porque alguien te obliga a hacerlo!" Pero, en mi opinión, el trabajo de un desarrollador es el diseño y codificación de software, ¡no negociar ni resistir la presión! Puede haber tomas de todos los comercios, generalmente aquellos que tratan directamente con clientes externos, ¡pero esta no es la mayoría de los desarrolladores de oficina!
Para mí, esta práctica solo hace que los programadores se vean como imbéciles, causa fallas constantes en el sprint y evita estimaciones realistas, además de buscar mejoras reales.
¿Qué dicen las pautas de Scrum sobre este tema, o dicen algo al respecto?
EDITAR: tiempos reemplazados por puntos de historia. Me refería a la fase de estimación inicial con Planning Poker y los puntos de la historia, no a la planificación detallada de la tarea. Simplemente puse los días / horas allí, porque a veces era un diálogo típico como este, también con tiempo en lugar de puntos. Perdón por cualquier confusión! Los ejemplos de puntos de la historia representan períodos de tiempo más largos que los ejemplos de tiempo.
EDITAR 2 Actualmente no hay un scrum master dedicado, y el PO toma ese papel, cuando se trata de reuniones de estimación. Por lo tanto, es probable que el conflicto de roles empeore esta negociación inapropiada, ya que aparece como una autoridad, en lugar de un maestro scrum neutral o desarrollador. Quizás, esto se puede solucionar tomándolo como un participante parcial en lugar de un "maestro", siempre que no haya ninguno disponible.