Estimaciones de la historia en Scrum

Question

Iniciamos un proyecto que se gestionará con Scrum/XP. Escribimos todo el trabajo acumulado del producto por adelantado para fines de evaluación. Estamos asegurándonos que todas las historias son centradas en el cliente y los estamos evaluando por

• historia de valor de negocio: Moscú técnica - debe, debería, podría, sería/no tendrá esta implementado
• esfuerzo/complejidad (= puntos de la historia) historia: 1, 2, 3, 5, 8, 13, 21, 100 - relacionado con historia complejidad/esfuerzo en lugar de días ideales duración

100 puntos de la historia puede tener algunas historias con Would/Will have porque en realidad son historias complejas más grandes que luego se desglosarán si es necesario.

Calculado importancia de historia se basa en el esfuerzo de valor & al no superponer historias de MoSCoW.

Pero sin historias de 100 puntos nuestras historias hasta ahora (también desglosadas) tienen una complejidad entre 2 y 8, que creemos que es un tamaño de historia apropiado para evitar la microadministración. Pero algunas historias se relacionaron o dependieron la una de la otra. Tenemos historias que pueden requerir más si se hacen primero, y menos si se hiciera alguna otra historia antes que ellas.

Preguntas
¿Es posible ajustar puntos de la historia más adelante durante el desarrollo, como podemos ver con las tareas de la historia en la que podemos re-evaluar, añadir nuevos, retire existente o es este no es el caso con las historias? Debido a que cambiar su complejidad, también cambiará las estimaciones de fecha de finalización basadas en la velocidad planificada. ¿Cuál es la mejor práctica en este caso?

Answer 1

Puede volver a estimar sus historias de nuevo y debería hacerlo. Los puntos solo se bloquean cuando el equipo se compromete con ellos en la Sesión de planificación de Sprint inmediatamente antes del inicio de un Sprint.

Una práctica que he usado es al hacer la Planificación Sprint individual, debes evaluar cada historia nuevamente. El equipo aprende con el tiempo y se volverá más preciso con estimaciones e identificando dependencias. Recuerde que lo que entra en un Sprint depende del equipo, el propietario del producto define el retraso acumulado general. Si el proyecto tiene un límite de tiempo, no intente hacer que las estimaciones se ajusten a la Fecha de finalización; si lo hace, se está preparando para el fracaso.

Recuerda que con Velocity empiezas a adivinar lo que puedes lograr. Por lo general, no es hasta el 3 ° o 4 ° Sprint al que aciertes identificar una velocidad realista que el equipo pueda administrar. Sí, esto significa que puede haber asumido que el equipo podría entregar 20 puntos por Sprint y en realidad solo puede hacer 15 puntos. Sí, eso significa que el tiempo de entrega se cancela o las historias quedan por debajo de la línea de corte.

En cuanto a las historias dependientes, debe trabajar con el propietario de su producto. Si el equipo les habla, generalmente puede reorganizar las historias. La mayoría de las personas son receptivas a alguien que les dice "Si hacemos A ahora tomará el Sprint completo, pero si lo hacemos A tomará un 15% de un Sprint", eso lo hace bastante convincente.

Una práctica útil para probar es programar las historias dentro del Sprint. Durante la sesión de planificación, una vez que todas las historias son validadas y discutidas, el equipo saca un calendario y habla sobre cuándo quieren que se hagan las cosas. Al poner fechas objetivo en un calendario, ayuda a identificar superposiciones y dependencias entre las historias. Esto puede identificar cosas que son de naturaleza serial y pueden causar que un Sprint falle.

Espero que la información sea útil.

Answer 2

Solo puedo describir mi expiriencia.

Cuando estábamos planeando el primer sprint decidimos que podíamos lograr 18 puntos. Así que tomamos varias historias y la estimación total fue de 15 puntos. Como mencioné anteriormente estábamos dando nuestros primeros pasos en el scrum y es por eso que decidimos que 3 puntos sin usar y el factor de forma 0.6 garantizaban nuestro éxito.

Pero nuestras estimaciones de cada historia son solo aproximadas. También tuvimos algunas historias dependientes. Y no hicimos un plan de implementación de cada historia porque pensamos que es imparcial con una metodología ágil.

Como resultado fallamos en nuestro primer sprint con solo 8 puntos completos.

Antes de nuestro segundo sprint, decidí que debíamos tomar algo de la vieja y simple cascada y las metodologías repetitivas (y yo era un scrum-master). Por lo tanto, en nuestra próxima primavera para planear correctamente, planificamos cada historia (aproximadamente 20 minutos por historia), con diagramas simples, todas las dependencias, detalles de la implementación, etc. La planificación fue difícil y tomó 2 reuniones.

Pero el segundo sprint fue mucho mejor y hemos hecho casi todo (en realidad hemos hecho todo menos algunos errores). Creo que tomaremos menos factor de forma en el tercer sprint y será exitoso.

Answer 3

Según su explicación, ya está haciendo un gran trabajo. Por supuesto, siempre habrá historias con una dependencia. Algunos pueden incluso no tener un valor para el cliente directamente visible; es decir, el esfuerzo inicial para establecer una arquitectura y algunos marcos).Pero si los excluyes, crearás muchas deudas técnicas. Si puede, le sugiero que trate de completar la ecuación y de alguna manera muestre la relación entre las tareas.

Por ejemplo: - la tarea 3 es 8 puntos si se realiza después de la tarea 2, pero 12 puntos si se realiza de forma independiente.

De esta manera, el propietario del producto sentirá el dolor de ignorar las dependencias, pero aún puede elegir hacer las historias más valiosas primero. Si el propietario del producto está seguro de que todas las historias lo hacen en los próximos sprints, puede dirigirlo para que se implementen en el orden más eficiente. Por ejemplo, al bloquear elementos para los que no se han cumplido las dependencias (es decir, solo puede tener la función 'cambiar mi logotipo en el sitio web' después de que se complete la historia 'versión habilitada para web')

¡Buena suerte!

Answer 4

Existen algunos patrones que podrían ayudarlo a dividir User Stories de manera que permanezcan INVEST, lo que significa que intentará guardar las dependencias, el tamaño, la capacidad de prueba y el valor en particular. Puedes leer más sobre esto aquí: http://www.richardlawrence.info/2009/10/28/patterns-for-splitting-user-stories/ Richard los aplica activamente y los mejora, y él no está solo ;-)

Solo ten en cuenta que dividir y mantener dependencias (que es como crear una ruta crítica en un diagrama de Gantt) va a superar la capacidad del equipo para ser creativo, y para negociar sobre esas historias, y también podría ocultar una "proposición no valiosa".

HTH
ANdreaT