Siguientes figuras que muestran el desempeño de un equipo Scrum durante los primeros 6 sprints de un proyecto.
Pregunta 1: ¿Cuál es la velocidad del equipo?
Pregunta 2: ¿Cuántos Story Points es probable que logre este equipo en Sprint 7?
Pregunta 3: Ahora, si tiene una tabla como la siguiente y representa la acumulación de productos. ¿Qué historias seleccionaría para el sprint 7 y por qué?
+---------------+
| Story Id | SP |
+---------------+
| S1 | 3 |
| S2 | 1 |
| S3 | 3 |
| S4 | 5 |
| S5 | 8 |
| S6 | 3 |
| S7 | 1 |
| S8 | 1 |
| S9 | 5 |
+---------------+
Pregunta 4: Y según los datos anteriores, ¿cuántos sprints se requieren para terminar el proyecto?
Pregunta 5: Dibuje un gráfico de trabajo pendiente para este proyecto de Scrum utilizando los datos proporcionados en las dos tablas anteriores. ¿Qué se puede inferir de este gráfico de trabajo pendiente?
Pregunta 1: ¿Cuál es la velocidad del equipo?
Ya lo anotaste en tu pregunta, es simplemente la cantidad de Story Points "quemados" en un sprint ( Velocidad ). Entonces, en Sprint 1, su velocidad es 15. Por favor, no solo se cuentan las historias "terminadas". Lo que es más interesante es la necesidad de velocidad promedio para la pregunta dos.
Pregunta 2: ¿Cuántos Story Points es probable que logre este equipo en Sprint 7?
La velocidad "promedio" es más interesante, porque te ayudará a pronosticar la velocidad para los próximos sprints. Esto se puede hacer simplemente sumando todos los puntos de historia de los sprints anteriores y dividiéndolos por la cantidad de sprints. En su caso, esto puede conducir a:
(15 + 5 + 20 + 15 + 25 + 10) / 6 = 90 / 6 = 15
Debido a que su velocidad cambia con el tiempo (se vuelve más rápido, cambia la composición del equipo, etc.), solo puede realizar los últimos 3 sprints. Scrum Inc. recomienda el tiempo de ayer para pronosticar el próximo Sprint, también con respecto a la cantidad de miembros del equipo disponibles.
Pregunta 3: Ahora, si tiene una tabla como la siguiente y representa la acumulación de productos. ¿Qué historias seleccionaría para el sprint 7 y por qué?
Si la tabla representa un backlog priorizado (¡esto es obligatorio en Scrum!), tomaría las primeras X Historias dependiendo de su velocidad estimada para el próximo sprint.
El orden solo depende del Product Owner, él/ella es el único que prioriza el backlog. Hay varios enfoques para hacer esto:
Pregunta 4: Y según los datos anteriores, ¿cuántos sprints se requieren para terminar el proyecto?
Tomemos la velocidad promedio calculada arriba (15SP). Su Backlog tiene un tamaño total de
3 + 1 + 3 + 5 + 8 + 3 + 1 + 1 + 5 = 30SP
Entonces, en teoría, podría terminar el proyecto dentro de dos Sprints.
(!) Pero tenga en cuenta que todos estos números son estimaciones y NO hechos. Tu velocidad más baja fue de 5SP y la más alta de 25SP, por lo que, en el peor de los casos, es posible que necesites 6 Sprints o más para terminarlo.
No hay nada de malo en hacer preguntas académicas o de tarea, pero está mal visto hacer preguntas en las que no te has esforzado en resolverlas por ti mismo. Además, las preguntas de la tarea no siempre tienen respuestas canónicas porque la única respuesta "correcta" es la que busca el profesor.
Dicho esto, vale la pena responder las preguntas que está haciendo por dos razones:
Mis respuestas a continuación lo ayudarán a responder sus preguntas de la tarea con mayor conocimiento, pero pueden o no ser las respuestas que su maestro esperaba que proporcionara. Por lo tanto, su kilometraje variará. ¡Buena suerte con tu asignación!
Para valores de velocidad de 15, 5, 20, 15, 25, 10, tiene una velocidad media de 15. Existe un 90 % de probabilidad (técnicamente, un intervalo de confianza) de que su velocidad real para su próximo Sprint se encuentre entre 5 y 25. .
Consulte la Calculadora de rango de velocidad para conocer las matemáticas detrás de este cálculo. Si lo prefiere, puede hacer sus propios cálculos con un intervalo de confianza diferente.
Puede seleccionar cualquier combinación de historias que desee, siempre que el total sea menor que la capacidad esperada del equipo y que todas las historias seleccionadas se relacionen con el Sprint Goal actual. Sin ningún factor de engaño o discusiones sobre la tolerancia al riesgo para un Sprint Goal no alcanzado, entonces asumiría 15 puntos de historia como un objetivo confiable más o menos una pequeña historia.
Sprint Planning es en parte un problema de mochila , pero se complica aún más por el requisito de seleccionar historias en orden de prioridad desde la parte superior del Product Backlog y garantizar que todas las historias seleccionadas contribuyan a (o al menos, no resten valor) a la coherencia. de un Sprint Goal singular. Es por eso que se alienta al equipo de desarrollo y al propietario del producto a discutir historias y hacer algunas negociaciones durante las reuniones de refinamiento de la cartera de pedidos y planificación de Sprint: para permitir que el propietario del producto edite y vuelva a priorizar la cartera de productos sobre la marcha para optimizar las historias para la selección del equipo.
El equipo no puede elegir historias basándose únicamente en estimaciones de tamaño, ni se deben seleccionar historias basándose principalmente en tratar de maximizar la cantidad de puntos de historia para el Sprint. En Scrum, el equipo debe seleccionar las historias en estricto orden de prioridad del Product Backlog hasta que se asigne su capacidad esperada para el Sprint, pero es el trabajo del Product Owner asegurarse de que el orden de prioridad refleje una coherencia central para el Sprint.
Aceptar historias basadas en valores ordinales hasta (pero nunca más allá) de la previsión de capacidad del equipo puede parecer contradictorio, pero en realidad no debería ser así. Hablando pragmáticamente, los equipos Scrum optimizan la coherencia y una cadencia confiable en lugar de la velocidad por sí misma. La velocidad es solo un indicador de la capacidad para ayudar con la previsión.
Los diseñadores de algoritmos se esfuerzan por encontrar soluciones óptimas al problema de la mochila. Los equipos de Scrum se esfuerzan por entregar valor a una cadencia confiable. Demasiado enfoque en optimizar la velocidad es un anti-patrón distinto.
Le quedan 30 puntos de historia en su cartera de productos. Suponiendo que haya estimado con precisión y que no cambien las estimaciones durante el resto del proyecto (se espera que los equipos vuelvan a estimar en función de la nueva información durante el refinamiento de la cartera de pedidos y la planificación de Sprint) y también suponiendo que no agregue ni elimine nada de su producto Backlog durante los próximos dos Sprints, luego, a su velocidad actual, le llevará al menos dos Sprints completar la totalidad del backlog actual.
Tenga en cuenta que dado que un Sprint proporciona un incremento potencialmente liberable al final de cada iteración, es posible que el proyecto pueda declararse suficiente y cerrarse después del Sprint actual. Alternativamente, si su equipo entrega menos que la mediana (su intervalo de confianza tiene cinco puntos de historia como su pronóstico de extremo inferior), entonces puede tomar hasta seis Sprints para completar todo el Product Backlog tal como está constituido actualmente.
Mientras que el peor de los casos reales es siempre:
según la probabilidad estadística, tiene un 90 % de posibilidades de completar al menos cinco puntos de la historia en su próximo Sprint. Debe volver a calcular sus probabilidades en cada Sprint, pero para fines de pronóstico, seis Sprints es un límite exterior razonable dados sus datos.
¿Cuál es la velocidad del equipo?
El equipo aún no ha logrado una velocidad estable. No esperaría necesariamente la cantidad exacta de puntos de historia logrados, pero una variación de 10 a 15 puntos de historia entre cada sprint parece excesiva. Aunque esto puede depender de los valores de puntos de la historia que se usen, estoy más familiarizado con el uso de un conjunto de 1-3-5-8-13-20-40 donde las historias con un tamaño de 20 o 40 deben reevaluarse para ver si no se puede descomponer en historias más pequeñas que también agregan valor a las partes interesadas.
¿Cuántos Story Points es probable que alcance este equipo en el Sprint 7?
Planearía lograr aproximadamente 10-15 puntos de historia en el Sprint. Esto se basa en la guía de que utiliza el último Sprint completado como punto de referencia para planificar el próximo Sprint. Una vez que alcances una velocidad estable, probablemente estarás completando casi la misma cantidad de puntos en cada sprint, sprint tras sprint.
Ahora, si tiene una tabla como la siguiente y representa la acumulación de productos. ¿Qué historias seleccionaría para el sprint 7 y por qué?
Mi propuesta inicial al equipo sería incorporar las Historias 1-4, para un total de 12 Puntos de Historia. Está un poco más que completado en el Sprint 6, pero la mayoría de los Sprints lograron más de 10 (solo 2 no lo lograron). Si el Product Backlog se ha priorizado adecuadamente, estos también representan las historias de mayor valor agregado para las partes interesadas.
Sin comprender completamente por qué la velocidad del equipo fue baja en Sprint 2 y 6, no es posible ir más allá de las matemáticas simples para determinar por qué el equipo fue bajo. Tampoco tiene en cuenta los cambios en la capacidad: vacaciones, licencia por enfermedad, miembros del equipo que apoyan otros trabajos, etc.
Y según los datos anteriores, ¿cuántos sprints se requieren para terminar el proyecto?
Es mejor no tratar de responder a esta pregunta a menos que sea necesario. El objetivo de los métodos ágiles es admitir la entrega incremental de software hasta que las partes interesadas que financian el proyecto decidan que las funciones que quedan en el backlog no valen el costo de una o más iteraciones. Sin embargo, puede haber casos en los que necesite intentar estimar, como una propuesta de contrato para un contrato a largo plazo.
Quedan 30 Story Points en el backlog. Suponiendo que no se elimine ninguna historia y que no se agregue ninguna, y según los datos históricos, estimaría que se requieren entre 2 y 6 sprints para terminar el trabajo. Por supuesto, depende de su intervalo de confianza. Según los datos históricos, no es probable que el equipo complete dos Sprints consecutivos de más de 15 puntos de historia. Es más probable que se necesiten al menos 3 o 4 Sprints para terminar el trabajo restante.
Todd A. Jacobs
tapu74