{"id":16747,"date":"2020-09-22T13:31:47","date_gmt":"2020-09-22T13:31:47","guid":{"rendered":"https:\/\/staging-mondaycomblog.kinsta.cloud\/?post_type=monday_reviews&p=16747"},"modified":"2025-05-20T20:52:25","modified_gmt":"2025-05-20T20:52:25","slug":"puntos-de-historia-el-norte-de-los-equipos-agiles","status":"publish","type":"post","link":"https:\/\/monday.com\/blog\/es\/producto\/puntos-de-historia-el-norte-de-los-equipos-agiles\/","title":{"rendered":"Puntos de historia: el norte de los equipos \u00e1giles"},"content":{"rendered":"

P\u00eddele a un desarrollador de software que adivine cu\u00e1ntos dulces hay en un frasco y, probablemente, obtendr\u00e1s alg\u00fan tipo de razonamiento algor\u00edtmico y una respuesta frustrantemente precisa.<\/p>\n

El c\u00e1lculo aproximado sin razonamiento no es exactamente el punto fuerte de la mayor\u00eda de los desarrolladores.<\/p>\n

Por eso, estimar la cantidad de tiempo que llevar\u00e1 abordar los proyectos para poder planificar la semana siguiente suele ser el proyecto que m\u00e1s probabilidades tiene de abrumarnos.<\/p>\n

Es entonces cuando entran en juego los puntos de historia La respuesta cuantitativa para esta pregunta ambigua.<\/p>\n

Entonces, \u00bfcu\u00e1les son los puntos de historia de la metodolog\u00eda \u00e1gil?\u00a0<\/b><\/h3>\n

Mientras que la mayor\u00eda de los equipos estiman la dificultad de una tarea por tiempo (medio d\u00eda, una semana o un mes), los puntos de historia son un m\u00e9todo para medir el esfuerzo en una escala relativa. La asignaci\u00f3n de tareas en funci\u00f3n de la dificultad relativa permite una descripci\u00f3n m\u00e1s precisa del esfuerzo que se espera para la tarea porque, a diferencia de las estimaciones de tiempo, los puntos de historia se refieren solo a la tarea en cuesti\u00f3n, no a los correos electr\u00f3nicos, las reuniones o los retrasos inesperados que podr\u00edan afectar el tiempo que se tarda en completar la tarea.<\/p><\/blockquote>\n

Para hacer una estimaci\u00f3n precisa de los puntos de historia, debemos tener en cuenta los siguientes elementos:<\/p>\n

C\u00f3mo medir los puntos de historia: la sucesi\u00f3n de Fibonacci<\/b><\/h3>\n

Los desarrolladores usan una sucesi\u00f3n de Fibonacci: 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100, como una m\u00e9trica para medir los puntos de historia con el fin de obligar a los equipos a tomar decisiones claras<\/a>. Por ejemplo, si tienes que completar un proyecto y alguien te pregunta si te llevar\u00e1 3 o 4\u00a0horas, puedes dudar sobre c\u00f3mo responder porque la diferencia es tan peque\u00f1a que es dif\u00edcil de adivinar. En cambio, si alguien te preguntara si te llevar\u00e1 3 o 6\u00a0horas, probablemente tu respuesta ser\u00eda mucho m\u00e1s clara.<\/p>\n

Algunas preguntas a tener en cuenta para definir los puntos de historia:<\/b><\/h3>\n

1. \u00bfEste proyecto se parece a otro proyecto en el que ya hemos trabajado? De ser as\u00ed, \u00bfcu\u00e1l fue el esfuerzo para completarlo?<\/b><\/h3>\n

Como los puntos de historia son una forma <\/i>relativa de medici\u00f3n, el proceso cambiar\u00e1 y se perfeccionar\u00e1 continuamente, pero especialmente al principio, puede ser \u00fatil compararlo con proyectos anteriores similares para obtener perspectiva.<\/p>\n

2. \u00bfHay alg\u00fan posible obst\u00e1culo nuevo que pueda ocasionar un retraso?<\/b><\/p>\n

Es importante considerar toda la trayectoria entre equipos que el producto tendr\u00e1 que recorrer hasta que est\u00e9 completo.<\/p>\n

3. \u00bfTendremos que depender de un tercero para completarlo?<\/b><\/p>\n

Depender de otro equipo o de un contratista externo puede dar lugar a demoras m\u00e1s prolongadas y a m\u00e1s intercambios de ideas que se deben tener en cuenta.<\/p>\n

Qui\u00e9n deber\u00eda planificar los puntos de historia: Planning poker y sus jugadores<\/b><\/h3>\n

Planning poker es una actividad que ayuda a lograr r\u00e1pidamente y en equipo una estimaci\u00f3n precisa de los puntos de historia. En planning poker, cada miembro del equipo tiene una pila de cartas, cada una de ellas con un punto de historia diferente. Una persona lee en voz alta los diferentes proyectos que el equipo tiene por delante. Despu\u00e9s de repasar todos los detalles que conoce sobre el proyecto, cada miembro del equipo presenta la tarjeta que cree que representa el esfuerzo necesario para completar dicho proyecto.<\/p>\n

Este es un proceso r\u00e1pido, eficiente y transparente para que el equipo se re\u00fana en torno a la planificaci\u00f3n del sprint.<\/p>\n

Entonces, \u00bfa qui\u00e9n deber\u00edamos invitar a la mesa de p\u00f3quer? Es importante tener en cuenta el panorama completo cuando se estima el esfuerzo que supone completar una historia y acordar una definici\u00f3n de hecho (DoD). Invitar a todo el equipo y a los equipos adyacentes, como al de control de calidad y de pruebas de usuario, puede asegurarnos de que no pasemos por alto ninguna \u00e1rea problem\u00e1tica oculta.<\/p>\n

Errores comunes y lo que hay que evitar al estimar los puntos de historia<\/b><\/h3>\n

Hay algunos errores que t\u00fa y tu equipo pueden evitar f\u00e1cilmente cuando estiman los puntos de historia. Aseg\u00farate de estar atento a ellos y orienta a tu equipo en la direcci\u00f3n correcta si empiezan a desviarse del camino.<\/p>\n