¿Gráfico de evolución que se basa en las fechas de vencimiento en lugar del trabajo restante?

En la empresa en la que trabajo usamos scrum.

Desafortunadamente, no hacemos un seguimiento del trabajo restante de los elementos, sino que utilizamos el modo de "fechas de vencimiento" por elemento.

Mi pregunta es, ¿es posible crear un burn down chart según las fechas de vencimiento?

De mi experiencia previa en scrum, había usado el gráfico de quemado después de actualizar los elementos de trabajo restantes a diario, y parece que no puedo pensar en una forma de implementarlo mientras estoy en el modo de fechas de vencimiento.

Cualquier orientación sería apreciada.

Si está utilizando fechas de vencimiento en lugar de esfuerzo restante, supongo que no está en línea con las pautas de escoria y los fundamentos de la escoria. Entonces diría que no está ejecutando un proyecto con escoria, simplemente. Así que no puedes hablar de quemaduras.
Con las fechas de vencimiento, será difícil encontrar quemados. Existe la medida en que puede personalizar la metodología. Entonces, el problema es que si se rompen los fundamentos, simplemente su pregunta se vuelve inválida. Sin embargo, puede hacer un truco simple para obtener el saldo restante a partir de la fecha de vencimiento. Si conoce la fecha de vencimiento de una tarea, puede calcular las horas necesarias para completar la tarea multiplicando por las horas que un recurso trabajará en dicha tarea. Allí obtendrá las horas restantes y aún puede dibujar sus quemaduras.
Esto no proporciona una respuesta a la pregunta. Para criticar o solicitar una aclaración de un autor, deje un comentario debajo de su publicación; siempre puede comentar sus propias publicaciones y, una vez que tenga suficiente reputación , podrá comentar cualquier publicación .

Respuestas (1)

Suponiendo que las fechas de vencimiento son por artículo, entonces no, no hay matemáticas que lo traduzcan en una suma de cantidades conocidas que podrían reducirse a cero en el transcurso de un sprint. Podría quemar los elementos restantes, y cualquier elemento que pierda su fecha de vencimiento no se quema, pero esto es difícil para el equipo y peligroso para el proyecto. Una vez que un elemento no llega a su fecha de vencimiento, el equipo no tendrá motivación para continuar trabajando en él y pasará a otras tareas que aún pueden recibir crédito por completar a tiempo .

Tal vez podría secuestrar el modelo de reducción del tiempo estimado frente al tiempo real, donde el tiempo estimado es la cantidad de días desde el inicio del sprint hasta la fecha de vencimiento. Esto mantiene el valor rastreado en el elemento 'vivo' y evita la pérdida de prioridad anterior.

Sin embargo, me preocupa un poco que esté rompiendo un principio fundamental de scrum: la única fecha de vencimiento es el final del sprint. El equipo asume una pila de trabajo al comienzo de un sprint y promete completarlo al final. Si las fechas de vencimiento son un problema, asigne trabajo a los sprints que finalicen antes de esas fechas. Use sprints de una semana si el trabajo llega tan rápido que necesita asegurarse de que entre en un sprint lo suficientemente pronto. Si incluso eso no es lo suficientemente rápido, entonces tal vez Scrum no sea para ti y deberías dejar de hacerlo. Introducir scrum en ese tipo de entorno conduce al fracaso con demasiada facilidad.

Tal vez busque en kanban puro basado en extracción y coloque los artículos con fecha de vencimiento más cercana en la parte superior de la pila. El truco es llegar a una posición en la que las fechas de vencimiento no estén al frente de su mente. Si siempre está compitiendo para encontrarlos, algo anda mal y los gráficos no lo solucionarán.

Por último, recomendaría reunir a su gerencia para hablar sobre el estado de scrum en su empresa. O no están realmente haciendo scrum y creen que lo están haciendo, o el equipo en el que está tiene una implementación defectuosa y necesita ser corregido por otros en la empresa que saben mejor. Esperemos que sea solo lo último, porque si es lo primero, hoo boy. No hay nada más condenado que una empresa que piensa que puede elegir las partes de scrum que le gustan y dejar de lado el resto. Recuerda: frankenscrum y waterscrum no son reales. Son solo mitos que los entrenadores ágiles inventaron para calmar a los gerentes mientras los subvierten desde cero. ¡No se supone que los hagas en realidad !