¿Es posible dar líneas de tiempo en SCRUM?

Como la mayoría de las cosas, depende.

En teoría, podría pronosticar cuándo es probable que se realice el trabajo. Si comprende la velocidad promedio de su equipo (ya sea en puntos de historia por Sprint, horas ideales por Sprint, elementos pendientes por Sprint), puede pronosticar cuándo llegará a un elemento específico en la acumulación. Sin embargo, hay muchas advertencias con esto. Depende de todo el trabajo hasta que el artículo en cuestión esté bien refinado y estimado. También supone que el orden del trabajo (incluidas las adiciones y las eliminaciones) es fijo. La velocidad del equipo puede cambiar con el tiempo (en cualquier dirección) por varias razones diferentes. Cualquier pronóstico de este tipo, especialmente si se trata de más de un par de Sprints, tiene mucha variabilidad. El pronóstico es una instantánea "tal como está" que podría cambiar diariamente, a medida que cambia la acumulación.

En la práctica, dudaría mucho en siquiera intentar pronosticar algo más de lo que se está haciendo en el Sprint actual y quizás probablemente para el próximo Sprint. Si realmente está adoptando la agilidad, que incluye la capacidad de respuesta a los cambios y la retroalimentación, debe adaptarse. No es raro que las personas conviertan estimaciones y pronósticos en fechas límite. Tener plazos comprometidos hace que sea más difícil responder a los cambios, especialmente si está tratando de mantener un ritmo de trabajo sostenible.

Lo mejor que puede hacer es trabajar con todas las partes interesadas para comprender las compensaciones. En lugar de pronosticar fechas, haga el trabajo en el orden correcto. Si hay un trabajo que tiene plazos, después de los cuales el trabajo ya no es valioso, esto debe tenerse en cuenta al ordenar el backlog.

La herramienta que desea es un gráfico de quemado. JIRA los tiene incorporados como Release Burnup Chart o Release Forecast Chart (siguen cambiando el nombre), pero la función en JIRA es limitada y solo pronostica el lanzamiento completo. Sin embargo, puede crear estos gráficos a mano; pueden parecer difíciles al principio, pero son muy rápidos y muy fáciles una vez que aprende a hacerlo. Construido a mano, puede pronosticar características específicas más fácilmente.

Hay algunas cosas que usted y su gerente deben saber acerca de esta herramienta:

1. te da una visión de las cosas como las conoces hoy. Su aprendizaje evoluciona, por lo que el gráfico cambiará a medida que aprenda más y progrese. En realidad, no hay nada nuevo aquí, pero los diagramas de GANTT dieron la ilusión de certeza. Cualquier gerente de proyecto sabe, sin embargo, que los diagramas de GANTT cambian todo el tiempo a medida que avanza el proyecto.

2. Los gráficos de quemado brindan un rango, generalmente desde un pronóstico pesimista hasta un pronóstico promedio y optimista. Si toma su pronóstico más optimista y se lo promete al director ejecutivo, ha cavado su propia tumba.

Finalmente, un pequeño consejo, para una gran cantidad de elementos atrasados, contar elementos suele ser tan preciso o casi tan preciso como usar las estimaciones, a menos que tenga elementos de tamaños muy diferentes.

¿Los cronogramas no son ágiles/-SCRUM o debería ser siempre posible un cronograma para tareas que están meses en el futuro?

Siempre puede hacer una planificación de lanzamiento a largo (más) plazo, sin importar si usa Scrum o cualquier otra cosa. Básicamente, observa las funciones que desea realizar, estima todas y cada una de ellas, luego, conociendo la velocidad del equipo y la duración de un sprint en días/semanas, puede pronosticar una línea de tiempo.

Pero, por supuesto, como usted mismo mencionó, pueden pasar muchas cosas entre el momento en que hace este pronóstico y el momento en que su lanzamiento "realmente estará hecho". Las prácticas ágiles como Scrum reconocen esto como una realidad y no intentan estimar todo por adelantado y predecir cuándo se hará todo. El alcance es flexible en Scrum. Una planificación de lanzamiento por adelantado corrige el alcance. En realidad, fija el alcance en la imaginación de las personas porque a medida que trabaja en su producto, descubre nuevos conocimientos, ocurren cosas, se necesitan cambios, etc., por lo que el alcance cambiará inevitablemente si desea construir EL producto CORRECTO y no ALGÚN producto que imaginado al principio (cuando menos se sabe al respecto).

Vea, por ejemplo , esta explicación sobre cómo se puede hacer una planificación de lanzamiento más larga con Scrum. Puedes hacerlo, pero no tienes garantías de que realmente lo harás realidad, porque las cosas evolucionan. Esa es una de las razones por las que en Scrum, la acumulación de productos se prioriza, se detalla y se estima en la parte superior, y las cosas se vuelven borrosas a medida que avanza, porque no intenta crear un montón de funciones, desea crear las funciones correctas.. Por lo tanto, averiguar ahora qué estará disponible dentro de unos meses es una mala idea y, por lo general, un desperdicio, y no solo con Scrum, sino en general. Si decidiste que crearás la función F dentro de dos meses, no hace que la función forme parte del producto por arte de magia, porque dentro de dos meses, por varias razones, esa función podría ser completamente inútil o incluso perjudicial para el producto. .

Agile, y también Scrum, necesitan una colaboración entre el equipo de desarrollo y quienes solicitan el producto. Lo que su gerencia está tratando de hacer es "eximirse" de esta colaboración y simplemente esperar que construya las cosas cuando lo deseen. Y cambiar la forma en que ven el desarrollo y cuál es su papel en todo , lamentablemente será mucho más difícil que dar plazos con Scrum.

Las estimaciones y la velocidad son la respuesta a su pregunta. Nada en Scrum impide que el equipo calcule el trabajo (y debe ser el equipo quien lo haga, no una sola persona). El enfoque de scrum ayuda con la estimación y los equipos de scrum normalmente basan sus pronósticos en la velocidad (evidencia basada en resultados anteriores) en lugar de predicciones más especulativas.

No es menos posible dar líneas de tiempo en Scrum que en otras metodologías.

La principal diferencia es que en Scrum no se nos anima a mentir descaradamente, es por eso que tenemos que pedirle al equipo que estime los elementos de la cartera de pedidos del producto y es por eso que consideramos cualquier quemado o quemado solo como un pronóstico .

Dar plazos no es mejor en un proyecto tradicional de PMI. Los plazos rara vez se cumplen, tal vez cuando se agregan contingencias generosas a las estimaciones y se imponen horas extras.

Si asumimos que tiene un equipo de Scrum bastante maduro trabajando en el proyecto, lo que significa que tienen una buena variedad de habilidades técnicas apropiadas, trabajan bien juntos, siguen las prácticas de Scrum de manera adecuada y han alcanzado un punto tanto en productividad como en estimación que son capaces de cumplir regularmente el Sprint Goal sin tener un exceso de trabajo o una falta de trabajo, entonces:

1. Cualquier elemento de la lista de pedidos del producto debe colocarse en una posición en la lista de pedidos que represente su prioridad en relación con los otros PBI según la comprensión del propietario del producto del estado actual del producto .

2. Cualquier elemento del Product Backlog debe ser estimable, lo que significa que el equipo tiene una idea de cuán simple o complicado es en relación con otras tareas y, por lo tanto, de su capacidad para completarlo si estuviera incluido en un Sprint. (Esto se puede hacer en términos de Story Points o de cualquier otra manera, como tallas de camisetas o monumentos mundiales o lo que sea, siempre que el equipo comprenda cómo se relacionan los valores entre sí).

3. Los elementos de la Lista de Producto cerca de la parte superior de la Lista serán, en promedio, mejor entendidos, más claramente definidos, más pequeños y tendrán menos condiciones previas no cumplidas que los que se encuentran más abajo en la Lista de Pendientes, es decir, deberían estar más listos, con los elementos en la parte superior. la parte superior está potencialmente lista para trabajar de inmediato.

Siendo este el caso, el propietario del producto debería poder simplemente trazar una línea en algún lugar de la cartera de productos y decir "Esto es lo que entregaremos el próximo Sprint", y el equipo Scrum debería estar lo suficientemente cerca de estar de acuerdo con esto para que Puede negociar y ajustar el punto hacia arriba o hacia abajo en algunos elementos.

Esto también significa que el propietario del producto debería poder dibujar varias líneas en el Product Backlog, cada una de las cuales representa el valor del trabajo de un Sprint. Si hace eso, entonces tiene una estimación de cuánto tiempo llevará completar un elemento dado, ya que es solo una función de cuántos Sprints faltan y cuánto duran sus Sprints.

Sin embargo, hay que estar atento a los puntos 1 y 3 anteriores. Cada Sprint Review es una discusión entre el Equipo Scrum y el cliente, y representa un punto en el que el Product Owner puede decidir cambiar el orden de los elementos en el Backlog, o incluso cambiar los elementos que se representan en el Backlog. Además, cualquier cosa que esté más abajo en el Backlog está, por naturaleza, nublada por la incertidumbre: algo que actualmente está 1 Sprint abajo en el Backlog probablemente terminará en el próximo Sprint, pero algo que está 4 Sprints abajo podría terminar siendo trabajado en 3 Sprints a partir de ahora, o 5. Puede dividirse en 3 elementos diferentes porque en realidad involucra múltiples desarrollos importantes, o el equipo puede necesitar invertir en un pico de investigación para comprender incluso lo que implica el desarrollo de esa característica.

Muchos proyectos de estilo Waterfall tienden a asumir que los hitos planificados al comienzo del proyecto son perfectamente estimados y predecibles, pero si trabaja en un equipo Scrum, entonces existe una buena posibilidad de que su producto no encaje bien. ese paradigma en primer lugar, y las partes interesadas que están detrás de usted pidiendo marcos de tiempo perfectamente responsables tendrán dificultades para acostumbrarse a esto, pero con suerte si están involucrados en las partes clave del proceso Scrum (especialmente Sprint Review, donde pueden ver tanto el desarrollo incremental del Producto como el ajuste del Product Backlog), entonces comenzarán a aprender el valor de aceptar esta incertidumbre, que siempre estará ahí, pero que se hace mucho más evidente en Scrum que en Waterfall. .

Si está haciendo scrum, no es factible estimar la línea de tiempo para todo el proyecto. Solo puede funcionar si se adopta el enfoque ágil, que requiere que los plazos dependan de lo que el propietario del producto ha priorizado en la cartera de productos. Además, cuando el equipo de desarrollo ha decidido la cantidad de funciones que se crearán en un sprint, el equipo de desarrollo puede estimar el esfuerzo que se necesitará para crear una función en forma de puntos de la historia. El número total de puntos de la historia en una acumulación de sprint es el esfuerzo y el tiempo necesarios para crear las características.