estimaciones de la historia en Scrum [cerrada]

Question

Comenzamos un proyecto que será gestionado con Scrum / XP. Escribimos toda la pila de 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 historia / complejidad (= puntos de la historia): 1, 2, 3, 5, 8, 13, 21, 100 - relacionado con historia complejidad / esfuerzo en lugar de la duración días ideales

100 puntos de la historia pueden tener algunas historias con Would / No tendrá porque en realidad son complejas historias más grandes que se descomponen más tarde si es necesario.

Calculado importancia historia es la base del valor y esfuerzo por parte de no superposición de historias Moscú.

Pero sin 100 historias de punto de nuestras historias hasta ahora (también descomponen) tiene complejidad entre 2 y 8, que creemos que es un tamaño adecuado para evitar la historia de la microgestión. Sin embargo, algunos se convirtieron en historias relacionadas o dependientes entre sí. Tenemos historias que pueden tardar más si se hace primero, y menos si alguna otra historia sería hecho delante de ellos.

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 el cambio de su complejidad, también cambiará estimaciones actualizadas de gama basado en la velocidad prevista. ¿Cuál es la mejor práctica en este caso?

Answer 1

A pesar de todo puede estimar sus historias una y debería hacerlo. Los puntos sólo están aseguradas cuando el equipo se compromete a ellos en la sesión de planificación de Sprint inmediatamente antes del comienzo de un Sprint.

Una de las prácticas que he usado es cuando se hace la planificación de Sprint individuo debe evaluar cada historia de nuevo. El equipo aprende con el tiempo y será más preciso con las estimaciones y la identificación de las dependencias. Recuerde lo que pasa en un Sprint es hasta el equipo, el dueño del producto define el retraso global. Si el proyecto es limitada en el tiempo no tratan de hacer que las estimaciones se ajustan a la fecha de finalización, si lo hace usted se está preparando para el fracaso.

Recuerde que la velocidad con la que comienza con una suposición de lo que puede lograr. Por lo general, no es hasta la tercera o cuarta Sprint que se golpea identificar a una velocidad realista que el equipo puede manejar. Sí, esto significa que es posible que haya asumido el equipo podría entregar 20 puntos por Sprint y en realidad sólo se puede hacer 15 puntos. Si eso significa que el tiempo de entrega se apaga o historias caen por debajo de la línea de corte.

En cuanto a historias dependientes que debe trabajar con su dueño del producto. Si el equipo habla con ellos por lo general puede reorganizar historias. La mayoría de las personas son receptivas a alguien que les dice "si hacemos un ahora que tomará el pleno Sprint, pero si lo hacemos Una tarde tomará el 15% de un Sprint" que hace que sea muy convincente.

Una práctica útil para probar es la programación de las historias dentro de la Sprint. Durante la sesión de planificación una vez que todas las historias son validados y discutieron el equipo se extrae un calendario y discutir cuando se quiere tener las cosas. Al poner las fechas previstas en el calendario que ayuda a determinar las superposiciones y las dependencias entre las historias. Esto puede identificar las cosas que son de serie en la naturaleza y puede causar un Sprint falle.

Esperamos que esta información es útil.

Answer 2

A partir de su explicación que estás haciendo un gran trabajo ya. Por supuesto que siempre habrá historias con una dependencia. Algunos ni siquiera pueden tener valor para el cliente directamente visibles; es decir, el esfuerzo inicial para establecer una arquitectura y algunos marcos). Pero si los dejas fuera que va a crear una gran cantidad de deuda técnica. Si es posible, me gustaría sugerir que trate de hacer que la ecuación completa y de alguna manera mostrar la relación entre las tareas.

Por ejemplo: - tarea 3 es de 8 puntos si se hace después de la tarea 2, pero 12 puntos si se hace independientemente

.

De esta manera el dueño del producto va a sentir el dolor de ignorar las dependencias, pero todavía se puede hacer una elección para hacer las historias más valiosos en primer lugar. Si el dueño del producto es asegurarse de que todas las historias de hacerlo en las próximas carreras, entonces se puede dirigir a ellos han implementado en el orden más eficiente. Por ejemplo, mediante el bloqueo de artículos para los cuales no se han cumplido las dependencias (es decir, que sólo puede tener el 'cambio mi logotipo en la página web' característica después de la historia 'webenabled versión' se ha completado.)

Buena suerte!

Answer 3

Sólo puedo describir mi Expirience.

Cuando estábamos planeando primer sprint decidimos que podríamos lograr 18 puntos. Así que tomamos varias historias y la estimación total fueron 15 puntos. Como he mencionado anteriormente que estábamos haciendo nuestros primeros pasos en el scrum y por eso hemos decidido que 3 puntos no utilizados y de factor de forma de 0,6 garantizado nuestro éxito.

Sin embargo, nuestras estimaciones de cada historia eran sólo aproximados. También tuvimos algunas historias dependientes. Y no hicimos el plan de ejecución de cada historia porque pensamos que es unnessecary con la metodología ágil.

Como resultado, hemos fallado a nuestros primer sprint con sólo 8 puntos completos.

Antes de la segunda carrera decidí que deberíamos tomar algo de la vieja buena cascada simple y methodoligies iterativos (y yo era un scrum master). Por lo tanto, en nuestra próxima planificación de primavera para hacer estimaciones correctas se planificó cada historia (unos 20 minutos por la historia), con diagramas simples, todas las dependencias, detalles de implementación y así sucesivamente. La planificación fue difícil y tardó 2 reuniones.

Pero la segunda carrera fue mucho mejor y hemos hecho casi todos (en realidad hemos hecho todo, pero con algunos errores). Creo que vamos a tener menos de factor de forma en la tercera carrera y va a ser un éxito.

Answer 4

Hay algunos patrones que ayuden en la división de historias de los usuarios de manera que permanecerían INVEST, lo cual significa que intentar salvar las dependencias, el tamaño, la capacidad de prueba y el valor en particular. Puede leer más sobre esto aquí: http: // www.richardlawrence.info/2009/10/28/patterns-for-splitting-user-stories/ Richard es la aplicación activa y la mejora de ellos, y que no está solo; -)

Ten en cuenta que la división y de mantenimiento de las dependencias (que es como la creación de una ruta crítica en un diagrama de Gantt) va a dejar sin efecto el capacidad del equipo para ser creativo, y para negociar en esas historias, y también podría ocultar un " no valiosa-proposición".

HTH
ANdreaT