¿Cómo medir la estimación y los puntos de la historia en Scrum? [cerrado]

Question

Tomemos un ejemplo, supongamos que tenemos 5 historias A, B y C, D, E.

Importance Name Estimate
90         B 
70         A 
50         C 
35         E
10         D 

Las historias están ordenadas según su importancia (prioridad). ¿Cómo los estimas? ¿Se estima en función del tamaño de la función? Por ejemplo, les he dado valores estimados:

Importance Name Estimate
90         B     10
70         A     12 
50         C     9
35         E     20  
10         D     11

Supongamos que es un sprint de 2 semanas. Este es un tiempo de 14 días = 5,14x5 = 70 días-hombre. Ahora, ¿qué significa el valor 10? ¿Significa la cantidad de tiempo (horas o días) que un equipo debe pasar? ¿Y qué son los puntos de la historia? Supongamos que este es el primer sprint; ¿Cómo va a estimar el número de sprints cuando no tiene la velocidad del último sprint?

Answer 1

¡Argh! Me sirve para escribir de memoria.

Un punto de historia está relacionado con la estimación, por supuesto, y cuando intentas calcular cuánto puedes hacer para un sprint, un punto de historia es una unidad de "trabajo". necesario para implementar parte o una característica completa. Un punto de la historia podría ser un día, o una hora, o algo intermedio. He confundido la "estimación" y "punto de historia" a continuación, no sé lo que estaba pensando.

Lo que escribí originalmente era "estimaciones" y "puntos de historia". Lo que quise escribir (y editado a continuación) fue "puntos de historia". y "velocidad".

---

Los puntos y la velocidad de la historia van de la mano, y trabajan juntos para tratar de darle una idea de cuánto podemos completar en un período de tiempo determinado.

Tomemos un ejemplo.

Supongamos que desea estimar características en horas, por lo que una característica que tiene una estimación de 4 tardará 4 horas en completarse, por una persona, por lo que asigna dicha estimación a todas las características. Por lo tanto, considera que esa característica, o su "historia", vale 4 puntos cuando se trata de competir por los recursos.

Ahora también digamos que tiene 4 personas en su proyecto, cada una de las cuales trabaja una semana normal de 40 horas, pero, debido a otras cosas que suceden a su alrededor, como apoyo, conversación, marketing, reuniones, etc., cada persona solo podrá trabajar el 75% en las características reales, el otro 25% se utilizará en esas otras tareas.

Entonces cada persona tiene 30 horas disponibles cada semana, lo que le da 30 * 4 = 120 horas en total para esa semana cuando cuenta las 4 personas.

Ahora también digamos que está intentando crear un sprint de 3 semanas, lo que significa que tiene 3 * 120 horas de trabajo que puede completar. Esta es su velocidad, qué tan rápido se está moviendo, cuántos "puntos de historia" puedes completar.

La unidad de tu velocidad tiene que ser compatible con la unidad para tus puntos de historia. No puede medir historias en "cuántas tazas consumirán los desarrolladores al implementar esto". con " cuántas horas tenemos disponibles " ;.

Luego, intentas encontrar un conjunto de características que juntas tengan cerca de 120 puntos, pero no más, clasificados por su prioridad. Esto sería simplemente sumar acumulativo desde arriba y hacia abajo hasta que llegues a una tarea que incline la suma por encima o por debajo de esos 120 puntos. Si se volcó, no incluya la tarea.

Podría estimar fácilmente en días, o tazas de café consumidas por el desarrollador, tal como el número es representativo del tipo de trabajo que está haciendo, y puede estar relacionado con el trabajo real que realizará ( es decir, cuánto tiempo tienes disponible).

También debe evaluar su carga de trabajo después de cada sprint para determinar si ese número del 75% es exacto. Por ejemplo, si solo manejaste la mitad de lo que te propusiste hacer, averigua si tus estimaciones de características eran incorrectas o si tus estimaciones de carga de trabajo eran incorrectas. Luego, tenga en cuenta lo que ha aprendido al estimar y planificar los siguientes sprints.

También tenga en cuenta que las características deben dividirse si se vuelven demasiado grandes. La razón principal de esto es que las estimaciones más grandes tienen mucha más incertidumbre incorporada, y puede mitigar eso al dividirlo en subcaracterísticas y estimarlas. La gran característica general se convierte en la suma de todas las subfunciones. También podría darle la capacidad de dividir la función entre varias personas, al asignar diferentes subfunciones a diferentes personas.

Una buena regla general es que las características que tienen una estimación de más de 1 día probablemente deberían dividirse. *

Answer 2

Recuerde que los puntos son solo ROM (orden de magnitud aproximado) establecido mediante el uso de " Planning Poker " como una práctica común Los primeros Sprints son cuando comienzas a identificar qué significan los puntos para el equipo y cuanto más tiempo pasas, más preciso se vuelve el equipo.

Además, busca usar puntos que estén un poco más espaciados. Una práctica que he visto y usado es usar la secuencia fibonacci , se asegura de que no No tiene demasiadas diferencias de 1 punto.

Tampoco se olviden de los evaluadores, cuando señalan una historia, cualquiera que esté probando debe tener en cuenta que a veces una simple tarea de desarrollo puede causar un gran esfuerzo de prueba y, si son verdaderos Sprints, la idea es tener todo completado como podría ser enviado (construido, probado y documentado). Entonces, la estimación de una historia la determina el equipo, no un individuo.

Answer 3

El valor 10 es simplemente un valor relativo a las otras estimaciones, p. es la mitad de un 20 o un poco más difícil que un 9. No hay una traducción específica de 1 punto = x horas de esfuerzo es algo a destacar.

Donde trabajo, tenemos lo que llamamos "puntos épicos" que es lo difícil que es una historia de alto nivel, por ejemplo. integre Search en un nuevo sitio web, que consistirá en múltiples historias para completar y luego estimamos las horas en cada historia que se crea al desglosar cada epopeya, por ejemplo. simplemente ponga Buscar documentos de soporte en el sitio. Los "puntos épicos" se distribuyen en una variación de los números de Fibonacci (1,2,3,5,8,13,21,28,35) para que las epopeyas más amplias y vagas obtengan un gran valor, p. algo mayor que 8, es un indicador de que se puede dividir en historias más fácilmente estimables. También vale la pena señalar aquí que donde trabajo solo trabajamos 5 días a la semana y en cada sprint se pierde un día en reuniones como la demostración, la reunión de planificación de iteraciones, la retrospectiva y la revisión, por lo que solo hay 9 días para un sprint. Agregando programación en pares para algunas cosas, tiempo para corregir errores y otros trabajos que no son del proyecto, como tickets de soporte, y se vuelve bastante difícil decir cuántas horas pasarán el puñado de desarrolladores en el sprint.

Los primeros sprints son donde los valores comienzan a ser más concretos, según la experiencia adquirida, las estimaciones pueden ser más claras en términos de cómo adivinar el valor.

Answer 4

Con un nuevo equipo o proyecto siempre comenzamos asumiendo que un punto de la historia es un solo "día ideal", y calculamos que cada desarrollador obtiene alrededor de 3.5 días ideales por semana, que es cómo calculamos nuestra probable velocidad inicial.

Una vez que hayas pasado por la "planificación de póker" escenario y equilibrado / comparado todas sus historias, la duración real de un punto de la historia es realmente desconocida: todo lo que realmente tiene es una muy buena idea de la duración relativa , y use su mejor criterio para venir con una velocidad probable.

¡Al menos, así es como lo hago!

Si también está apuntando a que sus puntos de la historia sean aproximadamente iguales a un día ideal, entonces sugeriría dividir sus historias en historias más pequeñas, de lo contrario no pasará un buen momento planeando y rastreando iteraciones.

Answer 5

Buenas respuestas por todas partes.

Un punto que me gustaría agregar es que no es realmente importante lo que elijas como base para el valor de tus puntos (horas, días ideales, cualquier otra cosa). Lo importante es mantenerlo consistente.

Si lo mantiene constante, le permitirá descubrir la "velocidad verdadera" de tu equipo Por ejemplo, supongamos que tuvo pocas iteraciones:

iteration 1 = 120 points
iteration 2 = 95 points
iteration 3 = 115 points

Y ahora está comenzando la iteración 4 y tiene lo siguiente en la cartera (ordenada por prioridad):

item 1 = 50 points
item 2 = 30 points
item 3 = 30 points
item 4 = 40 points

Ahora, suponiendo que sus estimaciones de puntos sean consistentes, puede estar razonablemente seguro de que el equipo terminará los elementos 1,2 y probablemente 3, pero definitivamente no 4.

Puede aplicar lo mismo para liberar la cartera de pedidos para mejorar su predicción de la fecha de lanzamiento. Esto es lo que permite a los equipos Scrum mejorar sus estimaciones a medida que avanzan.

Answer 6

JB King tiene la mejor respuesta, pero no tiene votos, lo que significa que se propaga información incorrecta y contribuye a la interpretación generalmente pobre de scrum. Vea las respuestas reales de una de las personas que diseñaron Scrum aquí:

http: //blog.mountaingoatsoftware.com/seeing-how-well-a-teams-story-points-align-from-one-to-eight

Recuerde, se trata de esfuerzo, no de complejidad.

Ahora lea y vea un video aquí:

http://www.agilebok.org/index.php?title=Relative_Sizing_and_Story_Points