¿Cuál es la mejor explicación de qué son los Story Points?

Estamos comenzando a usar Story Points aquí para nuestro desarrollo ágil, pero me resulta difícil explicarlo y tampoco puedo encontrar una respuesta definitiva a lo que son. Lo mejor que puedo hacer es señalar otros sitios (como http://blog.mountaingoatsoftware.com/tag/story-points ) y dar una vaga generalización de lo que son. Estoy buscando una buena explicación con algunos ejemplos de uso que puedan ser útiles para otros. ¿Hay buenos recursos para explicar los puntos de la historia?

Esto puede ayudar como titular: Mike Cohn sobre los puntos de la historia . Pero este es mucho mejor: Equipos de desarrollo ágil: alcance y escala con Mike Cohn

La solución de Mike a las métricas de estimación de software es simple y efectiva. Hechos biológicos:

• El cerebro humano simplemente no puede estimar a tiempo correctamente. Especialmente si más de unas pocas horas.
• Esto se amplifica en gran medida por la cantidad de incertidumbres en el desarrollador de software, las presiones psicológicas de la administración (cuando estima, se compromete ...) y la diferencia en las habilidades en el equipo.
• Sin embargo, somos bastante buenos para comparar cosas. Somos bastante precisos allí.

La idea es tomar una historia de usuario de referencia , luego darle una cantidad arbitraria de puntos (historia) , luego otras historias obtendrán puntos relacionados con esa referencia.

Si su historia de referencia es de 100 puntos, y otra historia es tres veces más grande, entonces serán 300 puntos.

Para convertir los puntos de la historia en tiempo para su planificación, debe conocer su velocidad .

Para obtener una velocidad precisa, debe hacer algunas iteraciones y calcular cuántos puntos completó su equipo en un período de tiempo determinado.

Funciona .

Estoy de acuerdo con todo @Pierre 303: dicho anteriormente: (aparte del punto de referencia 100).

Lo único que me gustaría agregar (énfasis) es que no somos buenos para estimar tareas. Podemos estimar tareas en relación con otras tareas siempre que sean aproximadamente del mismo tamaño. Cuanto mayor es la diferencia entre las tareas, peor nos ponemos.

Por lo tanto, no estoy de acuerdo con el uso de un punto de partida de 100.

No es como si estimara la próxima tarea como el 42% de la tarea de referencia. Es la misma mitad del trabajo, el doble del trabajo, el triple del trabajo, etc.

Nuestro equipo usa Planing Poker : en esto tenemos una tarea de referencia de 2 puntos de historia. Luego usamos la serie de Fibonacci para estimar tareas: 1,2,3,5,8,13,21, ¿Enorme? en relación con la tarea de referencia (en lugar de Fibonacci, he visto a otros equipos usar poderes de 2. 1,2,4,8,16,32, enorme ,?) He visto a otros equipos usar (pequeño (1), mediano ( 2), grande (3), XLarge (4) cuando calcularon la velocidad, todavía funcionaba).

El punto es que a medida que aumenta el tamaño de la tarea en relación con la tarea de referencia, somos menos capaces de estimar con precisión su costo. Entonces no tiene sentido intentarlo. Esto se refleja en el gradiente más grande al final del recorrido de estimación.

Entonces, si su tarea de referencia es 2SP. Entonces hacer una estimación de 1/2/3/5 es relativamente fácil ya que las tareas son de tamaño similar. Una vez que pasa 3 veces más grande que la tarea de referencia (5SP), la estimación se vuelve más difícil (es 8/9 / 10SP lo que importa) Todo lo que puede decir es que es mayor que 5SP y menor que 13SP, entonces 8SP se ajusta a la factura.

Cualquier cosa con un valor de SP de 21/21 / Enorme es demasiado grande para el retraso del sprint. Estas son estimaciones para cosas en las que aún no está listo para trabajar (y, por lo tanto, no se han desglosado en tareas más pequeñas (no las divida hasta que las necesite)). Pero sí le dan una estimación del tamaño de una tarea en la cartera de pedidos del producto (lo que permite una planificación futura). En el momento en que llegue al punto en el que va a trabajar en ellos, debe tener el conocimiento suficiente para dividirlos en tareas más pequeñas para el retraso del sprint y volver a estimarlos individualmente (Nota: es un error común pensar que la suma de las partes son iguales al original).

• Cualquier cosa que calcule como Enorme debe dividirse en tareas más pequeñas.
• ¿Algo que se estima como? significa que no está lo suficientemente bien definido para estimar
  Debe agregar una tarea específicamente para ir y definir la tarea
  (es decir, escribir alguna documentación o presentación).

Los puntos de la historia son una medida relativa de lo difícil que es una tarea. Esto se debe a que los humanos en realidad son mejores en estimaciones relativas que mediciones precisas.

La forma en que usa los puntos de la historia es que toma alrededor de dos tareas en el proyecto y les asigna dos valores de puntos de la historia diferentes. Luego, estima las otras tareas utilizando esas dos aproximaciones de puntos de la historia como base para su estimación. Es decir, la tarea C no es mucho más difícil que la tarea A, pero es increíblemente más fácil que la tarea B, por lo que solo se trata de 2 puntos de historia más trabajo que la tarea A.

Cuando haya terminado de estimar todos los requisitos que tiene hasta ahora, luego calcule cuántos puede hacer en un sprint. En los próximos sprints, calcula cuántos ha completado. Los puntos de historia de un requisito solo se cuentan como completados si el requisito se cumple. No hay "80% completado" en Scrum. Esto se debe a que los humanos son realmente malos para estimar la integridad. Después de algunos sprints, debes tener una idea de cuántos puntos de historia puedes hacer por sprint.

¿Cómo lo estimas? Puedes usar el póker de planificación para determinar cuánto trabajo creen tus desarrolladores que un requisito tomará en relación con tus requisitos básicos.

También recomendaría leer The Agile Samurai . Hace un buen trabajo explicando estos y otros conceptos ágiles en mi opinión.

Aquí hay un enlace con más información sobre los puntos de la historia.

Aquí hay otro enlace.

Son una pérdida de tiempo.

http://www.amazon.com/Lean-Trenches-Managing-Large-Scale-Projects/dp/1934356859/

Es interesante que esta opinión ahora venga del tipo que escribió Scrum y XP de las Trincheras y cuyo nombre de compañía ( Crisp ) se puede encontrar en tantas barajas de cartas de planificación de póker utilizadas por tantos equipos en todo el mundo.

La última oración del OP: "¿Hay algún buen recurso para explicar los puntos de la historia?" Sí, este libro es un buen recurso. Comida para el pensamiento.

La explicación más fácil que se me ocurre es usar un objeto que sea tangible y que pueda proporcionar un ejemplo concreto.

Llévate una casa móvil. Si estuviera en el negocio de casas móviles, sabría que construir un solo ancho generalmente requiere 5 (puntos, ranas, widgets ... la forma de medición es arbitraria) y, por lo tanto, construir un doble ancho debería tomar aproximadamente el doble del esfuerzo o 10 (puntos , ranas, widgets).

En este punto, la mentalidad de los programadores comenzará y hablará sobre un enfoque simplificado; no toma el doble de tiempo debido a que la infraestructura consume la mayor parte del tiempo y otros ejemplos similares. Esto es inevitable Arpa en el hecho de que esta es una estimación en (puntos, ranas, widgets) ya que NUNCA podemos estimar con precisión en el tiempo y, por lo tanto, estimar en (puntos, ranas, widgets) elimina la creencia de que podemos.

Para saber cuánto tiempo llevará construir algo, haremos uso de nuestras tendencias a lo largo del tiempo; así, con el tiempo, cada vez más precisos en nuestras estimaciones.

No olvides planificar el póker cuando el equipo esté listo para comenzar.

Como otros han mencionado, los puntos de la historia son una medida relativa de complejidad para una historia de usuario. El verdadero beneficio de los puntos de la historia se realiza cuando

1. Los puntos son medidos por la unidad responsable de la implementación (ya sea un individuo o el equipo).
2. Las métricas se mantienen para cuántos puntos agregados completa la misma unidad dentro de una duración constante (velocidad).

Después de algunas iteraciones de medición en puntos de historia y velocidad de seguimiento, debería poder estimar con precisión cuántos puntos de historia pueden caber dentro de un bloque de tiempo dado (iteración o sprint si usa scrum). Tenga en cuenta que aplicar esta técnica a un grupo e intentar usar esas métricas para un equipo diferente no funcionará bien. Es decir, si el equipo a puede completar 120 puntos de historia en un sprint de dos semanas, esperar que el equipo b tenga los mismos resultados no es realista.

Como alguien más mencionó, la planificación del póker es una gran ayuda cuando se utiliza este método porque ayudará a identificar historias que necesitan un mayor refinamiento (si existe una discrepancia entre los votos, significa que hay incertidumbre en los requisitos).