Soy Scrum Master de un equipo de 12 miembros. Sé que el tamaño del equipo es grande en este momento, pero a medida que crezcamos más, dividiremos el equipo en varios Equipos Scrum. Nuestras estimaciones para las historias de usuario se basan en puntos de historia. Para las tareas dentro de una historia de usuario, estamos estimando en horas. Sobre la base de los primeros 6 Sprints, pudimos establecer una velocidad de equipo.
No tuvimos ningún problema para tomar las Historias de usuario, porque sabíamos cuántas Historias de usuario podíamos tomar para el Sprint en función de nuestra Velocidad. Cuando un par de miembros del equipo se tomaron una licencia planificada, no pudimos estimar la cantidad de Story Points que teníamos que comprometer. Dado que no estamos calculando la Velocidad por miembro del equipo, no podemos estimar cuántos Puntos de Historia debemos tomar para el próximo Sprint. Entonces, mi pregunta es ¿cómo calculamos los puntos de la historia que podemos asignar al sprint cuando algunos de los miembros del equipo están de licencia ?
Mi segunda pregunta es que estamos calculando la cantidad de horas que cada miembro del equipo está disponible para el sprint. Como no deberíamos asignar directamente Story Points a horas, no vemos el valor de calcular la cantidad de horas para cada miembro del equipo durante la reunión de planificación de Sprint. ¿Cómo establecemos una relación entre las horas y los puntos de la historia?
La velocidad no es un objetivo de gestión. Es una herramienta de estimación, y deberías usarla como una herramienta entre muchas para ayudarte a planificar tus Sprints. No trate las métricas de velocidad como objetivos, ni el mantenimiento de una velocidad dada como el objetivo principal de cada Sprint.
Las horas y los puntos de la historia no tienen una relación directa entre sí. Los puntos de historia miden el esfuerzo relativo, mientras que las horas miden el tiempo ideal o de reloj de pared. Ambos son útiles, pero no son intercambiables.
La velocidad es un rango , no un valor único, y generalmente es más útil cuando:
Sin embargo, a menos que haya recopilado suficientes datos de velocidad para amortizar las variaciones en la capacidad, debe aplicar algo de sentido común en su lugar. Considere estos ejemplos:
Si ha estado haciendo Scrum durante un año, las personas se toman días de enfermedad, se van de vacaciones o trabajan por encima o por debajo de su capacidad típica de vez en cuando. Velocity promedia esos puntos de datos a lo largo del tiempo y le permite hacer estimaciones razonables de todos modos.
Solo ha estado haciendo Scrum durante dos meses y ha tenido todas las manos a la obra para ambos Sprints. No tiene datos sobre la variación normal y no tiene información sobre la capacidad máxima o mínima del equipo. Por lo tanto, tendrá que aplicar un factor de fudge .
En Scrum, el objetivo principal de Sprint Planning es evitar el compromiso excesivo durante un Sprint. La idea no es cumplir con la falacia de utilización del 100%; no tienes que empacar cada Sprint hasta las vigas en función de tu velocidad anterior.
La forma en que funciona Sprint Planning es que la velocidad simplemente ofrece orientación, lo que le permite saber si ha superado los límites razonables de trabajo en curso para un solo Sprint. Depende únicamente del equipo de desarrollo determinar cuántos puntos de la historia pueden caber cómodamente dentro de la iteración actual.
En su ejemplo, cuando tenga poco personal para un Sprint, se espera que el equipo reconozca este hecho y se adapte en consecuencia durante la Planificación del Sprint. Por ejemplo, el equipo podría decir:
Normalmente tratamos de limitar los puntos de nuestra historia a 10-15 puntos por sprint. Sin embargo, a Bob le están colocando implantes cibernéticos basados en COBOL en su corteza cerebral, por lo que probablemente solo deberíamos comprometernos con 8 puntos o menos esta vez.
Luego, el equipo acepta solo 8 puntos en el Sprint, según su capacidad esperada. Sin embargo, si terminan antes de tiempo, pueden (y deben) volver al Product Owner para:
La primera es la práctica más común, pero la segunda es ciertamente aceptable dentro de los límites del marco Scrum. Realmente solo depende de lo que funcione mejor para su equipo.
La velocidad del equipo es una medida del desempeño anterior del equipo: cuánto valor pudieron producir en cada sprint y se mide en puntos de historia. Velocity es útil para predecir cuántas historias podrá completar el equipo en el próximo sprint. Sin embargo, la velocidad no es el único factor para predecir esto. La capacidad del equipo puede ser otro factor. Tomemos un ejemplo:
Tu equipo tiene 5 miembros y la velocidad es de 60 puntos de historia por sprint. Un miembro está de vacaciones durante el próximo sprint. Entonces la capacidad del equipo disminuirá en un 20%. Su velocidad estimada para ese sprint sería entonces de 48 puntos de historia. 60 * (100% - 20%) = 60 * 0,80 = 48
Esta es una opción que se puede considerar, supongo.
Debido a la complejidad de un equipo, nunca podrá calcular la relación Story Point / Person. Entonces, cuando armes el Sprint Backlog, usa las Historias de usuario del Backlog y el plan de capacidad (esto te dice cuántas personas estarán a bordo durante el próximo Sprint) . Te comprometes en base a estos datos. Velocity te ayuda a no comprometerte demasiado en un Sprint. Así que no es tan útil.
Según su pregunta, no está utilizando las horas estimadas para nada. Si su trabajo se basa en Story Point, no necesitará las horas en absoluto. Si es posible, no intente convertir Story Points en horas. No son convertibles, como si no pudieras convertir un caballo en una bicicleta. Ambos se pueden usar para viajar, pero no hay otras similitudes.
Sin embargo, hay algo que puede probar, que puede ayudarlo con su primera pregunta. Si estima las horas para las tareas, puede resumirlas y, en función de la capacidad, puede verificar si la suma se ajusta a su próximo Sprint . Por ejemplo, tiene 2 historias de usuario. US1 tiene 2 tareas y la suma es de 48 horas. US2 tiene 3 tareas y la suma es de 68 horas. Digamos que los 12 compañeros pueden hacer 120 horas en un Sprint. Sin 2 solo tienes 100 horas, por lo que US1 + US2 no encajarán en tu Sprint. Puede omitir US2 o dividirlo en US2.1 y US2.2. Creo que esto podría funcionar en tu caso.
Creo que estás usando el término de velocidad de manera incorrecta, volvamos a lo básico. El punto de la historia es una estimación de alto nivel del esfuerzo necesario para implementar una historia, que se usa generalmente durante la planificación del lanzamiento o la sesión previa a la planificación.
La velocidad es el total de puntos de la historia implementados durante el sprint anterior y esto variará de un sprint a otro. Los puntos de historia y la velocidad de sprint nos dan una guía sobre las historias estimadas que se comprometerán en los próximos sprints.
La estimación de horas de tareas ocurre durante la planificación del sprint, es una estimación de bajo nivel realizada para representar el esfuerzo real en horas necesarias para cumplir con todos los requisitos de una historia.
A su primera pregunta, no hay forma científica de hacer esto. Aquí hay una manera rápida y sucia.
Fracción de personas en el equipo esta iteración x la velocidad del equipo. Entonces, si la velocidad de su equipo es 10 y 1/3 de su equipo está fuera, 6 podría ser un pronóstico justo de cuál podría ser su velocidad. Tener un rango sería mejor, así que quizás 5-8 en el escenario anterior. El valor está en comprender las suposiciones que usó para ajustar su pronóstico de velocidad.
Hagas lo que hagas, la velocidad es una herramienta que ayuda a los miembros del equipo a discutir y comprender el trabajo que están haciendo. Entonces, si los miembros del equipo están fuera y no está seguro de cuán útil es la velocidad como herramienta, simplemente pregunte a los miembros restantes del equipo "¿Parece razonable lo que estamos pronosticando o pronosticando en función de nuestra velocidad ajustada?"
A tu segunda pregunta. No te molestes. Los puntos de la historia son distribuciones a lo largo del tiempo y no se deben usar para la planificación de la capacidad o la generación de informes fuera del equipo. Si desea ingresar a metodologías ágiles basadas en el tiempo, su proxy más cercano será lean kanban utilizando el tiempo de ciclo y su variación.
Si no ve valor en calcular la cantidad de horas que cada miembro del equipo tiene disponible para cada iteración, deje de hacerlo :). Es muy común que los equipos de scrum dejen de poner estimaciones de horas en sus tareas una vez que se dan cuenta de que la velocidad y las prácticas consistentes de estimación de puntos de historia son lo suficientemente buenas para crear un pronóstico/compromiso.