Sabemos que los puntos de la historia son una estimación de la complejidad, mientras que las horas son una estimación del esfuerzo, pero ¿se pueden usar los puntos de la historia y las horas de manera intercambiable en cualquier escenario al estimar las historias de los usuarios o es una mala práctica elegir horas sobre los puntos de la historia al usar Scrum?

Answer 1

El punto principal del uso de los puntos de la historia es que son una abstracción y, como tales, no se traducen directamente en las horas dedicadas o planificadas para trabajar en un proyecto. Hay muchas razones para esto, pero finalmente se reduce a dos hechos:

1. Las personas son terribles al estimar el trabajo; y
2. Cuando calcula en horas, la gente lo mantendrá en esas horas.

La estimación basada en horas da un sentido muy falso de especificidad y confiabilidad, algo que es imposible cuando solo estás viendo una historia de usuario durante unos minutos y decides si clasificarla como una historia “pequeña” o una historia “grande”. Las estimaciones por hora son el trabajo mítico de Waterfall, donde conoce todos los rincones de los requisitos con anticipación, y nada cambia desde el momento en que se define hasta el momento en que se ejecuta.

Los puntos de la historia también son un “escudo” que separa al equipo de las intrusiones de los trituradores de dinero y los lapiceros que siempre quieren estimaciones por hora, a pesar de que no entienden que son altamente inexactos y poco confiables. Cuando los vendes en puntos de historia, dejan de molestarte por estimaciones por hora, y por informes de variación, y por toda esa mierda burocrática que nunca es confiable, nunca es correcta y nunca es lo suficientemente buena.

Nunca use estimaciones por hora para proyectos ágiles. NUNCA.

Answer 2

La estimación de proyectos de desarrollo de aplicaciones con la técnica de horas hombre es fácil de entender, pero tiene pocas desventajas.

Muchas tareas son difíciles de estimar correctamente, porque se basan en el nivel de experiencia del desarrollador. Si un desarrollador estima un proyecto pero otro completa la tarea, la estimación deja de ser válida. Además, las personas a menudo subestiman los inconvenientes que podrían enfrentar y consideran solo la alternativa óptima.

En RubyGarage estimamos proyectos de desarrollo de aplicaciones usando Story Points. Esa técnica de medición ofrece beneficios a los desarrolladores y clientes. No depende de quién está implementando la historia, y todos los miembros del equipo, con diferentes habilidades, pueden discutir la estimación juntos. Todo el equipo puede entender claramente el tamaño y la complejidad de la historia.

Además, la velocidad es un poderoso método de planificación de capacidad y el equipo puede aumentarlo con la ayuda de Story Points y no necesitará volver a estimar su proyecto si la velocidad cambia.

Los puntos de historia han adquirido una reputación; son estables e independientes de la habilidad o experiencia de los miembros del equipo; te permite seguir la velocidad de un equipo; y ayudarlo a mantenerse flexible en la planificación de las fechas de lanzamiento del proyecto.

Para obtener más información sobre Story Points, puede leer el artículo 3 Razones para estimar con Story Points en el blog RubyGarage.

Answer 3

No, no se pueden usar indistintamente. Estimar sus historias de usuario en horas tiene ramificaciones e impacta negativamente su velocidad. Aquí hay un par de problemas que vienen a la mente, solo para simplificar las cosas:

1. Lo que puede tardar 2 horas en completarse puede llevar a otro desarrollador 2 días, dependiendo del nivel de experiencia.
2. Cuanto más alto estimes en horas, más impreciso / impreciso obtendrás. ¿Cuántas veces hemos estimado que algo demorará 12 horas para que tarde más de 30 horas reales? ¿Por qué? Cuanto mayor sea su estimación, aumentará el número de incertidumbres.

Apégate a los puntos. Aprendelo bien. No trate de igualar puntos con el tiempo como lo hacen a menudo los primeros usuarios de Scrum. He estado en equipos que intentaron pensar en las siguientes líneas:

• 0 puntos = 5 minutos
• 1/2 punto = 30 minutos
• 1 punto = 2 horas
• 3 puntos = 1/2 al día
• 8 puntos = 1 día

Y así sucesivamente. Esto está mal. Si necesita estimar algo a tiempo, puede hacerlo durante la planificación de sprint para historias que podrían dividirse en subtareas. Si no, manténgase enfocado en usar puntos.

Answer 4

No es una mala práctica per se usar horas o cualquier otra unidad basada en el tiempo para su estimación, aunque no se recomienda. Es una mala práctica mezclar tales unidades con SP debido a la filosofía diferente detrás de esas unidades.

Las unidades basadas en el tiempo son un intento de estimar directamente el tiempo que llevaría completar un requisito, los SP son el primer paso para derivar esa información más adelante de los datos empíricos (velocidad), aparte de sus otras ventajas, por ejemplo, es más fácil estimar como un grupo que usa SP en lugar de unidades basadas en el tiempo, etc.

Answer 5

Tal como lo veo, los puntos de la historia son más simples para abordar el concepto base de estimación. El punto de no. De historia que el equipo podrá entregar con el tiempo. Cuando vayas con horas, el mismo equipo tomará menos tiempo para una implementación similar en la que trabajó antes. Por lo tanto, no es apropiado para la estimación. Entonces es mejor usar puntos de historia. Utilice también la numeración basada en la serie Fibonacci. Me gusta el enfoque de marcarlos como SS SML XL y XXL, cada uno con el valor del número de Fibonacci. Esto permite que el equipo no piense en términos de complejidad sino en términos de números … Espero que les sea útil. Buena suerte con la implementación de scrum.