Como Scrum Master, quiero ayudar a mi Product Owner a hacer una suposición informada de cuándo se implementarán las características de un proyecto, para poder comunicarme con las partes interesadas para que puedan administrar Scope. Conducir a las prioridades y un pronóstico del plan de liberación.
Una forma de pronosticar es crear una acumulación de epopeyas e historias de usuarios y pedirle al equipo que proporcione estimaciones de alto nivel en los puntos de la historia. Por ejemplo, con una técnica de dimensionamiento Swimlane . Luego complete el campo de estimación de Jira con estos valores. Después de algunos sprints, puede usar el trabajo pendiente de la versión o el informe de versión para pronosticar las fechas en las que se pueden completar ciertas funciones.
Pero como Jira solo tiene un campo de Estimación único, me temo que cuando estos campos ya están poblados, esto influirá en las estimaciones del desarrollador durante las reuniones de planificación de Sprint, sin duda porque las estimaciones iniciales del proyecto podrían no ser del tamaño relativo a lo que usamos durante nuestros Sprints.
Más bien me gustaría hacer:
Ahora mi pregunta:
En general, parece que vas por buen camino. Recuerde la Guía Scrum :
El Equipo de Desarrollo es responsable de todas las estimaciones.
Permita que el equipo de desarrollo cree estimaciones de alto nivel. Por lo tanto, el campo se puede utilizar según lo previsto.
De acuerdo con McConnell ("Estimación de software"), el tamaño de la camiseta es útil para ayudar al equipo de productos a priorizar las cosas en la cartera de pedidos, porque el tamaño les permite comprender la prioridad de una característica en función de su relación de tamaño y valor. Entonces, puedes usarlo para este propósito. Y puede crear un campo personalizado para él, e incluso ocultarlo de los desarrolladores después de que se haya movido a través del flujo de trabajo, si lo desea (aunque, en mi humilde opinión, no "anclará" a los desarrolladores tanto como teme).
Pero para producir estimaciones numéricas con el fin de pronosticar las fechas de finalización, es necesario que los desarrolladores proporcionen estimaciones numéricas, como aconsejan los muchachos.
El Informe de versión es por tablero, por lo que si tiene más de un tablero, producirá una estimación diferente para cada tablero. Por lo tanto, consideraría este enfoque solo cuando el proyecto use una sola placa. Lo mismo se aplica al informe Burn-down de la versión . No creo que ambos informes produzcan un resultado consistente cuando hay más de una junta. El comunicado (campo) no es específico de la junta, pero dichos informes dependerán de la junta.
La forma en que desea proporcionar el pronóstico es de abajo hacia arriba, en función de la estimación de las epopeyas y las historias. Creo que el informe mencionado podría funcionar solo cuando hay una placa por proyecto, lo cual es un caso simple. Jira debería proporcionar un mejor conjunto de informes con un mayor nivel de personalización para tener algunas herramientas útiles para predecir el futuro (pronóstico). Los informes existentes son difíciles de entender sin personalización y no son válidos para un proyecto que trabaja con más de una placa.
Otra solución sería estimar todo el backlog utilizando cualquier técnica de estimación, podría ser asignar puntos de historia y luego, en lugar de mantener los problemas en el backlog, preguntarle al equipo cuándo esperan entregarlos y luego asignarlos a futuros sprints. Ahora tenemos el trabajo planeado. Exportando desde Jira la información a un archivo de Excel, y luego tendremos un plan basado en el sprint de trabajo a futuro planeado. Esta es una posible solución para predecir el futuro y realizar un análisis de capacidad basado en la planificación de recursos e identificar posibles brechas.
No veo el punto de usar un campo diferente para estimar al final como parte de las actividades de preparación, las estimaciones se vuelven más precisas a medida que sabemos más sobre la historia/epopeya a implementar. La estimación es un proceso iterativo, donde el término de clasificación es más preciso que el futuro.
Para Nex-Gen Jira Project hay una nueva característica: Hoja de ruta , pero no está disponible para proyectos clásicos. Seleccionar un proyecto de próxima generación o clásico tiene ventajas y desventajas. Por ejemplo, tiene una hoja de ruta para la próxima generación, pero luego no realiza subtareas, por ejemplo, y otras limitaciones también.
El uso de una hoja de ruta proporcionará una planificación de arriba hacia abajo como debería ser. Para un proyecto clásico, la única solución equivalente es comprar un complemento de Jira Market Place, por ejemplo, Easy Agile User Story Map para Jira o cualquier otro complemento como Jira Portfolio o Big Project que brinde soluciones similares.
La versión básica de Jira proporciona opciones limitadas para hacer un pronóstico. Jira sigue los principios Agile/Scrum donde la única forma de predecir el futuro es mediante la entrega de una pieza de software y mostrar a las partes interesadas el trabajo realizado en una sesión de demostración. Los informes están destinados solo para uso interno del equipo, pero no para otra audiencia, como partes interesadas externas.
Me gustaría darle una respuesta más optimista, pero no creo que la versión actual de Jira (al menos para Jira Cloud, la que yo conozco), no proporcione una forma sencilla para esta estimación de pronóstico.
Yo diría que no desea "... ayudar a mi Product Owner a hacer una suposición informada de cuándo se implementarán las características de un proyecto, para poder comunicarse con las partes interesadas para que puedan administrar Scope".
Las proyecciones solo son útiles cuando contienen estimaciones de confianza que son lo suficientemente estrictas como para usarlas en la planificación.
Según mi experiencia, el propietario de su producto necesita saber:
Niels van Reijmersdal
alan larimer