Scrum está pensado como un marco simple pero suficiente para la entrega de productos complejos. Scrum no es una solución única, una bala de plata o una metodología completa. En cambio, Scrum proporciona los límites mínimos dentro de los cuales los equipos pueden autoorganizarse para resolver un problema complejo utilizando un enfoque empírico. Esta simplicidad es su mayor fortaleza, pero también es la fuente de muchas malas interpretaciones y mitos que rodean a Scrum. En esta serie de publicaciones, nosotros, sus ” Cazadores de mitos “, Christiaan Verwijs & Barry Overeem, abordaremos los mitos y malentendidos más comunes. 

PD: Las grandes imágenes son de Thea Schukken.

Hoy abordamos la idea de que el trabajo en el Product Backlog debe estimarse en Story Points. La mayoría de los equipos con los que trabajamos hacen esto, y realmente no hay nada intrínsecamente malo en ello. El mito comienza cuando las personas malinterpretan el propósito de la estimación en Scrum y los Story Points se convierten en un fin en sí mismos.

Para aquellos que no están familiarizados con Story Points; los equipos que utilizan esta técnica estiman el esfuerzo con estimaciones relativas en lugar de estimaciones basadas en el tiempo (por ejemplo, horas, días). Esto generalmente se hace con una versión simplificada de la secuencia de Fibonacci (0, 1, 2, 3, 5, 8, 13, 20, etc.). Los números no tienen significado en sí mismos, sino solo en relación con otros elementos. Por lo tanto, un elemento de 5 puntos requiere aproximadamente el doble de esfuerzo del equipo que un elemento de 3 puntos, y así sucesivamente. Existen varios métodos para estimar Story Points, incluidos Planning Poker y Magic Estimación .

Aunque el uso de Story Points es la técnica más difundida, podríamos generalizar fácilmente esta publicación para incluir estimaciones en horas, días ideales o tallas de camisetas para el caso.

Rompiendo el mito

Al igual que con las publicaciones anteriores, comencemos con lo que dice la Guía Scrum sobre la estimación. Aunque establece que “el trabajo puede ser de diferente tamaño o esfuerzo estimado”, no prescribe cómo debe hacerse esta estimación. Aunque los Scrum Teams deberían aplicar algún tipo de ‘estimación’, no se mencionan los Story Points, las horas, los días ideales, el instinto, las tallas de las camisetas o cualquier otra unidad para el caso. La Guía Scrum nos recuerda que debemos utilizar un enfoque que respete la complejidad del desarrollo de software y no dejar que la estimación reemplace la importancia del empirismo en sí.

Así que podemos acabar con este mito fácilmente solo con la Guía de Scrum. Pero una explicación más completa ayuda a comprender mejor por qué

El propósito de la estimación en Scrum

En los enfoques basados ​​en planes, las estimaciones se utilizan para llegar a los presupuestos y determinar las fechas de entrega. Suponiendo que las estimaciones sean precisas, nos brindan un medio para administrar los riesgos (financieros) de gastar demasiado dinero o gastar dinero en cosas incorrectas.

El propósito principal de las estimaciones en Scrum es brindar a los equipos de desarrollo una idea aproximada de la cantidad de trabajo que pueden realizar en un Sprint. Esto requiere una conversación entre miembros; ‘¿Qué implica?’, ‘¿Cómo debería funcionar?’ y ‘¿Qué trabajo se necesita?’. Aunque el equipo de desarrollo se compromete a lograr el objetivo del Sprint, no se compromete a completar todo este trabajo dentro del Sprint. Incluso dentro de un único Sprint, es probable que surjan problemas y conocimientos inesperados.

Esto subraya que el papel de las estimaciones es bastante diferente en Scrum, y algo con lo que las personas que provienen de una perspectiva basada en planes a menudo luchan. Scrum se basa en la observación de que el desarrollo de software es un esfuerzo muy complejo, lo que hace imposible llegar a estimaciones precisas. En entornos complejos, lo que sucederá en el futuro (cercano) es en gran parte desconocido. A medida que trabajamos juntos para descubrir tanto el problema como la solución (más adecuada), surgirán nuevos y mejores conocimientos y problemas inesperados. En lugar de confiar en estimaciones para pronosticar y controlar lo que sucede en el futuro, deberíamos usar el proceso empírico de Scrum para capitalizar el cambio en lugar de controlarlo. Como observa la Guía de Scrum: “Solo lo que ya ha sucedido puede usarse para la toma de decisiones con miras al futuro”.

Utilice el proceso empírico de Scrum para capitalizar el cambio en lugar de controlarlo Clic para tuitear

Esto nos proporciona cuatro conocimientos importantes con respecto a las estimaciones

Las estimaciones precisas son imposibles, ya que incluso la técnica más completa y detallada no puede cubrir todos los escenarios, problemas potenciales, conocimientos que pueden surgir y factores externos que influyen en nuestro trabajo. Por no hablar de eventos completamente inesperados (llamados ‘cisnes negros‘);

Un presupuesto no puede ser garantía. “ Una estimación es simplemente una predicción basada en información conocida y entradas en un momento dado” – Ilan Goldstein;

El tiempo que dedicamos a la estimación es una forma de desperdicio . Las estimaciones son, en el mejor de los casos, inexactas y es probable que el trabajo que estamos estimando cambie drásticamente a medida que nuestra comprensión cambie con el tiempo (o incluso se elimine del Product Backlog);

Las estimaciones en sí mismas son el resultado de una conversación necesaria dentro del Equipo de Desarrollo para llegar a un entendimiento compartido.

En lugar de dedicar mucho tiempo y esfuerzo a la estimación, es mejor dedicar ese tiempo a crear software valioso y utilizar el proceso empírico de Scrum para aprender. La pregunta ahora es; ¿Qué método de estimación es “lo suficientemente bueno” para ayudar a los equipos de desarrollo a seleccionar una cantidad de trabajo factible para un Sprint y tener una idea de lo que se necesita, al tiempo que requiere el menor tiempo y esfuerzo posible?

Las estimaciones basadas en el tiempo (horas, días ideales) son una opción. Una gran desventaja es que tienden a mantener la ilusión de precisión y previsibilidad y, a menudo, se interpretan como tales. Otra desventaja es que su ilusión de precisión a menudo lleva a los equipos a una ‘parálisis del análisis’, donde todos los detalles deben discutirse en profundidad para llegar a una estimación detallada.

Las estimaciones basadas en el tiempo mantienen la ilusión de precisión y previsibilidad Clic para tuitear

Esta es la razón por la que Extreme Programming popularizó el uso de la estimación relativa , en particular ‘Story Points’ . Las estimaciones relativas no se basan en unidades de tiempo y evitan toda pretensión de detalle y precisión. Pero pueden proporcionar a los equipos de desarrollo una guía sobre la cantidad de trabajo que pueden completar dentro de un Sprint. Toma este ejemplo:

Suponga que un equipo de desarrollo ha estado trabajando en conjunto durante 20 Sprints. El proceso empírico de Scrum les ha enseñado que pueden completar, en promedio, 35 puntos de trabajo (su llamada velocidad). Basado en lo que ya sucedió, el Equipo de Desarrollo tiene una idea aproximada de la cantidad de trabajo (alrededor de 35 Story Points) que pueden realizar en su próximo Sprint. Además, el Product Owner puede utilizar estos datos empíricos (~ 35 Story Points) para crear un pronóstico aproximado de funciones o versiones específicas. Si un equipo de desarrollo puede asumir 35 Story Points de trabajo por Sprint, y hay 350 Story Points de trabajo en el Product Backlog, no sería descabellado anticipar otros 10 Sprints para completar el Product Backlog en su estado actual.

Así que los Story Points son un enfoque ligero para tener una idea aproximada de cuánto trabajo se puede completar en un Sprint. Sin embargo, sigue siendo un indicador aproximado. Pero al menos se basa en lo que ya sucedió y no en lo que esperamos que suceda. Ciertamente, la estimación en horas o días ideales sigue siendo una opción, pero los equipos deben ser conscientes de sus desventajas.

Otras formas de estimar, si realmente quieres

A pesar del atractivo inicial de Story Points, se abusa de ellos fácilmente. Por ejemplo, a menudo se utilizan para comparar Scrum Teams en su desempeño. O las organizaciones imponen requisitos burocráticos y administrativos para estimar todos y cada uno de los elementos del Product Backlog con Story Points. Por eso, a menudo recomendamos a los equipos que utilicen enfoques aún más simples:

• Usa la cantidad de elementos por Sprint como guía para seleccionar una cantidad de trabajo factible para un Sprint. Por ejemplo, un equipo de desarrollo puede saber por experiencia que puede completar entre 6 y 8 elementos por Sprint. Esto requiere que los artículos se desglosen aproximadamente al mismo tamaño;
• Use cubos de tamaño como guía, donde el equipo de desarrollo clasifica los artículos en términos de tamaño (por ejemplo, grande, mediano, pequeño). Puede saber por experiencia que puede completar 1 artículo grande, 2 a 3 artículos de tamaño mediano y 4 a 6 artículos de tamaño pequeño;
• Simplemente use la intuición combinada del Equipo de Desarrollo para determinar si se seleccionó suficiente trabajo para el Sprint;

Aunque estos enfoques pueden complicar el pronóstico basado en resultados históricos en comparación con Story Points o estimaciones basadas en el tiempo, son alternativas viables que se ajustan bien al Scrum Framework y su propósito de estimación.

¿Por qué estimar en absoluto?

Si la estimación es en gran medida un desperdicio, tiene sentido preguntarse: “¿Por qué molestarse?”. Este punto lo plantea el movimiento #NoEstimates. Animan a construir pequeñas cantidades de valor de forma incremental, lo que lleva lo más rápido posible a un producto de envío deseado, sin pasar horas interminables tratando de predecir el futuro. En otras palabras, cambian el enfoque para optimizar el flujo de trabajo durante un Sprint. Usar Kanban dentro de Scrum es un excelente ejemplo de esto, y algo que recomendamos encarecidamente.

Sin embargo, alguna forma de estimación puede resultar útil. En muchas situaciones, ayuda a enfocar la conversación dentro de un equipo de desarrollo en lo que se necesita para un artículo en particular. Tener que llegar a algún tipo de estimación, a menudo ayuda a desencadenar el tipo correcto de discusiones: “¿Qué se necesita?”, “¿Podemos encontrar una solución más simple?”, “¿Hemos considerado X?”. La estimación no se trata tanto de las estimaciones, sino de las discusiones que desencadena. Se trata de tener una conversación, idealmente con el cliente real, y crear un entendimiento compartido.

"La estimación suele ser útil, las estimaciones a menudo no lo son". – Esther Derby Clic para tuitear

Si quieres profesionalizarte en agilidad a través de Scrum te invitamos a las próximas fechas abiertas al público

Consejos

• Hagas lo que hagas en términos de estimación, asegúrate de hacerlo con todo el equipo de desarrollo. El proceso de estimación no se trata únicamente del número resultante, sino quizás incluso más de la comunicación que tiene lugar dentro del equipo para llegar a una comprensión compartida del trabajo involucrado. Al poner en común su pericia, creatividad y experiencia, es más probable que identifique problemas o descuidos potenciales;
• Algunos equipos quieren ceñirse a estimaciones basadas en horas porque les parece “más real” o más fácil de estimar. Un enfoque es crear cubos de tiempo con intervalos crecientes (por ejemplo, 1 hora, 2 a 3 horas, 3 a 5 horas, 5 a 8 horas). Esto comunica más claramente la creciente incertidumbre como resultado de una estimación más alta;
• Explore diferentes técnicas y determine qué funciona mejor para su equipo de desarrollo y requiere el menor esfuerzo y tiempo posible;

Conclusiones

En esta publicación, derrotamos el mito de que Scrum requiere que el trabajo sea estimado en Story Points. Aunque es una técnica útil y utilizada por muchos equipos Scrum, no es de ninguna manera la única técnica. Y, lamentablemente, lo hemos visto abusado con tanta frecuencia que generalmente recomendamos técnicas más simples. Usamos esta publicación para describir algunas alternativas y explicar por qué los Story Points se volvieron frecuentes. Al hacerlo, también explicamos cómo la estimación cumple un papel diferente en Scrum en comparación con los enfoques basados ​​en planes.

Sobre todo, recuerde la cita de Esther Derby: “La estimación suele ser útil, las estimaciones a menudo no lo son”. Cuanto más compleja es la actividad en cuestión, más importante se vuelve la comunicación y la colaboración.

Respete la complejidad del desarrollo de software y no permita que la estimación reemplace la importancia del empirismo en sí. Clic para tuitear

¿Qué piensas de este mito? ¿Estás de acuerdo con esta publicación o no? Háznoslo saber en los comentarios.