¿Un tiempo estimado equivale a una promesa en Scrum?

Si una estimación no es una promesa, como propietario del producto, ¿cómo puedo entregar mis proyectos sin saber cuánto tiempo llevará?

¿Un equipo Scrum funciona de manera más eficiente si tratamos las estimaciones de tiempo como una promesa?

¿Cuánta investigación (preparación, esfuerzo para comprender el problema) en una historia es suficiente para obtener la estimación correcta?

¿Qué pasa con los problemas técnicos inesperados (problemas que realmente pueden alterar sus estimaciones iniciales) que surgen después de estimar su trabajo?

Las estimaciones no son promesas grabadas en piedra. Son la mejor conjetura que el equipo puede hacer sobre el esfuerzo requerido para completar la tarea / historia.

En respuesta a su pregunta "como propietario de un producto, ¿cómo puedo entregar mis proyectos sin tiempo de referencia?", La respuesta es que puede y debe tener tiempo como referencia (es decir , lanzará en una fecha determinada). Lo que no tiene es el alcance exacto que estará en la entrega.

Tenga en cuenta que lo que dije es cierto sobre todas y cada una de las metodologías que utiliza para impulsar su desarrollo. La diferencia entre Scrum y otras metodologías (como Waterfall) es que en Scrum este hecho se reconoce y se tiene en cuenta. Lo que hará, como OP, es priorizar su alcance y asegurarse de que el equipo, en cualquier momento dado sea:

1. Trabajando en la característica no entregada más importante (léase: valiosa) (tarea, requisito, historia del usuario)
2. Ha completado con éxito cada función que es más importante que la que está trabajando actualmente (esto se refiere a la Definición de hecho : cada historia completa se prueba, se acepta, no contiene errores y se completa la función).

Teniendo eso, ahora puede enviar, o entregar, en un abrir y cerrar de ojos, sabiendo que en cualquier momento dado , la última versión es el mejor producto que podría enviarse. Esto significa que en la fecha de su compromiso de lanzamiento original, entregará el mejor producto posible.

Por supuesto, esto no promete que consistirá en cada historia que solicitó que el equipo desarrolle, pero sabe que las restantes incompletas son, por supuesto, las menos importantes, que podrían entregarse fácilmente en una fecha posterior.

Además, las estimaciones realizadas por el equipo serán cada vez mejores, lo que le permitirá tener una idea temprana y sólida de cuál será el alcance al final del lanzamiento. Podrá enviar un buen producto sólido a tiempo, con algunas características menos importantes adicionales unas semanas más tarde (por supuesto, podrá estimar cuándo será).

En cuanto a la cantidad de investigación requerida, aquí hay una ley de rendimientos decrecientes en juego. Si rompes tus historias lo suficientemente pequeñas, entonces un poco de investigación debería darte una estimación lo suficientemente cercana. Si los entendió mal, lo modificará en el próximo sprint y las estimaciones serán mejores. En 3-4 sprints, en promedio, debe tener una buena idea de cuánto alcance se puede entregar antes de la fecha límite (o cuánto tiempo llevará completar el alcance).

Cuando estima los puntos de la historia en Scrum, debe saber lo suficiente como para poder comenzar a escribir la función. No se espera que la estimación sea completamente precisa, el objetivo de las metodologías de desarrollo ágil es que reconocen que no se puede predecir con precisión cuánto tiempo llevará el desarrollo.

La etapa en la que se compromete a entregar es cuando acepta las historias de la cartera de pedidos del producto en un Sprint. Prometes entregar esas historias dentro del sprint.

Si hace este compromiso, esto significa que está dispuesto a hacer algunas horas adicionales si parece que no va a cumplir su promesa. En realidad, algunas historias tomarán más tiempo de lo que pensabas y otras tomarán menos tiempo de lo que pensabas.

Cuando el equipo haya hecho suficientes estimaciones, mejorarán en eso.

También es posible que desee mirar ...

The Clean Coder (Libro) : hay un capítulo en este libro titulado "El lenguaje del compromiso" y también un capítulo sobre la estimación, que es realmente revelador.

Kanban : Kanban es más un estilo pull de desarrollo en ejecución: también hay combinaciones de Scrum y Kanban llamadas "Scrumban", que se basan en ambas ideas.

No.

La suma de todas las estimaciones en cada tarea completada en un sprint se llama velocidad . La velocidad se define como "número de puntos completados por sprint" donde "punto" es la unidad en la que su equipo estima.

Entonces, la velocidad le permite saber cuánto puede producir su equipo en el próximo sprint, suponiendo que usen el mismo método para estimar y que el equipo esté estable, etc.

Y así es como puede estar bastante seguro de lo que el equipo puede cumplir sin tener que hacer ninguna promesa al azar.

Las estimaciones de esfuerzo son una herramienta para pronosticar. Un pronóstico no es un compromiso ni una garantía. Los pronósticos se reevalúan continuamente para tener en cuenta los nuevos conocimientos y deben incluir posibles alternativas, como variaciones optimistas y pesimistas.

Estamos mirando hacia adelante en Agile. Los compromisos no agregan más valor a la planificación organizacional que los pronósticos.

Recomiendo altamente la estimación y planificación ágiles de Mike Cohn

Si una estimación no es una promesa, como propietario del producto, ¿cómo puedo entregar mis proyectos sin saber cuánto tiempo llevará?

No trabajas con una gran estimación, sino con muchas pequeñas estimaciones a nivel de historia. Muchos de los errores de estimación a nivel de historia se promedian. No puedes prometer contenido y fecha. Sin embargo, puede estar bastante seguro de que la parte superior de la cartera de pedidos se publicará (alternativamente, tendrá una fecha bastante precisa, pero no fija) en la que se pueda entregar toda la cartera de pedidos).

¿Un equipo Scrum funciona de manera más eficiente si tratamos las estimaciones de tiempo como una promesa?

No. Eso lleva a estimaciones de sacos de arena y convierte los gráficos de velocidad / consumo en datos inútiles, lo que impide que el equipo mejore.

¿Cuánta investigación (preparación, esfuerzo para comprender el problema) en una historia es suficiente para obtener la estimación correcta?

Depende de cuánto te preocupe la precisión. Puede pasar semanas preparando cada estimación con cuidado, o dar estimaciones rápidas de buena fe y esperar que se promedien los errores. La primera forma es prepararse para el fracaso, porque estimar algo que no ha hecho antes es realmente difícil, y la ingeniería de software se trata de cosas que no ha hecho antes.

Personalmente, no creo que haya muchos beneficios al tratar de obtener estimaciones muy precisas. Lo que intento hacer es asegurarme de que las estimaciones sean lo suficientemente precisas, es decir, que no me haya perdido algo que pueda hacer que una historia se desvíe de su estimación en un orden de magnitud. (Ver siguiente punto).

¿Qué pasa con los problemas técnicos inesperados (problemas que realmente pueden alterar sus estimaciones iniciales) que surgen después de estimar su trabajo?

Pequeñas iteraciones. Pedido atrasado ordenado. Pequeñas historias Lo peligroso es lo que no sabes que no sabes. La falta de experiencia en un problema dará como resultado estimaciones pobres, pero puede ajustar adquiriendo experiencia (más elaboración) o ir con estimaciones 'suficientemente buenas': todo se trata de gestión de riesgos.

Si una estimación no es una promesa, como propietario del producto, ¿cómo puedo entregar mis proyectos sin saber cuánto tiempo llevará?

Este es uno de los mayores malentendidos sobre Scrum. La pregunta "¿Cuánto tiempo durará mi proyecto?" asume que puede definir, en algún momento, exactamente lo que implicará el proyecto para completarlo. Pero toda la idea sobre Scrum es que reconoce que las cosas que aprende sobre un proyecto, a medida que trabaja en el proyecto, van a cambiar la definición del proyecto.

La forma más común de definir un proyecto es enumerar las características que tendrá. Normalmente, un proyecto se completa cuando se han implementado todas las características. Pero, ¿qué pasa si, mientras trabaja en un proyecto, se da cuenta de que 5 de las características identificadas al inicio no serán necesarias, pero hay 7 características que la gente pensó en los primeros 6 meses que realmente deberían incluirse? ¿Qué hace eso a la pregunta de cuánto tiempo tomará?

Otro factor es que las cosas que aprende cambiarán su comprensión de cómo implementar ciertas características, y a medida que se acerque a implementar cada característica, sus estimaciones van a cambiar. Personalmente, me resistiría a poner estimaciones numéricas en cualquier cosa que no se aproxime al horizonte de la implementación, tal vez utilizando estimaciones descriptivas como "pequeño", "pequeño", "mediano", "grande" y "enorme" o "épico". Entonces no estás implicando una precisión mayor de la que eres capaz de estimar.

A decir verdad, "¿Cuánto tiempo llevará?", No responde más que, "¿Qué será cuando esté hecho?". Los contadores y los empresarios tradicionales odian esto, por eso es muy difícil alejarse de Waterfall en algunas organizaciones.

También es la razón por la que necesita hablar mucho sobre la velocidad y las métricas con un grano de sal. Los proyectos de software tienen una especie de Principio de incertidumbre de Heisenberg integrado en ellos, y si pasa demasiado tiempo ajustando las medidas, terminará con un sinsentido extremadamente preciso.

Entonces, no, una estimación no es una promesa. Es un estimado. La "promesa" es el compromiso que el Equipo hace para completar un cierto número de características o historias en un Sprint en particular.

Las estimaciones deben ser lo suficientemente precisas como para permitir que el Equipo identifique cuántas características (o historias) pueden caber cómodamente en un Sprint. Incluso más importante que la precisión en las estimaciones es la consistencia, porque el Equipo aprenderá cuánto valor de trabajo de las estimaciones pueden caber en un Sprint, incluso si el trabajo real resulta ser generalmente el doble de lo que estimaron. Mientras esté constantemente desactivado, podrán planificar.