¿Por qué usar puntos de historia en lugar de horas para estimar?

El uso de puntos es una versión de lo que a menudo se denomina " Tamaño relativo ". Para una perspectiva inicial muy recomendable, mira este video y luego regresa. La mayoría de los usos de la estimación de puntos de la historia lo limitan al extremo inferior de la serie de Fibonacci: 1, 2, 3, 5, 8, 13 porque el objetivo es agrupar cosas de tamaño general similar en lugar de buscar una estimación muy precisa.

Los puntos de la historia a menudo tienen en cuenta tres aspectos diferentes al estimar: Complejidad, Esfuerzo y Duda. Esto les permite capturar de manera más efectiva las fuentes de variación que harán que una estimación basada en horas sea incorrecta.

La complejidad son las "cosas que tenemos que resolver". Sabemos que podemos resolver el problema, y ​​probablemente tengamos una buena idea de cómo lo abordaremos, pero aún tenemos que resolverlo.

El esfuerzo es la gran cantidad de cosas que hay que hacer. Para mí, ese ejemplo es la configuración de listas de SharePoint, porque sabía exactamente cómo resolver todo y sabía cuántas había, pero aun así me tomó tiempo revisarlas.

La duda es sobre las cosas que en realidad no sabemos si se pueden hacer. Podemos sospechar que estamos en el camino equivocado, que la tecnología no está a la altura, o algún otro factor que nos haría agitarnos por un tiempo antes de descubrir si realmente podemos hacer el trabajo.

La mayoría de las historias contienen una combinación de los tres y, por lo tanto, es útil tener un lenguaje común para que cuando diga "es un ocho", pueda seguir con "debido a la complejidad del algoritmo foobar" o "porque no soy Estoy seguro de que nuestro caché ya está configurado para manejar eso".

La estimación puntual final es solo una forma de decir " teniendo en cuenta todas estas cosas, creo que esto es más grande que la mayoría de las cosas que llamamos tres y más pequeño que la mayoría de las cosas que llamamos ocho, por lo que debe ser un cinco "

Yo no diría que los puntos son mejores. Esta es una técnica enfocada en un aspecto diferente de la estimación. Puede resultar que su estimación puntual apeste más. Ten eso en mente.

1. Al estimar en horas te enfocas en responder a la pregunta "¿Cuánto tiempo nos puede llevar?". Entonces, básicamente, es más o menos adivinar, según su experiencia previa.

2. Al estimar en puntos , se enfoca en los tamaños relativos o la complejidad de las tareas/historias/lo que sea estimado. Por lo general, toma algunas de sus tareas y les aplica uno de los valores de puntos, y luego, para cada tarea, intenta responder a la pregunta "¿Qué tan grande es en relación con los que ya he estimado".

La clave de la estimación de puntos es que necesita medir realmente cómo se relacionan las estimaciones con el tiempo. Después de un tiempo inicial en el proyecto (especialmente cuando comienza con estimaciones de puntos), aprende cuántos puntos puede entregar en cada iteración o período de tiempo fijo. Esto le proporciona la base para planificar futuras versiones.

Si busca en este foro, también encontrará al menos algunos métodos de estimación en puntos. Pruébelo y vea por sí mismo si se vuelve más preciso para usted.

La esencia de la estimación en puntos es que se basa en el tamaño relativo, mientras que la hora es una medida absoluta. Mi tarea de 10 horas podría ser su tarea de 5 horas, pero ambos estaríamos de acuerdo en que crear una página de registro de usuario normal es una tarea más pequeña en comparación con la creación de un módulo de carrito de compras, por lo que este enfoque reduce la variabilidad en las estimaciones.

Otorgue puntos en función de cuán grande/compleja es la tarea/historia y cuánto hay, por ejemplo, hay una tarea que es bastante simple pero debe realizarse varias veces, entonces esa tarea/historia recibirá más puntos. .

Para empezar, debe elegir un par de tareas/historias que sean de complejidad/tamaño medio/promedio. Asígneles algunos puntos de su rango de puntos seleccionado (generalmente series de Fibonacci). Estas tareas/historias se convierten en sus tareas/historias de referencia. Ahora asigne puntos al resto de las tareas en función de cuán compleja/grande sea cada tarea en relación con sus tareas de referencia. Las tareas más grandes obtienen puntos más altos que los puntos otorgados a las tareas de referencia. Al final del ejercicio de estimación (generalmente realizado con Planning Poker), sumas todos los puntos para obtener el total de puntos estimados para ese proyecto.

Después de completar un par de proyectos, tendría un historial de cuántos puntos cubre su equipo en un intervalo de tiempo específico. Esta será la velocidad del equipo. El punto clave aquí es que no cambias el tamaño del equipo. Los miembros del equipo pueden ser reemplazados pero no preferidos.

Se trata de abstraerse de una falsa realidad.

Los puntos son mejores que las horas porque obligan a todos los involucrados, especialmente a las partes interesadas no técnicas, a internalizar que crear su propio software no es como comprar funciones en una tienda.

Para bien o para mal, las partes interesadas del negocio casi siempre quieren saber "cuánto costará cada una de mis funciones". Por supuesto, generalmente comienzan con descripciones de características de tan alto nivel que cualquier estimación de precio, en horas o dólares, será ridículo.

La agilidad en general y el sistema de puntos en particular obligan a las partes interesadas a participar en el proceso de pasar de una solicitud comercial de alto nivel a una implementación iterativa refinada.

Como siempre, no hay una respuesta simple a esta pregunta. Yo diría que debes elegir lo que mejor te funcione . Sin embargo, como dices, trabajar con horas no funciona para ti.

En mi equipo era el aspecto psicológico de trabajar con puntos. Cuando las personas están estimando en puntos se sienten más cómodas, porque no existe una medida simple, que 1 punto = 1 hora, por lo que no serán sancionados si les tomará más tiempo terminar la tarea de lo declarado.

Otra cosa es que al trabajar con puntos (1,2,3,5,8,13,20) o tallas (S, M, L, XL) solo defines la complejidad de la tarea. La velocidad muestra cuántos puntos puede poner en la iteración, pero la velocidad cambia .

Y que trabajar con puntos es menos frustrante : si estimó mal, su velocidad disminuirá.

Aunque probablemente no sea una característica prevista, uno de los beneficios de usar puntos desde la perspectiva de un gerente es que las tareas se miden por complejidad en lugar de por tiempo, lo que le permite ver fácilmente quién en el equipo trabaja más rápido que los demás. Por ejemplo, sabe que a la persona A le toma 2 horas hacer algo, pero a la persona B le toma 10 horas (para una tarea en particular; tal vez sea lo contrario para otra tarea). Si la persona A estimó 2 horas y luego se ausentó por enfermedad, la persona B estaría 8 horas atrasada con respecto a la estimación antes incluso de comenzar. Pero si le das puntos y luego promedias para el equipo, es más probable que alcances tu marca en general.

Hay dos razones por las que me gustan los puntos sobre las horas.

Las horas tienen una precisión implícita y tienden a verse como 100% precisas, todos los humanos entienden lo que es una hora, así que si dices 10 horas, deben ser diez horas. Para compensar esto, la persona que realiza la estimación incorporará algo de "tiempo extra" para compensar las incógnitas. Es solo la naturaleza humana que no quieren ser responsables de una estimación cuando no tenían todos los datos necesarios.

El problema con esto es que cuanto mayor sea la tarea/historia, mayor será la complejidad y más tiempo llevará desarrollar una estimación verdaderamente precisa. En algún momento simplemente no vale la pena el esfuerzo. Especialmente cuando usted está mirando el trabajo que no se hará durante varios meses.

Los puntos, por otro lado, tienen una imprecisión implícita "aceptable" ya que solo son relativos entre sí.

Al usar la serie de Fibonacci: 1, 2, 3, 5, 8, 13, etc., el equipo puede compensar tanto la complejidad de un proyecto como el esfuerzo esperado. A medida que los números aumentan, se incorpora la confusión de la estimación. No se pierde tiempo tratando de determinar si es un 9, un 10 o un 11, si es más grande que lo que el equipo llama 8 y más pequeño que lo que el equipo llama un 20 entonces es un 13. A medida que la historia se acerca a ser aceptada en una iteración, se desglosa y refina aún más y mejora la precisión de la estimación.

Mediante el uso de este método, el trabajo a corto plazo se puede estimar con un alto grado de confianza, cuanto más avanza en el cronograma, la confianza disminuye, pero el equipo aún tiene una buena idea del esfuerzo involucrado sin gastar una cantidad excesiva de tiempo rompiendo escribir una historia que tal vez nunca se haga debido al cambio de prioridades.

jeff

Para mi equipo, con frecuencia se colgaban al estimar las horas para obtener detalles minuciosos absolutamente correctos, pero hacían conjeturas descabelladas en otras tareas. El resultado fue una variabilidad muy alta en la entrega de historias. Cuando cambiamos a puntos, el equipo comenzó a hacer estimaciones de historias completas basadas en la complejidad general y su velocidad se volvió mucho más predecible.

Por lo general, las estimaciones de horas se pueden convertir en puntos, pero las estimaciones de puntos, por lo general, no se pueden volver a convertir en horas.

Tenga cuidado, una vez que cambie a las estimaciones de puntos, no habrá una manera fácil de volver a usar las horas.

¿Cuándo cambiaría a puntos y otros sistemas relativos? Cuando las horas dejan de trabajar para ti. Si encuentra que las estimaciones de horas no le dan una buena idea del tiempo que llevará completar un proyecto, aún puede hacerse una idea de la complejidad relativa con los puntos y otros sistemas. Esto le permite ignorar la dimensión del tiempo y obtener información de complejidad.

Sin embargo, según mi experiencia, tendrá que volver a las estimaciones de tiempo en algún momento, sin importar lo que esté haciendo. Entonces, si está cambiando a puntos, descubra una manera de estimar también el tiempo.

Todo esto es bastante engañoso. El hecho es que, en nuestra cabeza, tendemos a convertir los puntos nuevamente en horas una vez que conocemos nuestra velocidad. Los puristas pueden hablar de puntos todo el día, pero son solo personas que intentan ser engreídas. Realmente, la clave aquí es alentar a las personas que estiman a pensar en términos relativos; por ejemplo, este proyecto es tan complejo como ese proyecto y ese proyecto tomó, x hourspor lo que este proyecto debería tomar y hours.

Puede pensar que está logrando algún truco psicológico genial, pero si su gente vale algo, ya están haciendo cálculos mentales en su cabeza.

Los puntos de historia funcionan mejor cuando existen las siguientes condiciones:

1. La organización tiene una alta tolerancia al riesgo que permite grandes variaciones entre lo planificado y lo real durante el comienzo de un proyecto nuevo y difícil de estimar.
2. Los equipos trabajan en un sistema cerrado, donde todos los equipos siguen de forma ágil y los equipos son estables. No se comparten recursos y no se requiere que los equipos interactúen con equipos usando otros métodos (por ejemplo, Waterfall)
3. Los equipos tienen un propietario del producto o un usuario final comprometido como parte del equipo.
4. Un recurso de prueba dedicado, la automatización o ambos permiten estimaciones de prueba relativamente estables
5. El equipo coordina la priorización de la deuda técnica con cada sprint, junto con las prioridades del cliente.
6. La planificación solo incluye las tiendas transferidas para completar o las historias definidas como "suficientemente buenas" para estimar (por ejemplo, una buena historia de usuario, reglas comerciales que son universales o específicas para el actor, las condiciones de aceptación/criterios de prueba se pueden establecer dentro de los 24 días posteriores a la asignación de tareas).
7. Después de planificar con el propietario del producto, los equipos tienen "tiempo a solas" y orientación técnica para discutir y priorizar las tareas.
8. Durante el sprint, el equipo evalúa el progreso diariamente, colaborando y eliminando obstáculos. Los equipos se apegan a las tareas a las que se han comprometido.
9. No están obligados a completar la documentación estándar o tradicional, como un BRD o SRS, antes de que pueda comenzar el trabajo.
10. Los compromisos del proyecto u otros elementos que el equipo no puede controlar no impulsan la priorización del sprint, pero se tienen en cuenta para influir en la planificación.
11. Los equipos demuestran y corrigen dentro del sprint, como entradas a la velocidad
12. Los equipos se atribuyen el trabajo realizado con un sprint, aunque es posible que la historia no esté completa, pero el código está listo para la producción, al menos en parte.
13. Los equipos se toman el tiempo para analizar las variaciones en la velocidad, lo que necesitan mejorar en retrospectivas, definir un plan y medir su éxito.
14. El código de calidad y libre de errores se implementa a tiempo, no rompe nada más, cumple con los criterios de aceptación y prueba y no ha dejado una acumulación llena de enormes cantidades de deuda técnica.

Si un equipo no puede marcar cada una de esas casillas "sí, lo hacemos", su administración va a retroceder y el próximo paso será un equilibrio para administrar el negocio. Como se mencionó en una respuesta anterior, los equipos deben comenzar a planificar puntos y horas para abordar este escenario. La gerencia sabe que cada punto de la historia equivale a algún valor en horas de persona. Identifíquelo como un equipo o prepárese cuando lo defina la forma de negocio.

Hace algún tiempo escribí una publicación de blog relevante: "Horas de esfuerzo restantes"

La esencia es que no podemos estimar el tiempo real y, en cambio, pensamos que estamos estimando en "horas ideales", pero no podemos abstraernos de la percepción del tiempo. También puede crear la falsa impresión de que el número de horas restantes son 'horas de reloj' en lugar de 'horas idealizadas'.

Estoy un poco de acuerdo con el comentario de Blaze, pero intentaré presentar un caso más feliz:

A decir verdad, por lo general es la cantidad de tiempo para una tarea que le interesa, para que pueda estimar cuánto tiempo llevarán los proyectos futuros, de complejidad similar.

Así es como terminas usando la velocidad como se mencionó. Después de algunas iteraciones de desarrollo que toman x cantidad de tiempo y tienen y cantidad de puntos asignados, puede obtener su velocidad y luego usarla para planificar el futuro.

Es una gran cosa poder hacer eso y una herramienta realmente útil para desarrolladores, gerentes y propietarios de productos.

Los puntos de historia funcionan mejor en Scrum debido a la mentalidad del método.

En mi experiencia, Scrum es uno de los únicos métodos que permite esto porque en Scrum la gestión debe ser directa. Scrum le da cierta libertad al equipo de desarrollo para completar todos los trabajos pendientes sin la interferencia de la gerencia (y de los PM) hasta el final del sprint. Por lo tanto, preguntar cuánto tiempo llevará desarrollar una sola historia será irrelevante.

Por ejemplo, la Historia A requiere aproximadamente 5 Puntos de Historia, y la cantidad total de Puntos de Historia en el Sprint de las próximas 2 semanas es de aproximadamente 20. Si usted, como PM, necesita saber cuánto tiempo llevará terminar la Historia A, bueno... .2 semanas es tu respuesta. En paralelo con las otras Historias en el sprint.

Al final, siempre puede intentar calcular la proporción de días-hombre por Story Point. En el caso anterior, 20 Story Points tardarán 2 semanas (10 días). Lo que significa que podría tomar 5 Story Points, la tarea tomará 2.5 días. Pero en Scrum, no empaquetas el lanzamiento después de 2,5 días. Debes esperar a que finalice el Sprint, que son 2 semanas. Lo que hace que la proporción de días-hombre por Story Point sea bastante inútil.

No olvide que, como PM, debe monitorear la velocidad del equipo y asegurarse de que el equipo tenga una cantidad constante de Story Points totales para trabajar en cada sprint.

El sistema de puntos se basa en el comportamiento de la "fragmentación" y, si bien hace que las personas comuniquen la matriz de duración general frente a la complejidad al final del día, aún se reducirá al cálculo basado en el tiempo (ya sea en el momento en que el equipo realiza el pronóstico de secuencia lo vea o no).

Hay un elemento de peligro aquí en el sentido de que veo que muchos equipos asumen que tienen un desarrollo de "bolas de dinero", ¡finalmente han descifrado el secreto para pronosticar con matemáticas! - es un falso positivo porque si alguien asigna una historia con "pequeño" (enfoque de tamaño de camiseta) y esa persona luego descomprime 20 tareas para completar esa historia, entonces cada una de estas tareas aún asigna variables de tiempo a la ecuación.

Esto no es algo malo, ya que todas las secuencias de fragmentación están configurando parámetros sobre cuánto "Permite" el equipo en términos no solo de inversión en la tarea, sino también de los tipos de conjuntos de habilidades de desarrollador necesarios para que la tarea suceda.

Como gerente de equipo, aún necesita conocer el tiempo + la tarea, y no es para penalizar a un desarrollador por no mantener su presupuesto de tiempo en su lugar. Es más actuar como una forma de monitorear su crecimiento o capacidad para ayudarlos a fomentar un mejor comportamiento de comunicación: "A Sam no le gusta pedir ayuda", por lo que le permite al líder ayudar a rehabilitar el comportamiento hacia "estar bien con el fracaso, el fracaso". te enseña lecciones de vida". También le permite poner a un desarrollador junior en una tarea senior, porque quiere ver qué tan bien lo hará... sí, superará las estimaciones del sistema de puntos, pero eso es parte del entrenamiento de crecimiento en el trabajo y así sucesivamente.

Como dije, puede "jugar" con el modelado de pronóstico con técnicas de abstracción como el sistema de puntos, pero cuando se trata de asignación e incluso velocidad, el tiempo todavía está al acecho. Es por eso que la mayoría de los equipos hacen que la cantidad x de semanas sea un sprint, cuando si fuera realmente una metodología abstracta sería "este es un sprint de 45 y el siguiente es un sprint de 24" o algo así... el sprint sería Ser variable en longitud y tiempo. En cambio, ¿te encuentras en esta disonancia cognitiva en torno a la abstracción calzada de puntos en tiempo relativo? pero ¿usar líneas de base arbitrarias para cuantificar los datos de alguna manera?

Otro punto a agregar es que el equipo a menudo estima el trabajo antes de hacerlo. Las estimaciones basadas en el tiempo son particulares de las personas que completan el trabajo. El tamaño relativo (Story Points usando Planning Poker) es el tamaño del equipo. No es específico de personas.

Básicamente , el tiempo y los puntos de la historia no son equivalentes .

Los puntos agregan una abstracción fuera del tiempo por razones psicológicas, implícitamente para evitar el agotamiento del programador. Alguien todavía tiene que convertir la abstracción en un costo de tiempo/financiero. Simplemente pasa por la cadena hasta que alguien está dispuesto a asumir la responsabilidad por ello.

Mi propia opinión es que el agotamiento del programador no es causado por intentar estimar a tiempo, es causado por reacciones de administración inapropiadas cuando las cosas toman más tiempo de lo esperado.

Si está inventando abstracciones para evitar dar una estimación comercialmente útil porque le teme tanto al castigo, el problema está en su cultura de gestión.

Es mejor tener un ambiente de apoyo donde se entienda que las personas sinceras y trabajadoras cometen algunos errores, pero donde haya comentarios transparentes, en lugar de agregar capas de abstracción para que no tengan que confrontar realidades como 'Pensé que esto tomaría un día y se ha tardado más de una semana'. En mi opinión, eso es tratar a los ingenieros como niños.

La respuesta corta sería que "las horas son solo una conjetura, en el mejor de los casos". Pero si observa los puntos de la historia, llámelos como quiera, está considerando el mapa de actividad (y las dependencias que ocurren naturalmente dentro de ese mapa) que eventualmente harán que se gasten esas horas facturables.

El "software de computadora", en particular, es un nido de ratas de dependencias entrelazadas. Cuando examina el software desde un punto de vista funcional de esta manera, lo que realmente busca es descubrir la complejidad y la interdependencia que tan a menudo pone a un proyecto en una "marcha de la muerte".

Los puntos de historia no deben usarse para la planificación de proyectos. No hay propósito. Las estimaciones deben construirse en semanas-hombre o meses-hombre. Los puntos de la historia no presentan fácilmente ninguna información sobre la que se pueda actuar. Una historia tiene un peso de 10. ¿Cuánto es 10? ¿Es eso 10 por 1 persona, es eso 10 por 100 desarrolladores que trabajan en el proyecto?

El uso de semanas-hombre es sencillo.

Al final, la estimación, ya sean puntos o tiempo... es una estimación. Se basa en la experiencia de la persona que crea la estimación. Al usar el tiempo directamente, tiene una mejor capacidad para medir el éxito de sus estimaciones. Comparar los puntos de la historia con los puntos de la historia es, en el mejor de los casos, confuso y, en el peor, sin sentido.

Por último, ¿cómo construyes un sistema con puntos de historia? ¿Cuántos miembros del equipo necesitamos? ¿Cuándo se hará? El tiempo y el dinero son negocios. La planificación de proyectos es para brindarle a la empresa información sobre cómo aplicar mejor su tiempo y dinero, los puntos de la historia no lo son.