Pregunto porque estamos viendo Pivotal Tracker, que creo que es una herramienta muy popular para la gestión de proyectos Scrum, y:
Si usar Tareas y actualizar Tareas con horas restantes estimadas es la mejor práctica de Scrum, ¿por qué se dejaría fuera de una de las herramientas de administración de Scrum más populares y por qué no admitirían un Sprint Burndown Chart?
Creo que la respuesta a su pregunta es un desacuerdo con su premisa básica: actualizar tareas con horas estimadas no es necesariamente una "mejor práctica de Scrum".
Parte del objetivo de Scrum es utilizar datos precisos y empíricos para proporcionar estimaciones precisas de la cantidad de trabajo que se puede realizar. En mi experiencia, la mejor práctica es usar Puntos de Historia de Usuario; en mi empresa usamos una secuencia de Fibonacci modificada (1/2/3/5/8/13/20/40/100) para estimar cada Historia de Usuario. Después de algunos Sprints, te haces una idea bastante buena de la velocidad del equipo.
Usamos Story Points porque son precisos pero no necesariamente precisos , mientras que la estimación en horas tiende a ser lo contrario: los equipos intentan hacer una estimación precisa que generalmente termina no siendo muy precisa en una tarea. Durante mucho tiempo, intentamos estimar las historias con puntos y las tareas con horas, pero la cantidad de tiempo que pasábamos tratando de hacer estimaciones de horas exactas y precisas en cada tarea nos costaba más de lo que nunca. ¿Quién necesita una estimación precisa de horas cuando un equipo puede decir con confianza "Vamos a lograr 35 puntos de historia de usuario en este Sprint"?
Con respecto al gráfico Burndown, tiene algunas opciones:
Mi fuerte recomendación es repensar cómo estimas las cosas y cambiar a un método de punto de historia o tamaño relativo.
La mejor parte de Story Points es que, una vez que obtenga una cantidad razonable de datos de seguimiento de tiempo, puede comenzar a calcular la mediana y la desviación estándar de los valores de tiempo para cada calificación de Story Point discreta (por ejemplo, la historia mediana de 2 puntos toma n horas con una desviación estándar de x). Si bien nunca respaldaría el uso de estas medidas como métricas o KPI, sí uso un método con estos valores para las estimaciones de referencia para los Ámbitos de trabajo, junto con otros datos y análisis de un proyecto.
La guía de Scrum no dice nada sobre el seguimiento y la actualización de las horas restantes, ni lo obliga a usar un trabajo pendiente para monitorear el progreso. En realidad, las horas quemadas son el peor indicador de progreso, ya que se ve bien, pero no muestra incertidumbre. Crees que vas por buen camino, hasta que pierdes la marca y ves que hay mucho trabajo extra y ahora estás atrasado.
Se han utilizado varias prácticas proyectivas sobre tendencias para pronosticar el progreso, como burn-downs , burn-ups o flujos acumulativos. Estos han demostrado ser útiles. Sin embargo, estos no reemplazan la importancia del empirismo. En entornos complejos, se desconoce qué sucederá. Solo lo que ha sucedido puede usarse para la toma de decisiones con miras al futuro.
En el día de los evangelistas ágiles en Amsterdam hace algunos años, Jeff Sutherland (fundador de Scrum) dijo que si tuviera que usar una herramienta, sería PivotalTracker , pero mejor sería ninguna herramienta. Tampoco le gusta mucho el seguimiento de horas, llamándolo anti-scrum de seguimiento de tiempo . Sugiere que es lo primero que hay que prohibir en una empresa. Sugiere que las horas de seguimiento cuestan el 10% de su tiempo de desarrollo, ya que los desarrolladores lo odian, porque se usa para dirigir las señales equivocadas, si es que se usa.
Cuando hablo de decidir sobre herramientas para un proceso, siempre digo: construya procesos alrededor de herramientas (existentes), no encuentre herramientas para su proceso ideal, porque no lo encontrará. Si lo intenta como un taller de desarrollo, incluso podría decir que la herramienta no existe, ¡construyámosla nosotros mismos! Y ahora estás en años de problemas.
Todd A. Jacobs