¿Hay algún método para estimar de manera justa los puntos de la historia de un proyecto antes de profundizar en la parte de planificación del póquer? Pregunto esto porque a veces, al iniciar un proyecto, ayuda saber la cantidad tentativa de trabajo en términos de puntos de la historia.
¿Hay alguna técnica que pueda usarse para generar algunas cifras al principio?
Un enfoque común es hacer una estimación inicial aproximada del Product Backlog utilizando un método de clasificación como el sistema de cubetas , con variaciones descritas por ThoughtWorks o Mountain Goat Software . Algunas otras técnicas también se enumeran como referencia en la parte inferior de esta respuesta.
La idea general del sistema de baldes es que usted identifique una historia de línea de base, le asigne 1 o 2 puntos de historia y luego calcule los tamaños relativos del resto en relación con la línea de base. Es similar a Planning Poker en algunos aspectos, pero tiene la intención de proporcionar resultados más rápidos a expensas de la granularidad y la precisión porque no está haciendo el nivel de descomposición que normalmente haría durante Sprint Planning o Backlog Refinement.
Este tipo de clasificación puede ser muy rápido en comparación con Planning Poker, especialmente si recuerda que el punto de la estimación inicial es hacer una planificación de lanzamiento de alto nivel, en lugar de planificar todos sus sprints por adelantado. En otras palabras, en realidad solo está haciendo una estimación aproximada de los primeros sprints, mientras que el resto del Product Backlog está lleno de temas y epopeyas a los que puede o no llegar bajo el principio YAGNI .
Puede utilizar la clasificación de cubos u otras técnicas similares para crear entradas para el resto del proyecto. Aún deberá volver a planificar y estimar cada Sprint, y determinar cómo (o incluso si) desea formar un plan de lanzamiento para el proyecto general. Discuto cada uno de estos temas con más detalle a continuación.
Recuerde que la estimación inicial de la cartera de pedidos es el comienzo de una serie de procesos, no el estado final. Volverá a estimar las historias probables para cada próximo Sprint nuevamente durante el Refinamiento del Backlog y hará otra estimación detallada durante la Planificación del Sprint al comienzo de cada Sprint.
En otras palabras, sus estimaciones iniciales cambiarán con el tiempo:
Su plan de lanzamiento contiene estimaciones de alto nivel de la variedad "a grandes rasgos", mientras que su Sprint Backlog realmente debería contener un pronóstico más granular del trabajo inmediatamente por delante del equipo en el Sprint actual. Algunos equipos también usan la clasificación de cubos para la planificación de Sprint, pero soy un gran admirador de Planning Poker para estimar los puntos de historia durante la primera mitad de la planificación de Sprint y verificar la cordura de las tareas de Sprint Backlog con la capacidad estimada del equipo en horas ideales . o días calendario durante la segunda mitad para evitar compromisos excesivos.
Su kilometraje puede variar según la técnica, pero aún debe aplicarse la regla de aumentar la granularidad a medida que pasa de la Planificación de lanzamiento a la Planificación de Sprint.
El objetivo principal de la planificación inicial es, por lo general, hacer una suposición informada sobre la velocidad y proporcionar una línea de base inicial para la planificación de lanzamiento ágil . Puede ser tentador estimar todo el Product Backlog, pero en mi propia práctica descubrí que estimar solo lo suficiente del backlog para pronosticar los primeros sprints es suficiente para hacer conjeturas informadas para el cronograma general de lanzamiento del proyecto. De todos modos, la mayor parte del resto de la cartera de pedidos no sobrevivirá al ciclo continuo de refinamiento de la cartera de pedidos, planificación de Sprint y modificaciones de las revisiones de Sprint y las retrospectivas de Sprint.
Un truco mental Jedi decente aquí es clasificar los cubos, estimar la velocidad inicial y luego ver si las historias que se elegirían para el primer Sprint parecen encajar. A veces, encontrará que algo se siente mal con respecto a las estimaciones de los elementos de la cartera de productos o la capacidad del equipo, mientras que otras veces sentirá que tiene al menos un 80% de posibilidades de alcanzar su primer Sprint Goal utilizando la velocidad y la historia. estimaciones puntuales que está adivinando como su línea de base.
En la planificación ágil de versiones, todavía se aplica la triple restricción tradicional , pero la dimensión que cambia con mayor frecuencia es el alcance . Por lo tanto, aún puede formar un plan de lanzamiento basado en hitos clave en el proyecto utilizando épicas/temas, pero tendrá que ajustar sus Objetivos de Sprint y refinar el alcance de cada Sprint para que se ajuste al plan de lanzamiento. Este enfoque no requiere una estimación completa de todo el trabajo pendiente.
Alternativamente, puede basar su programa de lanzamiento en el tiempo que espera que lleve completar todo el trabajo en la cartera de productos inicial. Si hace esto, deberá volver a estimar periódicamente todo el trabajo atrasado restante y realizar un seguimiento de una versión quemada, además de asegurarse de tener un producto potencialmente entregable al final de cada Sprint.
Obviamente, recomiendo encarecidamente el primer enfoque. Aún así, si el alcance del proyecto es fijo pero el cronograma es una dimensión ajustable para su proyecto, entonces el último enfoque también puede funcionar. Es solo más trabajo y, en muchos casos, menos preciso durante la planificación inicial.
Estos enlaces no son particularmente canónicos, pero abordan algunas alternativas bien conocidas para planificar el póquer o el sistema de cubetas. Ciertamente hay otros, pero estos son algunos de los más comunes:
La valoración masiva relativa tiene mucha aceptación en la comunidad ágil, pero a pesar del nombre, creo que TFB/NFC/1 es una técnica sorprendentemente útil que merece más atención. YMMV.
Se utilizan varias técnicas que ayudan con la estimación del punto de la historia.
Un enfoque es elegir una historia de referencia y usarla como referencia para las otras historias. En un equipo de BI en el que trabajé, su historia de referencia era agregar una sola medida a un informe. Juzgarían todas las demás historias contra esa. Tener una línea de base facilitó que el equipo dijera 'más pequeño que la línea de base' o 'más grande que la línea de base'.
Otro enfoque es escribir sus historias en tarjetas y ordenarlas por tamaño. De modo que la historia más grande esté en la parte superior y la historia más pequeña en la parte inferior. Luego, decide dónde están los puntos de límite en la lista entre los distintos tamaños de puntos de historia. Por ejemplo, digamos que tiene 20 cartas clasificadas en orden y decide que las tres cartas de abajo valen 1 punto, las dos cartas de arriba valen 2 puntos y así sucesivamente.
Mike Cohn ha escrito en su blog sobre esto .
He tenido un gran éxito con Swimlane Sizing para estimar una gran lista de posibles cambios, es similar al sistema de cubo que describe CodeGnome.
Divida el mazo de historias entre su equipo y pida a los miembros que pasen un máximo de 5 minutos en silencio colocando sus historias en los carriles de natación, con historias de tamaño creciente de izquierda a derecha. Por ejemplo, las historias más pequeñas en el carril más a la izquierda.
Lea todo el proceso en esta publicación de blog: Dimensionamiento de Swimlane: estimación completa y rápida de la acumulación
No veo ninguna forma de evitar hacer una primera estimación aproximada de la cartera de pedidos.
Además de esto, debe tener en cuenta los errores esperados, así como espacio para refactorización, malentendidos y mejoras. Una buena técnica para visualizar el riesgo y comprender la zona de aterrizaje del proyecto es la simulación de Monte Carlo, por ejemplo, https://agilemontecarlo.com o mediante la descarga de una hoja de Excel de simulación de Monte Carlo.
jwecompra