Definición de un punto de historia [cerrado]

Que yo sepa, no hay una definición de Story Points y cómo compararlos. Cada persona en un equipo puede tener su propia comprensión de la correlación entre un esfuerzo y los Story Points. ¿No es la estimación de Story Points solo una falacia?

¿No es solo una creencia? Por ejemplo, se supone que todas las tareas tienen una propiedad específica: la dificultad, la cantidad de esfuerzo. Pero tal vez no lo hagan. E incluso si lo hacen, es solo una creencia de que podemos estimarlo adecuadamente como un número. La cantidad de tiempo que tomará una tarea es intrínsecamente indeterminada.

Por ejemplo: Durante Planning Poker, todos los miembros del equipo acuerdan que un PBI debe estimarse en 10 Story Points y pasan al siguiente PBI. Esta estimación de 10 Story Points en realidad no significa nada porque todos entienden 10 Story Points de manera diferente (diferente cantidad de esfuerzo, tiempo, riesgos).

Solo quiero argumentos confiables (una investigación, encuestas exhaustivas) de que SP es realmente una herramienta , y no solo una creencia .

La pregunta y los comentarios sobre las respuestas hacen que parezca que solo quieres discutir. Los puntos de la historia no tienen un vínculo fijo con el tiempo o el dinero. Los equipos consistentes que trabajan en el mismo contexto a menudo observan una fuerte correlación después de haber estado trabajando juntos durante un período de tiempo. La técnica fue diseñada de esta manera. Es solo una herramienta que puedes usar o no.
Pienso lo mismo @Daniel.
@Daniel No, solo quiero argumentos confiables de que SP es realmente una HERRAMIENTA, y no solo una CREENCIA.
¡Chris Brettini tienes argumentos! La cosa es que usted tiene la CREENCIA de que solo su CREENCIA es correcta y no puede proporcionar argumentos confiables para eso.
La solicitud de información es buena, aunque pensé que esto se había abordado antes en PM: SE. La distinción entre "herramienta" y "creencia" parece una falsa dicotomía y parece estar desplegada al servicio de un objetivo retórico.
Sí, también creo que lo que Chris Brettini quiere ya fue respondido aquí .
No estoy seguro de cómo se define una creencia. Lo que Taigo publicó puede ayudar. Además, en una de las conferencias magistrales de Mike Cohn, habla de que su organización ejecuta varios métodos de estimación entre sí y los puntos de la historia se destacaron como los más útiles. Cientos, si no miles, de equipos los utilizan con éxito todos los días. Son una herramienta a buen precio, independientemente de los estudios publicados. Sin embargo, desafían muchas suposiciones tradicionales sobre la estimación, por lo que no puede usarlos como si fuera horas.
Escuché argumentos similares de innumerables desarrolladores a los que simplemente no les gustaba hacer estimaciones. Llegarían a los puntos más complejos para justificar la idea de que cualquier tipo de estimación es defectuosa y, por lo tanto, inútil. Sin embargo, vincular SP a la religión es nuevo para mí. Felicitaciones por la creatividad.
No puedo pensar en una sola tarea que no tenga dificultad o esfuerzo. ¿Podría proporcionar algunos ejemplos?
Tal como está escrita, esta pregunta es demasiado abierta. Se han escrito libros enteros sobre el tema de la teoría del control empírico y las técnicas de estimación, por lo que esta pregunta es demasiado amplia. También invita al debate, que es una especie de formato de pregunta subjetivo que genera una lista y que se considera fuera de tema aquí. Hay una pregunta subyacente válida, pero sin una gran cantidad de modificaciones es probable que se cierre en breve porque no está en línea con la guía de preguntas de nuestro Centro de ayuda.
Con base en las idas y venidas extendidas en los comentarios, mantendré mi declaración anterior de que esta pregunta es demasiado amplia y demasiado abierta. Creo que hay una pregunta válida aquí, pero PMSE está diseñado para preguntas y respuestas canónicas, no para debates. Sin embargo, la comunidad puede volver a abrir esta pregunta a su discreción después de una edición juiciosa y una limpieza de comentarios.

Respuestas (5)

Los puntos de la historia son una medida relativa de esfuerzo en lugar de absoluta. Sin embargo, cada miembro del equipo debe tener la misma comprensión del tamaño de una estimación de puntos. Se logra un entendimiento común cuando el equipo estima repetidamente juntos y cuando acuerdan historias de referencia comunes contra las cuales medir. Esto realmente no es diferente a la estimación en horas o días donde las personas también miden las cosas contra las líneas de base recordadas. Planificar el póquer es una forma de asegurarse de que los equipos tengan un entendimiento común del tamaño de los artículos.

La estimación relativa con puntos de historia tiene algunas ventajas sobre la estimación absoluta. Parece que muchas personas obtienen estimaciones relativas más precisas que las absolutas. La velocidad, medida por los puntos de la historia completados por iteración, es una medida basada en evidencia, mientras que las estimaciones basadas en horas tienden a ser más subjetivas. Si mide las cosas en horas, aún puede medir retrospectivamente cuántas "horas" estimadas realmente completó, pero eso inevitablemente diferirá de las horas reales de trabajo realizadas, por lo que la realidad es que las "horas" tienden a convertirse en una medida relativa también.

¡Gracias! La ventaja de las horas es que todo el mundo las entiende. ¿Cómo sabemos que tenemos la comprensión compartida de los puntos de la historia? ¿Deberíamos incluir los riesgos en la estimación de SP? ¿Cómo estimar la complejidad en los SP?
Usted sabe que tiene una comprensión compartida de las estimaciones de puntos de la historia de la misma manera que sabe que tiene una comprensión compartida de las estimaciones de horas: acordándolas como grupo. Las técnicas de estimación de equipos como el póquer o el juego de Bockman aseguran que si alguien tiene una diferencia de opinión, esa diferencia es obvia para todos y el grupo tiene la oportunidad de llegar a un consenso.
Tu argumento tiene un defecto: ya asumes que todos tienen un entendimiento compartido. Suponiendo que este sea el caso, entonces describe el proceso de Planning Poker.
Planning Poker se trata de lograr una estimación compartida para un PBI, no de lograr una comprensión compartida de lo que significa 1 SP.
Viene a ser lo mismo. Si el equipo está de acuerdo en que la historia X equivale a 4 puntos, entonces "están de acuerdo" en que 1 punto es algo que es un cuarto de X. La unidad de medida no es tan importante. Lo que importa es que puedan ponerse de acuerdo sobre una cifra y luego usar esa cifra para medir la velocidad del equipo.
¿Cuál es su preocupación real? El equipo debe decidir cómo quiere medir las estimaciones. Si el equipo está más satisfecho definiendo las estimaciones como horas y no como puntos, está bien. Muchas personas encuentran que los puntos funcionan para ellos, pero no necesariamente para todos.
Me gustaría un enfoque de estimación confiable para planificar una fecha de finalización o fechas de lanzamientos y los Story Points simplemente no me brindan esta información.
@ChrisBrettini A menudo empiezo con 8 puntos = lo que se puede hacer en un día, pero no importa. Sus primeras iteraciones serán incorrectas, pero cada vez menos a medida que las personas ajusten sus estimaciones en función de los datos. Intenté hacer 40 puntos en la última iteración, obtuve 20, la capacidad de la próxima iteración es de 20. Sus iteraciones deben ser cortas, una o dos semanas, para una rápida retroalimentación y corrección. El seguimiento diario de la finalización de tareas con gráficos de trabajo pendiente le indicará rápidamente si va por buen camino o no. Esto no deja lugar para esconder malas estimaciones. La estimación a largo plazo es un tema avanzado.
@ChrisBrettini En resumen, los puntos de la historia y las prácticas asociadas se tratan de llegar a comprender su capacidad a corto plazo, desarrollar su capacidad para estimar con precisión el costo de las tareas y saber cuándo está descarrilado. Solo una vez que tenga eso abajo, cuando pueda alcanzar su marca regularmente para el trabajo de una iteración, puede comenzar a hacer estimaciones precisas a largo plazo. No puedes saltarte ese paso fundamental.

Seamos serios, a la gente normalmente no le importa cómo haces las estimaciones. Lo que les importa es cuánto se necesita y/o cuánto cuesta. Tiempo y dinero. Eso es lo que quieren. Las estimaciones son solo algo que lo ayuda a responder esas preguntas. No importa lo que use para las estimaciones, siempre que las personas puedan recuperar un valor de tiempo o dinero. Puede ser una estimación directa en horas o días hombre, o pueden ser puntos de historia, tallas de camisetas, cachorros o verduras. A nadie le importa. En serio ahora. Se trata de tiempo y dinero.

Por lo tanto, debe tener una forma de convertir una estimación en tiempo y dinero, ¿verdad?

Todo el mundo entiende qué hora es. Todo el mundo entiende lo que es el dinero. Y nos gusta pensar en ellos como absolutos. Una hora es una hora. Diez dólares son diez dólares. Pero no realmente. Significan diferentes cosas para diferentes personas. Si yo soy rico y tú eres pobre, diez dólares para mí pueden ser inútiles, pero para ti puede ser la diferencia en tener comida en la mesa o no. Si yo soy una persona ocupada y tú no, entonces una hora para mí significa mucho y la uso sabiamente, mientras que para ti podría significar pasarla en línea mirando videos de gatos en YouTube. Aunque los percibimos como absolutos, no lo son.

De las discusiones sobre las otras respuestas, veo que está preguntando por qué no estimar en horas directamente en lugar de puntos de la historia, ya que los puntos de la historia son abstractos y no absolutos. Todos entienden una hora, pero los puntos de la historia significan diferentes cosas para diferentes personas, ¿verdad? Pero por lo que dije anteriormente, ves que los puntos de la historia no son tan diferentes a las horas. Significan diferentes cosas para diferentes personas. Una hora de desarrollo para un desarrollador senior no significa lo mismo que una hora de desarrollo para un desarrollador junior. El senior puede construir una función completa en una hora, el junior podría usar esa hora para descubrir cómo abordar exactamente la función. Si el desarrollador sénior estima que una función tardará una hora, esa estimación es subjetiva. Depende mucho de las habilidades. El senior construirá la característica F en una hora, pero el junior puede tardar cuatro horas en construir la misma función. Entonces, ¿de qué sirve una estimación de una hora para la característica F si tendrá que ser el junior quien debe trabajar en ella? (si el desarrollador senior no está disponible, por ejemplo).

Estimar en horas es una forma de mentirte a ti mismo y darte una falsa confianza. Usted entiende las horas, por lo que cuando estima un proyecto y obtiene 1078,65 horas, entonces tiene información absoluta, ¿verdad? Sabes a lo que te enfrentas. Pero no lo haces. El desarrollo de software no funciona así. Es por eso que ya no hacemos Waterfall por todas partes, sino que tratamos de ser más ágiles. Hay mucha complejidad en la construcción de software, hay mucho esfuerzo que se dedica a construir lo correcto y muchos riesgos. Las estimaciones de horas no reflejan esto y pensar que las horas son absolutas es simplemente una ilusión. La historia nos ha demostrado eso. La gente apesta estimando, y apesta adjuntando horas a esas estimaciones. Pero parece que podemos estimar mejor las cosas entre sí. Si tienes dos características,

Los puntos de historia son una forma de resaltar la diferencia de tamaño entre las características. Una función de 5 SP es más que una función de 3 SP y menos que una función de 8 SP. Es posible que las personas no estén de acuerdo en que una hora o diez dólares son lo mismo para todos porque muchas cosas subjetivas influyen en eso, pero pueden estar de acuerdo en que una característica es más compleja que otra. Una historia de 5 SP es una historia de 5 SP tanto para el desarrollador senior como para el desarrollador junior. Puede que al senior le lleve una hora y al junior cuatro horas construirlo, pero eso no cambia el hecho de que, en relación con las cosas en las que ambos trabajaron hasta ahora, este es un 5.

Inicialmente, las personas tienen diferentes entendimientos sobre lo que es un 5. El senior podría pensar que 5 es fácil, el junior podría pensar que 5 es difícil. Entonces, al estimar, obtendrá diferentes valores para la misma característica. Pero hay una discusión. Las personas diseccionan la función y explican por qué creen que es un 5 o un 1 o un 13 o lo que sea. Con el tiempo, descubren, en relación con las otras características, qué es un 5, un 1 y un 13. No importa cómo alcanzaron subjetivamente ese número, relativamente hablando, aprenden a unir los mismos números a características de tamaño similar. Una vez que esto suceda, la gente sabrá cuánto tirar en el sprint y la velocidad comenzará a ser relevante. Luego, puede agregar horas a los puntos de la historia por equipo, ya que sabe cuánto pueden entregar por sprint. Pero recuerda que todavía no será un absoluto. no hay ta coincidencia por qué usas Fibonacci para estimar. Cuanto más altos sean los SP, mayor será la incógnita. De hecho, ni siquiera es Fibonacci. Una secuencia de Fibonacci es 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, pero la mayoría de las cartas de póquer de planificación son 1, 2, 3, 5, 8, 13, 20, 40, 100. Las cosas se ponen redondeado de. El número 89 es absoluto, 100 es una aproximación. ¿Realmente importa si es un 89 o un 90 o un 95? No hace ninguna diferencia. Es mucho. Así que solo di 100 y llámalo un día. ¿Es un 89 o un 90 o un 95? No hace ninguna diferencia. Es mucho. Así que solo di 100 y llámalo un día. ¿Es un 89 o un 90 o un 95? No hace ninguna diferencia. Es mucho. Así que solo di 100 y llámalo un día.

Basta de divagaciones... para volver a tu pregunta. La definición de un SP es que es una medida abstracta de la dificultad de una función y el esfuerzo necesario para construirla. Con el tiempo, las personas del equipo descubren qué significan los PF para ellos (por eso, por ejemplo, no puedes comparar los puntos de la historia de un equipo con los puntos de la historia de otro; 10 PF en un equipo pueden significar 40 PF en otro).

Vea también si esto proporciona información adicional: ¿ Por qué usar puntos de historia en lugar de horas para estimar?

¡Muchas gracias por una respuesta detallada! Pero sigue siendo solo una creencia. Por ejemplo, se supone que existe una dificultad de una tarea/característica. ¿Cómo sabes que tal cosa existe en absoluto? Está seguro de que todas las tareas tienen una propiedad específica: la dificultad. Pero tal vez no lo hagan. E incluso si lo hacen, es solo una creencia de que podemos estimarlo adecuadamente como un número.
Todas las características tienen dificultad y esfuerzo necesario para construirlas. Eso no es una creencia. Así es como es. Las cosas pueden ser fáciles de hacer o difíciles de hacer. Las cosas pueden tomar una pequeña o una gran cantidad de tiempo para hacerse. Y todas las cosas conllevan riesgos. Cuando estima, tiene en cuenta todos estos factores, sin importar si estima en horas o en SP. No entendí muy bien tu comentario, pero el punto con los SP no es estimar adecuadamente la dificultad como un número. Debe considerar los SP como cajas en las que puede poner sus funciones. Cajas más pequeñas, cajas más grandes, etc. Todas las estimaciones son...
... lo más probable es que esté mal. Cuando usa los SP para estimar, el equipo discute el trabajo lo suficiente como para descubrir, comprender y acordar en qué cuadro debe ir una característica. Como muchas cosas en Agile, la estimación de SP es una estimación "suficiente" para comprender el esfuerzo necesario (es decir, un esfuerzo similar al de otras características similares del pasado). Una función de 5 SP no significa que el 5 sea exacto, solo identifica el cuadro con 5 escrito en él. Más tarde, puede calcular el tiempo para los SP en función de cuántos SP entregue el equipo por sprint. Estimar directamente en horas te da falsos absolutos...
... que lo engañan haciéndole creer que obtiene información útil palpable de la estimación, pero en realidad no es así. Si estima algo como 10 horas y en realidad toma 11 horas para hacerlo, entonces está atrasado en su trabajo. Si una característica de 5 SP toma 10 u 11 horas, entonces eso es lo que tomó. No has llegado tarde. Así es como 5 SP se tradujeron en horas. Después de algunos sprints, algunas rondas de estimaciones de SP, algunos valores de velocidad, puedes hacerte una idea de cuánto tardan las cosas. Pero nada es absoluto cuando se trata de estimaciones. Los SP expresan mejor ese hecho de lo que podrían hacerlo las horas.
¿Cuál es el uso de los SP? ¿Se utilizan para un Sprint Planning o para planificar una gran cantidad de trabajo (por ejemplo, Epics)?
El equipo usa SP para calcular cuánto trabajo pueden realizar en el sprint. Una vez que tenga la velocidad del equipo para una cantidad de sprints, puede extrapolar cuánto otro trabajo tomará, como épicas o incluso todo el backlog. Si, por ejemplo, fue y estimó todo su backlog en 1000 SP, y la velocidad del equipo es en promedio de 100 SP, entonces puede asumir que puede terminar todos los PBI en al menos 10 sprints (digo al menos, y no exactamente 10, porque cuanto más mire hacia el futuro, mayor será la incertidumbre y el riesgo involucrado)
Bueno, ¿cómo estimas toda la epopeya? Puede estimar rápidamente algo pequeño, observable, algo que sabe cómo hacer. Epic es bastante grande, estimar un Epic te da un gran error de estimación. En lugar de 10 sprints, puede tomar 30 sprints. ¿Cuál es el uso de esta estimación? Pregunto esto porque todavía no estoy seguro de cómo los SP pueden ser útiles.
Fundamentalmente, una epopeya es una historia de usuario muy grande que contiene otras historias de usuarios. No puedes trabajar en una epopeya directamente, porque no está debidamente detallada. Tienes que dividirlo en historias de usuario más pequeñas. Ese es el propósito de la reunión de refinamiento, por ejemplo. El equipo analiza la epopeya, crea historias de usuarios con los detalles apropiados y estima cada historia. Los SP épicos son entonces la suma de todos los SP de las historias de usuario. Con cualquier tipo de estimación, incluidos los SP, si desea obtener mejores resultados, debe dividir las cosas en partes más pequeñas; de lo contrario, tendrá un error de estimación mayor.
Bien, solo usamos SP para la planificación a corto plazo, cuando tenemos el trabajo descompuesto en partes pequeñas. No usamos SP ni póquer de planificación rápida para estimar la fecha de finalización de un proyecto. Me parece que usar SP es solo una cuestión de gusto.
@DJClayworth: Mala elección de palabras. Lo que quise decir es que a la gente no le importa cómo haces las estimaciones. Gracias por traerlo a mi atención. La gente suele esperar un valor de tiempo de todas las estimaciones. Incluso tu comentario refuerza lo que estoy diciendo. Dices "lanzamiento del próximo mes" y "listo a tiempo". Pero incluso la redacción inicial es cierta. Si los desarrolladores se acercan a usted con una estimación de esfuerzo de 13 puntos de historia, ¿le importa o prefiere una duración? Cuando tiene una duración, ¿su tendencia es intentar reducirla si no le gusta cuánto tarda algo? Además de todas las cosas que...
... se dijo en esta publicación, una ventaja de estimar en SP es que la alta gerencia tiene menos espacio para jugar con las estimaciones. Si los desarrolladores dicen 10 días, algunos podrían sentirse tentados a tratar de presionar a los desarrolladores para que den un valor menor ("¿No pueden hacerlo en 8 días? Es realmente importante, es necesario para tal y tal, bla, bla, bla"). Si algo tiene 5 SP, no puedes decir "¿Puedes convertirlo en 3 SP?" porque no se puede disminuir la dificultad real de algo de la misma manera que se puede disminuir el tiempo que se trabaja en ello.
¡Respuesta larga pero realmente vale la pena leerla!

Cada persona en un equipo puede tener su propia comprensión de la correlación entre un esfuerzo y los Story Points.

Inicialmente, en un equipo nuevo, eso puede ser cierto. Es por eso que una estimación basada en Story Points es más que cada miembro del equipo simplemente dando un número y luego tomando la estimación final más baja/más alta/promedio/lo que sea.

Al hacer una estimación de Story Point, eso también debe incluir una discusión en la que los miembros del equipo puedan explicar lo que consideraron al llegar a su valor de puntos. Es importante que al menos las personas con las estimaciones más altas y más bajas escuchen, porque es probable que tengan ideas específicas sobre el tema en cuestión. Esto también puede incluir información sobre los riesgos y/o incertidumbres asociados con el elemento de trabajo en cuestión.

A través de estas discusiones, los miembros del equipo también obtendrán una comprensión más común de la combinación de esfuerzo, complejidad y riesgo que implica un Story Point.

Para subrayar que la estimación no es una ciencia exacta y para evitar debates interminables sobre si un elemento de trabajo debe tener 40 o 41 puntos, las técnicas de estimación como el póquer de planificación (que se usan comúnmente para estimar los puntos de la historia) tienen una granularidad de estimaciones que se pueden dar que aumenta con el tamaño de las propias estimaciones.

¿Cómo llegan a un entendimiento común de los riesgos? La estimación de riesgos depende de la experiencia personal. ¿Por qué deberíamos molestarnos con estos SP ofuscados en lugar de solo usar horas?
@ChrisBrettini, ¿cómo adquiere experiencia en la estimación (reconocimiento final) de riesgos? Espero que no exclusivamente de golpearte la nariz, sino también de otros que puedan señalarlos antes de que tú te golpees la nariz. Y ahí es donde entran en juego las discusiones, porque ahí es donde alguien puede señalar el riesgo a los otros miembros del equipo.
@ChrisBrettini El equipo llega a un entendimiento común por experiencia. Cuanto más tiempo exista un equipo como equipo, más tenderán a sincronizarse sus propias ideas personales sobre el valor de un punto de la historia. Cuando cambia los miembros de un equipo, habrá un período de ajuste en el que sus estimaciones individuales difieren más ampliamente, y tienen que discutir y acordar qué número usar. Con el tiempo, comenzarán a sugerir los mismos números, requerirán menos discusión y su velocidad de puntos por sprint será más consistente. He visto que esto me ha pasado en varias empresas. Funciona.

Mike Cohn tiene un excelente artículo sobre Story Points . Algunos de los aspectos más destacados son

Los puntos de historia son una unidad de medida para expresar una estimación del esfuerzo general que se requerirá para implementar completamente un elemento de la cartera de productos o cualquier otro trabajo.

...

Debido a que los puntos de la historia representan el esfuerzo por desarrollar una historia, la estimación de un equipo debe incluir todo lo que pueda afectar el esfuerzo. Eso podría incluir:

  • La cantidad de trabajo a realizar
  • La complejidad del trabajo.
  • Cualquier riesgo o incertidumbre al hacer el trabajo.

...

Una estimación puntual de la historia debe incluir todo lo relacionado con la realización completa de un elemento de la cartera de productos. Si la definición de hecho de un equipo incluye la creación de pruebas automatizadas para validar la historia (y eso sería una buena idea), el esfuerzo para crear esas pruebas debe incluirse en la estimación de puntos de la historia.

Los puntos de la historia pueden ser un concepto difícil de entender. Pero valdrá la pena el esfuerzo de comprender completamente que los puntos representan el esfuerzo impactado por la cantidad de trabajo, la complejidad del trabajo y cualquier riesgo o incertidumbre en el trabajo.

Sí, pero no da reglas sobre cómo convertir cada pronóstico personal de la cantidad de trabajo, de la complejidad, de los riesgos en una estimación de un número. Entonces, como dije, todos entienden los Stoty Points de manera diferente. ¿De qué sirven entonces...?
Los defines como un equipo. Quiero decir, llegas al SP final para una historia de usuario como equipo. Entonces, llegas a un acuerdo porque si uno selecciona un SP bastante bajo o un SP alto, entonces comienza una discusión para comprender qué llevó a esa decisión. Cada vez que usé SP hubo solo una o dos veces que el equipo no llegó a un acuerdo completo después de la discusión. ¿Tiene sentido?
No precisamente. Acordar SP se trata de nombrar cosas: uno puede etiquetar una historia con "10 puntos de historia", el otro puede etiquetarla con "5 puntos de historia". Pero estas son solo etiquetas: dos personas diferentes pueden dar etiquetas diferentes a la misma cosa. Y es difícil lograr una comprensión compartida de lo que llamamos 1SP, 2SP, etc.
Son etiquetas que, como explica Mike Cohn, se traducen en esfuerzo por desarrollar un EE.UU. particular. Tienes una meta y, de acuerdo a tu experiencia, esta es de 4 SP. El otro miembro de tu equipo se da cuenta de algo que tú no sabías que se suma a la incertidumbre y decide 12 SP. Luego, discutirás para defender por qué. Te das cuenta de que no estabas considerando esa parte que es incierta y te das cuenta de que tal vez 4 no es muy bueno. Así que decides dar 8 o 12 o incluso más.
El Scrum Master a menudo establece un límite. No es como "Hola a todos, seleccionen un número del 1 al 100". SM puede decir algo como "2-4-8-16-32-64"
Dentro de ese rango, si selecciona 32 SP para un EE. UU. muy, muy fácil (lo que significa que es bastante complejo, incierto o requiere mucho trabajo), entonces estoy seguro de que los otros miembros de su equipo no estarán de acuerdo con dar 32 SP a ese EE.UU.
Pero sin las reglas comunes, estos números se eligen y acuerdan de manera poco confiable. ¿Cómo puedes discutir y acordar algo para lo que no tienes una definición?
Seguro que puedes obtener alguna estimación usando Plannning Poker, pero la pregunta es ¿cuál es la precisión de estas estimaciones? Si la precisión es solo del 30%, estas estimaciones son bastante inútiles. ¿Y cómo sabes la precisión?
Para mí, esto es una definición "Los puntos de la historia son una unidad de medida para expresar una estimación del esfuerzo general que se requerirá para implementar completamente un elemento de la cartera de productos o cualquier otro trabajo".
Pero las horas también son "una unidad de medida para expresar una estimación del esfuerzo general que se requerirá para implementar completamente un elemento de la cartera de productos o cualquier otro trabajo". ¿Por qué no usar horas?
Hay muchos factores que influyen en la precisión. Habilidades de sus desarrolladores es uno.
Sí. Entonces, al final del día, ¿cómo sabemos que los SP son más útiles que las horas? Las horas al menos tienen la propiedad de ser entendidas por todos los miembros del equipo de la misma manera.
Puedes usar horas si quieres. Pero la cantidad de tiempo que toma para lograr algo no expresa el esfuerzo. Se aplica la misma lógica si se le paga por la cantidad de horas, entonces la forma en que realiza actividades/tareas es diferente a cuando se le paga por actividad/tarea.
Esta es la verdadera razón? ¿Para evitar la presión del tiempo y permitir que los desarrolladores se concentren en la calidad en lugar de cumplir con la fecha de finalización?
Tarea muy simple y repetitiva - 3 horas. Tarea difícil - 1 hora.
El equipo de desarrollo trabaja dentro de los límites del sprint. Quieren entregar los EE. UU. que prometieron al comienzo del sprint. Está más orientado a la actividad/tarea.
¿Por qué no hacer que la tarea difícil dure 5 horas?
Si realmente quieren entregar lo que prometieron, deben esforzarse por estimar con precisión en horas para pronosticar lo que podría seleccionarse para el Sprint: no está orientado a tareas, está orientado a horas. No estoy seguro de qué quiere decir con dura última 5h - diferentes tareas duran diferente tiempo
Tomar más tiempo no significa que sea más difícil.
Pero, ¿qué necesitamos saber cuando estamos haciendo un proyecto? Necesitamos saber la cantidad de tiempo, ¿verdad? No el nivel de dureza. Al cliente no le interesa si es difícil o no, quiere saber la cantidad de tiempo.
Los SP son más útiles a largo plazo. Sabrás "mi equipo es capaz de manejar X durante un sprint".
Y sabrás qué significa X en la vida real porque tendrás métricas.
Pero, ¿por qué necesitamos conocer esta X? ¿Cómo usamos esta X? ¿Qué métricas?
Varias razones. El equipo de desarrollo puede comprender su rendimiento promedio, cómo, cuándo fue el mejor y el peor momento, cómo pueden mejorar. Sepa si y por qué necesita más personas.
Primero debemos demostrar que existe una fuerte correlación entre SP y el rendimiento. Tal vez solo queremos creer en SP.
¿Tienes uno por horas también?
Cuando hablamos de horas es más fácil entendernos, la conversación se vuelve más concreta, podemos detallar más la estimación y obtener una cantidad de tiempo más confiable. La fecha de lanzamiento se vuelve más confiable. Esta es la propiedad de Applealing de hous para mí.
Dan Radigan - «Las horas no tienen en cuenta el trabajo no relacionado con proyectos que inevitablemente se cuela en nuestros días (correos electrónicos, etc.). Las horas tienen un apego emocional. Cada equipo estimará el trabajo en una escala ligeramente diferente, lo que significa que su velocidad (medida en puntos) será naturalmente diferente. Esto, a su vez, hace que sea imposible jugar a la política usando la velocidad como arma. Los puntos de historia recompensan a los miembros del equipo por resolver problemas en función de la dificultad, no del tiempo invertido (esto mantiene a los miembros del equipo enfocados en el valor de envío, no en el tiempo invertido).»
@ChrisBrettini Los puntos de la historia son más precisos porque los humanos son notoriamente malos para estimar el tiempo. Es difícil estimar una cantidad de horas para permitir que "todavía haya cierta incertidumbre sobre cómo se implementará esto". Es fácil comparar una tarea con algo que hizo antes y decidir si es más grande, más pequeña o similar. Los puntos deliberadamente no son los mismos en todos los equipos, lo que significa que no puede decirle al Equipo A "aquí, el Equipo B dice que son cuatro días de trabajo, por lo que le llevará cuatro días, ¿verdad?" El equipo A tiene que estimarlo por sí mismo, lo que mitiga el problema del "mes-hombre mítico".
Además, "al cliente no le interesa si es difícil o no; quiere saber la cantidad de tiempo", esto es cierto, pero el cliente no debe ver los puntos de la historia. Los puntos de historia no significan nada para nadie fuera del equipo que estimó las historias. Los puntos se pueden usar para decidir cuánto trabajo cabe en un sprint y, en ese punto, si es difícil o no es muy importante. Los puntos de historia se pueden usar para estimar cuántos sprints de trabajo hay en su cartera de pedidos, lo que se puede usar para darle a su cliente la fecha de entrega estimada que desea. (Tenga en cuenta que esto cambiará a medida que pase el tiempo).
@anaximander usar puntos de la historia para estimar cuánto tiempo llevará el trabajo pendiente es problemático y me mantendría alejado de eso. Los puntos de la historia no tienen relación con el tiempo a propósito. Simplemente se usan en el 'ahora' para comparar qué tan grande es algo con otra cosa. Tratar de extrapolar el tiempo y las estimaciones a partir de ellos es una receta para el desastre.
@GeorgeStocker Estoy totalmente de acuerdo, y he visto que causa todo tipo de problemas (un lugar en el que trabajé incluso "calculó" que un punto de la historia valía 2,5 horas y basó todo en eso, lo que realmente no funcionó). Lo que quiero decir es que puedes usar los puntos de la historia y la velocidad para decidir cuánto trabajo cabe en tu sprint (lo cual es normal), y esto se puede extrapolar para estimar de forma aproximada cuántos sprints de trabajo hay en la cartera de pedidos, pero cuando decir que cambiará, quiero decir que realmente, este tipo de estimación solo es precisa para uno, tal vez dos sprints en el futuro.

Sin dispositivos de medición externos, puedo comparar dos tazas de agua y adivinar cuál está más llena que la otra.

No puedo decirte cuánto líquido exacto puedo meter en la taza, ni puedo decirte si poner el líquido de una taza en la otra resultará en un desbordamiento sin intentarlo. Si ambos están realmente llenos, es posible que tenga alguna capacidad para hacerlo; pero depende de los tamaños relativos de las tazas y de la cantidad de agua que parece haber en cada una.

Mi punto es: mientras puedo hacer inferencias y deducciones tratando de comparar las dos tazas entre sí; No puedo decirte mucho más, porque no se puede conocer sin una medición más precisa y un proceso científico.

El desarrollo de software es cualquier cosa menos un proceso científico: es lo más alejado posible de la ciencia. Supongo que por eso lo llamamos "Desarrollo de software" y no "Ciencia del software".

Los puntos de historia se utilizan para medir el trabajo contra el trabajo realizado en el mismo sprint; y sus valores son relativos al trabajo que se está realizando. Al igual que el agua en la taza, no tienen ninguna medida ni relevancia para el trabajo realizado en el pasado o el trabajo que aún queda por hacer; eso requiere medidas que no tenemos porque no somos realmente capaces de medir los cambios en el medio ambiente. que hacen que el software se construya o no.

Por ejemplo, cualquiera de los siguientes puede afectar la velocidad:

  • Nuevo miembro del equipo
  • El error contiene una dependencia que no conocíamos
  • Un miembro del equipo tiene un problema con otro miembro del equipo
  • una actualización del entorno de desarrollo de software provoca efectos secundarios imprevistos
  • NPM cae
  • Después de comenzar el desarrollo, un desarrollador nota que el problema es más profundo de lo que sabíamos
  • Un desarrollador se confunde con el código 'inteligente' de otro desarrollador
  • Cualquiera de los elementos enumerados aquí .

Mi punto es que cualquier técnica de estimación que intente hacer otra cosa que no sea dimensionar el trabajo inmediatamente frente a usted con el trabajo que también está inmediatamente frente a usted está sujeta a una decepción extrema.

Hay dos formas de evitar esto:

  1. Desglose el trabajo tan pequeño que sea fácilmente estimable de forma fiable.
  2. Trabaje en una cosa a la vez, con todo el equipo trabajando en ello, para asegurarse de que no haya puntos ciegos o pistas que puedan colisionar ( Programación Mob ).

La mayoría de los equipos que he visto que han tenido problemas con Story Points han tratado de usarlos como una especie de estimación de cuánto trabajo se puede hacer en un sprint de manera confiable en un entorno dinámico; o comparar la velocidad en el tiempo, o pensar en ellos como una medida confiable de estimación absoluta.

La analogía de las dos tazas de agua explica claramente de dónde proviene el valor de un punto. Dadas dos tazas diferentes, podría observar que sus tamaños tienen una proporción aproximada de 3:5 (por ejemplo), pero eso no significa que la taza más pequeña contenga 3 litros, o tres pintas, o tres de cualquier unidad en particular, se trata de las tres quintas partes del mayor. También explica el uso de los números de Fibonacci: dado un vaso muy grande, es probable que no puedas ver la diferencia entre 25:3 y 26:3 con mucha precisión, pero probablemente puedas decidir si está más cerca de 21 o de 34.
Definición de un punto de historia [cerrado]
RespuestasAquíPolítica de privacidad1y, 0v