Si entiendo Scrum correctamente, así es como determino el trabajo que mi equipo puede realizar en el próximo sprint:
Promedio el número de puntos completados en los últimos sprints.
Esta cantidad es nuestra velocidad promedio. En el próximo sprint, tomaremos tantos puntos de la historia.
Este es un promedio , por lo que si la historia se repite, este sprint tiene un 50% de probabilidades de que tengamos muy pocos puntos de historia y un 50% de probabilidades de que tengamos demasiados puntos de historia.
En el caso del 50%, hemos tomado demasiados puntos de historia que podríamos:
No se pudo completar el sprint. Esto significa que no cumpliremos con nuestro compromiso de sprint la mitad del tiempo.
Trabaja más para ponerte al día. El problema es que este trinquete solo tiene una dirección. Lograremos el sprint, y la cantidad de puntos de historia completados reflejará eso. Como siempre terminamos, con el tiempo, nuestro promedio tenderá hacia arriba hasta el punto en el que siempre logremos una gran cantidad de puntos de historia y nos quedaremos hasta tarde.
¿Es correcto mi comprensión de los compromisos de velocidad media y sprint?
Si es así, ¿qué debemos hacer para el 50% de los sprints donde estamos por debajo del promedio?
Si no, ¿qué me he equivocado?
fuente
Respuestas:
Sí, tienes la esencia de eso.
Lo que pasó por alto es que los puntos de la historia son las cosas que se hacen . Es casi imposible para todos trabajar en historias hasta el final del sprint. Si está haciendo las cosas bien, la mayoría de sus desarrolladores estarán "inactivos" durante unos días mientras se prueban las historias (y sus evaluadores en el medio del sprint ya que el desarrollo está en pleno apogeo).
Puse inactivo entre comillas porque sus desarrolladores no están sentados viendo videos de gatos, están arreglando errores, puliendo algunas pruebas de código / unidad, agregando documentación sobre procesos, pensando en el diseño de historias en el trabajo atrasado o uno de los otras docenas de cosas útiles de las que un equipo de desarrollo puede beneficiarse pero que no encajan bien en una historia.
Entonces, aunque adivinará en exceso el 50% del tiempo y subestimará el 50% del tiempo, eso no significa que vaya a fallar el sprint o que tenga que trabajar horas extras . Significa que no tendrá tanto tiempo para hacer este trabajo misceláneo (a menos que realmente pierda sus estimaciones). Pero eso no es gran cosa, ya que el trabajo misceláneo no es sensible al tiempo, y las cosas se compensarán a la larga.
fuente
Desafortunadamente, se le ha informado mal sobre algunas cosas con respecto a la planificación de Sprint en Scrum. Primero, el Equipo de Desarrollo (DT) es
La palabra para esto es autoorganizarse. Esto incluye el trabajo de pronosticar el trabajo que se realizará en un Sprint determinado. No se le dice al DT qué funcionará en cada sprint, sino que está más facultado para elegir su propio trabajo. El DT podría necesitar información como velocidad histórica, una cartera de productos bien refinada y la capacidad del DT del próximo Sprint para crear un pronóstico. En última instancia, es la determinación del DT de lo que se puede y no se puede lograr en un Sprint lo que debe prevalecer en su pronóstico; no se les debe decir cuánto trabajo harán.
Aviso también, pronóstico y no compromiso. La palabra c se eliminó de la Guía Scrum porque se estaba utilizando para abusar del Equipo de Desarrollo. Pronóstico es el término preferido.
Con respecto a la probabilidad de perder el pronóstico de Sprint en el extremo bajo o alto, no veo que eso sea importante. En algún momento, más análisis no produce una mejor precisión y creo que ahora estamos más allá de ese punto.
Además, un Sprint solo se puede "cancelar"; nunca puede fallar. Un Sprint se cancela solo cuando el objetivo del sprint se vuelve completamente obsoleto e irrelevante. Esto rara vez es el caso. Si un pronóstico es incorrecto, solo mantén la calma y Scrum. ¿Tienes retrospectiva? El próximo Sprint, tus pronósticos serán mejores :).
fuente
Primero, su velocidad es de su sprint anterior, o algunas veces de un promedio de algunos Sprints recientes (Clima de ayer), y no un promedio de todos los sprints pasados. Por supuesto, si no tiene datos históricos de su equipo o empresa, debe encontrar un valor razonable para su primer sprint. En tu segundo sprint, obtienes los puntos de la historia completa en el sprint. Si tuviera que graficarlo, puede ver variaciones en los primeros sprints (por ejemplo, 17 en el primer sprint, 22 en el segundo, 26 en el tercero, 24 en el cuarto). Eso es de esperarse a medida que normaliza su trabajo en equipo y el proceso de estimación, junto con una mejor comprensión del proyecto (tecnología, dominio).
Eso no quiere decir que no te ajustas. Por ejemplo, si tiene una semana que es una semana de vacaciones, asegúrese de tener en cuenta las vacaciones donde el trabajo está cerrado. Si sabe que los miembros del equipo se van de vacaciones, planifique que trabajen menos personas. Por supuesto, los eventos no planificados también ocurren, pero puedes explicarlos en una retrospectiva del sprint y puedes decidir cómo eso influye en la cantidad de puntos de historia que traes al próximo sprint.
En cuanto a qué hacer, "no completar el sprint" es diferente a "no completamos todas las historias". Para mí, una falla en un sprint significa que no produjo un producto potencialmente enviable al final: ninguna de sus historias está completa, no tiene una compilación, no puede demostrar ningún valor agregado al cliente o usuarios.
Hagas lo que hagas, no debes trabajar tarde o excesivo con el tiempo. Esto se llama ritmo sostenible ( Agile Alliance , Scrum Alliance ).
Los indicadores de que puede haber problemas es si:
fuente
La metodología ágil varía de una compañía a otra, en una implementación puede ser muy diferente de otra. He trabajado con Agile en dos empresas. En la primera compañía en la que estuve se tomaron sus métricas muy en serio, en la segunda compañía en realidad no. Entonces, por lo que sabes, nadie está prestando atención a tus métricas.
Dicho todo esto, parece que le preocupa no cumplir con sus objetivos de sprint o lo que sucede cuando tiene una estimación inexacta. Creo que este tipo de preocupación y perspectiva es común, pero no es particularmente importante. Agile, sobre todo, es un sistema de desarrollo de software que hace algunas cosas:
Al final del día, si calcula mal un sprint o falla un sprint, no es realmente tan importante. Es probable que las personas que están por encima de su equipo en su empresa estén más preocupadas de que su equipo se mueva constantemente y que los proyectos se lleven a su finalización lógica.
Como individuo bajo Agile, debería preocuparse más por la cantidad de trabajo que está realizando efectivamente en referencia al resto de su equipo. Si eres nuevo, no se puede esperar que seas demasiado productivo, pero en algún momento de tu período de empleo deberías estar a la par con al menos parte de tu equipo. Si no está generando trabajo, realmente no está haciendo su trabajo.
fuente
Su velocidad promedio es acertada. En mi experiencia, esto es muy útil para las estimaciones de finalización a largo plazo, suponiendo que tenga una gran acumulación de pedidos; pero no tan útil para los compromisos de planificación de sprint.
El proceso que he visto seguido para la planificación del sprint es extraer historias de la parte superior del trabajo atrasado y dejar que el equipo decida si pueden lograrlas. Los equipos han decidido esto en función de la sensación intestinal, desglosando las tareas de 1/2 día, la presión del propietario del producto, la alineación con un objetivo de sprint, la mejor suposición (basada en la velocidad) o alguna combinación de todos ellos.
Ocasionalmente, el propietario del producto ha permitido omitir un par de elementos para poder agregar más.
A veces, el equipo y el propietario del producto acuerdan previamente los artículos elásticos para moverse.
fuente
Esta es una excelente pregunta y es muy importante para que los equipos mejoren. El tema es engañoso y es ampliamente mal entendido El propósito original de señalar historias era encontrar un método rápido y aceptablemente preciso para estimar el Nivel de esfuerzo (LOE) necesario para completar la funcionalidad que se definió en las historias. El objetivo general: dar a los equipos un método de PREDICCIÓN o predecir cuánto tiempo tomaría completar un esfuerzo (como un proyecto). Tu comprensión de Velocity es correcta: son los puntos PROMEDIOS por Sprint completado (realmente HECHO). Entonces, si tiene un proyecto para entregar, y son 250 puntos, y su equipo promedia 25 puntos por sprint, el proyecto tomará aproximadamente 10 sprints, más o menos un poco de tiempo de amortiguación.
Algunas luminarias, como Ken Schwaber, sugieren que la velocidad y los puntos solo se usen para pronósticos a mediano y largo plazo. Sugieren usar horas de tarea como un segundo "control de cordura" sobre lo que realmente se puede hacer en un sprint. Por lo tanto, la cantidad de puntos en cada sprint puede variar según la capacidad. Otros (incluido yo mismo) creen que un equipo maduro se asentará en un patrón de tamaño muy consistente que puede predecir con precisión la capacidad, y eventualmente las horas de tarea se convierten en una carga adicional inútil. (Es crítico actuar para los nuevos equipos durante al menos 6 a 12 sprints, en mi humilde opinión, hasta que el equipo comprenda los puntos y el tamaño de la historia sea precisa).
Su primer pequeño error es que usted dijo que el equipo debería saber la velocidad y aportar tantos puntos de historia. En realidad, los entrenadores alientan a los equipos a deducir del 10% al 20% y comprometerse * a ese nivel. Entonces, si tu equipo tiende a completar 25 puntos por sprint, no llenes el sprint a 25 puntos, sino detente en 20 a 22 puntos. Recuerde: está perfectamente BIEN traer historias cuando se realiza el otro trabajo. Por lo tanto, puede "comprometerse" a 22 puntos y completar 28. Eso es genial. Solo tenga cuidado de no alentar al equipo a "hacer bolsas de arena" y comprometerse constantemente. No hay nada de malo en estirar para ver si podemos hacer más.
Ahora, a su punto sobre la varianza entre sprints. Es un patrón muy común (pero NO ÓPTIMO) ver a un equipo que completa 20 puntos un sprint, luego 50, luego 22, luego 45, luego 15, luego 60. Si calcula la desviación, puede mostrar oscilaciones del 50% al 100% de sprint tras sprint. ¿Por qué los equipos completan solo 15 puntos en un sprint y luego 60 en el siguiente?
Puede significar que el equipo realmente no sabe lo que puede hacer. (Oye, completamos 50 puntos el último sprint, podemos hacerlo nuevamente este sprint).
O, podría indicar que los propietarios de productos están obligando al equipo a comprometerse demasiado, o están agregando trabajo después del inicio del sprint, etc. Estos son solo algunos de los ANTI-PATRONES que podrían estar causando este cambio salvaje en los puntos completados.
Esta medida de previsibilidad es importante para que los maestros de scrum observen y llamen la atención del equipo.
A menudo, la razón por la que completaron pocos puntos en un sprint, y luego muchos puntos en el siguiente sprint es lo que yo llamo la "OLA RODANTE DEL TRABAJO INCOMPLETO". Aquí hay un patrón muy común:
El propietario del producto está bajo presión para cumplir con una fecha. Entonces, el equipo siente la necesidad de tratar de hacer mucho trabajo. Comienzan como un nuevo equipo y no están seguros de lo que realmente pueden hacer.
Entonces, el sprint 1, planean el sprint y, como están en la fase de formación, no pueden completar todo el trabajo. De hecho, tienen un trabajo más incompleto que el trabajo realizado. El trabajo incompleto se INICIA pero es INCOMPLETO. Se pasa al siguiente sprint, y esta vez han hecho más trabajo que incompleto. Para el próximo sprint, esa gran carga de trabajo incompleto cae en HECHO y la confianza del equipo se dispara.
El propietario del producto está entusiasmado y por eso aumentan su carga nuevamente. Al final de este sprint, tienen una ENORME cantidad de trabajo incompleto y una cantidad decepcionante de trabajo REALIZADO.
Aquí comienzas a ver las ONDAS de Done vs Incomplete sprint alterno tras sprint. Si los equipos no se dan cuenta de lo que está sucediendo, este patrón puede continuar durante meses. Pero en promedio, completan alrededor de 24 puntos por sprint. Entonces, ¿qué sucede cuando dejan de comprometerse demasiado?
Notarás que TODAVÍA completan 24 a 26 puntos, pero el trabajo de arrastre se reduce. Ahora, en lugar de sentirse abrumado tratando de completar una cantidad imposible de trabajo, que también destruye la moral del equipo, el equipo puede comenzar a mejorar sus procesos.
Con el tiempo, la velocidad comenzará a aumentar, sin los enormes cambios en el trabajo Hecho-vs-Incompleto.
Si no le permite al equipo un "tiempo flojo", NUNCA tendrán tiempo para realizar un trabajo que los haga más ágiles, más rápidos y mejores. Dev-Ops, por ejemplo, no puede suceder. Prueba de automatización: ¿quién tiene tiempo para eso? Pero estas son precisamente las cosas en las que los equipos necesitan trabajar para que puedan aumentar la velocidad.
fuente