¿Quién consume estimaciones?

Las estimaciones son una herramienta que apoya la planificación. Cualquier persona que necesite tomar decisiones y elaborar planes sobre el futuro puede utilizar las estimaciones como una herramienta para hacer predicciones y averiguar cosas (sin saberlo con seguridad, solo se puede hacer una estimación; pero tener una estimación, cualquier estimación, a veces es mejor que no saber en absoluto).

Así por ejemplo:

• la alta dirección puede utilizar estimaciones para la planificación estratégica. Digamos que usted es una empresa de videojuegos que crea videojuegos y existe esta conferencia anual de juegos donde todos en la industria presentan lo último. Digamos también que a alguien se le ocurre una idea brillante sobre un nuevo videojuego. Faltan 6 meses para la conferencia. ¿Puedes construirlo? El equipo elabora una estimación y creen que tardará entre 8 y 10 meses. Ahora puede hacer planes más realistas sobre lo que podría entregar en esos 6 meses, en lugar de saltar y comenzar a construir el juego asumiendo que llegará a tiempo para la conferencia.
• un propietario de producto podría tomar decisiones sobre qué construir. Digamos que hay tres formas de construir una característica determinada. ¿Cómo puede el Product Owner elegir entre ellos? Bueno, tal vez le pregunten al equipo sobre el esfuerzo de cada uno y les den 30, 120 y 75 puntos de historia. Ahora el Product Owner puede tomar una decisión mejor informada e ir con la solución que se puede presentar a los usuarios más rápido (el 30 SP). Sin esta información, tal vez habrían elegido el segundo enfoque, que requiere cuatro veces más esfuerzo.
• como señaló @nvogel en otra respuesta, el equipo también puede usar estimaciones. Pueden usar el póquer de planificación para discutir historias y comprenderlas, y descubrir cómo hacer las cosas, y como un subproducto de este ejercicio, también atribuirles una estimación de SP. Luego, pueden usar los SP para planificar cuántas historias pueden caber dentro del sprint, o pueden usar la velocidad para calcular más tarde cuánto podrían necesitar para quemar otras características similares que suman una cierta cantidad de SP. Hay algunos equipos que cuentan historias en lugar de usar SP; el resultado final sigue siendo el mismo, suponiendo que pueda dividir todas las historias en aproximadamente el mismo tamaño para que simplemente pueda contarlas.
• etc.

Una vez más, las estimaciones son una herramienta que apoya la planificación y la toma de decisiones . Siempre que todos entiendan sus limitaciones y no se haga un mal uso o abuso de las estimaciones, entonces pueden ser una herramienta valiosa para determinar si sus objetivos son alcanzables. Si desea alcanzar algún objetivo en "6 meses" y la estimación arroja "al menos 9 meses", entonces eso es una indicación de que tal vez su objetivo es demasiado ambicioso y necesita encontrar otro plan para alcanzarlo.

Desafortunadamente, las estimaciones se malinterpretan, se usan mal y se abusa de ellas, y cuando la estimación da como resultado "al menos 9 meses" y no "6 meses", entonces obviamente la estimación es incorrecta, ¿verdad? Pero esta es una historia para otro momento.

Dado que menciona la planificación de sprints, asumiré que su equipo está utilizando iteraciones de longitud fija. Las estimaciones son para el equipo. El equipo debe incluir a la parte interesada principal o la persona que es responsable ante las partes interesadas, por supuesto (por ejemplo, el propietario del producto), pero el objetivo principal de la estimación es permitir que el equipo decida qué puede incluirse en un sprint determinado. Por lo tanto, las estimaciones no son muy importantes para las partes interesadas fuera del equipo porque la fecha prevista para cada incremento de producto siempre es el final del sprint, independientemente de cuál haya sido la estimación.

Lo que más debería preocupar a las partes interesadas es la cartera de productos priorizada y cualquier plan de lanzamiento asociado que indique qué elementos de la cartera de pedidos entrarán en qué sprint. En términos de Scrum, normalmente se entiende que las estimaciones son un componente del artefacto de la acumulación de productos.

El 7% del tiempo dedicado al refinamiento de la cartera de pedidos y la planificación de sprints no es excepcional; en mi experiencia, parece un poco ligero, pero depende tanto del tipo de trabajo y del tamaño del equipo que es difícil dar una pauta general. La Guía Scrum solía sugerir que hasta el 10 % del tiempo del equipo se dedicaba al refinamiento del trabajo pendiente, pero la última versión de la Guía ya no recomienda cuánto tiempo dedicar al refinamiento.

Solo otra perspectiva... En la organización en la que trabajo actualmente, nadie "consume" las estimaciones, y todos lo saben. Sin embargo, seguimos señalando historias/tareas. El objetivo del ejercicio, para esta organización, no son los puntos, sino la discusión para crear un entendimiento compartido sobre los elementos de trabajo, y es el descubrimiento de que los elementos deben dividirse aún más.

Para la implementación real de un artículo, no aceptamos 8, 13 o puntos más altos. Si un artículo termina con esos, los consideramos que aún no están completamente arreglados . Una vez que terminamos de arreglarnos (después de posiblemente dividir aún más algunos elementos), terminamos con 1, 2 o 3 puntos (5 puntos es excepcional); en realidad, ya no nos importa mucho en ese punto (ya que, de nuevo, nadie "consume" las estimaciones, y sabemos que se entiende y se desglosa). A partir de ahí, en realidad es una broma corriente con este equipo que "todo es un 2".

Todas las partes interesadas involucradas deben consumir estimaciones. Sin estimaciones, no hay forma de llegar a los valores de planificación. Sin valores de planificación, no hay forma de tomar una decisión convincente porque no hay forma de evaluar las inversiones, las desinversiones, el progreso, los beneficios, los costos y los riesgos. Todas esas cosas requieren estimación. Y cada parte interesada tiene algo de juego en algunas de esas áreas, incluido el hacedor con la clasificación más baja en el equipo.

No importa si es formal y da como resultado un producto de trabajo, las personas se dedican a estimar todo el tiempo, comenzando por cuánto tiempo llevará conducir al trabajo. Así que hazlo formal para que puedas medir.

Las estimaciones son un medio para un fin . El objetivo, en este sentido, es la previsibilidad .

¿Quién necesita previsibilidad? Prácticamente todos los involucrados en el proceso, por diferentes razones.

Las prácticas de ejemplo incluyen la planificación de póquer, la planificación de sprints, el desarrollo de planes de juego.

En la declaración anterior, asume que todas las actividades anteriores (entre otras) tienen la misma importancia. Eso está lejos de la realidad. nvogel menciona que se sugiere dedicar una cantidad considerable de tiempo al refinamiento de la cartera de pedidos. Eso está en el lugar. Sin embargo, vale la pena notar que el esfuerzo dedicado durante el refinamiento de la cartera de pedidos en la estimación de la historia debe ser mínimo .

Estimar una obra, especialmente en un contexto cambiante y dinámico, es una actividad derrochadora (ese es uno de los argumentos a favor de las #noestimaciones ). Es importante observar que existen diferentes "categorías" de despilfarro, y vale la pena analizarlas , pero no es el enfoque de esta pregunta.

En pocas palabras: los equipos deben invertir sus esfuerzos en minimizar el tiempo de estimación (planificación del póquer o cualquier otra actividad en torno a las estimaciones), pero aún así encontrar la cantidad correcta de esfuerzos en la estimación para que el equipo pueda ofrecer una previsibilidad confiable a sus partes interesadas.

Y, aquí hay una forma "disimulada" de verlo: cuando se le asigna la tarea de hacer una estimación, y si realmente intenta hacerlo , significa que está viendo cosas como "fallos potenciales en el trabajo" y " dependencias". Tal vez el número real que se te ocurra sea exacto, o tal vez no lo sea, pero el proceso mediante el cual trataste de llegar a una cifra defendible es importante. Para lograr con éxito cualquier cosa, debe estar "mirando hacia adelante" muy formalmente en todo momento. De lo contrario, "los ciegos guían a los ciegos" y "esa no es manera de construir una casa... ni siquiera una letrina".

Tal vez Sin importancia: "Creo que tardará 46 horas".

Muy Importante: "¿Por qué, exactamente, crees eso?"

Tenga en cuenta que incluso para un producto interno (= solo consumido dentro de la empresa), el costo de desarrollo generalmente no solo lo paga 'la empresa', sino varias partes interesadas internas, que tienen diferentes requisitos, prioridades y presupuestos. En otras palabras, quien pide un widget, lo paga. Para que eso sea posible, debe tener una idea de cuánto cuesta el widget específico.

Además, para permitir una priorización útil de diferentes deseos, es necesario conocer los tamaños relativos. El departamento A podría estar dispuesto/capaz de esperar tres días y dejar que el widget del departamento B se haga primero, pero es posible que no esté dispuesto/capaz de esperar tres meses.

Finalmente, la 'necesidad' de una función a menudo depende de la duración/costo: si una idea tarda un día en implementarse (y ahorra una semana de trabajo manual), la aceptarán, pero si lleva un mes implementarla. , prefieren hacer un esfuerzo manual de una semana.