He escuchado muchas explicaciones diferentes de lo que la Historia Puntos significan y cómo se deben utilizar los mismos. Casi todos los equipos de Scrum los usan, pero no forman parte de la Guía Oficial de Scrum. Este artículo tiene como objetivo eliminar algunos de los puntos de misterio que rodean la historia., También compartiré los conceptos erróneos más comunes que he encontrado.

¿Qué Historia Puntos representan?

Los puntos de Historia representan el esfuerzo necesario para poner en marcha un PBI (Product Backlog Item). Cada punto de la historia representa una distribución normal del tiempo. Por ejemplo,1 punto de historia podría representar un rango de 4-12 horas, 2 Puntos de Historia 10-20 horas, y así sucesivamente., Esta distribución de tiempo es desconocida durante la estimación. Al utilizar la referencia PBI relativa a la cual estimar, no es necesario saber cuánto tiempo lleva. Solo desea tener una indicación aproximada de cuánto tiempo tardará el PBI en completarse.

¿cuáles son los beneficios de usar puntos de Historia?

Los puntos de Historia permiten a un equipo:

• estimar rápidamente los problemas. La estimación es relativa a los elementos de Backlog de productos ya completados. Esto es más rápido que estimar sin ninguna referencia.
• estimar sin dar un compromiso de tiempo específico., Al estimar en horas, usted hace un compromiso de tiempo preciso. Estimar los puntos de la historia impide dar un compromiso exacto. Nadie sabe exactamente cuántas horas está asignando a un tema específico.
• Abrazar la incertidumbre que viene con la estimación. Los puntos de historia especifican un intervalo de tiempo desconocido. Seleccionar de una secuencia específica de Fibonacci-como de los puntos de la historia nos permite capturar la incertidumbre.
• lo suficientemente preciso como para planificar Sprints con antelación. Esto nos permite gestionar mejor las expectativas de tiempo de las partes interesadas para el trabajo futuro.,

12 errores comunes cometidos al usar puntos de Historia

1. equiparar los puntos de historia con solo complejidad, incertidumbre o valor

algunos PBI pueden ser complejos y no requieren mucho tiempo. Un PBI implica la implementación de un algoritmo sofisticado. El equipo ya ha hecho esto antes, por lo que podrán hacerlo rápidamente. Lo contrario también puede ser cierto, un PBI simple que toma mucho tiempo. El equipo necesita refactorizar una pequeña pieza de código, lo que afecta a una gran cantidad de funcionalidad. Como resultado, una gran cantidad de funcionalidad necesita regresión probado, que tomará mucho tiempo.,

la incertidumbre en la estimación se captura en la secuencia de Fibonacci en sí misma: 1, 2, 3, 5, 8, 13, 20, 40, 100. La elección de un número específico de esta secuencia refleja la cantidad de incertidumbre. Por supuesto, si la incertidumbre es demasiado grande para estimar, puede utilizar el’?’ tarjeta.

Los puntos de historia no dicen nada sobre el valor de un PBI. Los puntos de la historia proporcionan una estimación aproximada. Podría ser que este artículo es extremadamente valioso, o no agrega ningún valor en absoluto. Los puntos de historia ayudan a determinar el ROI de un PBI., Puede utilizar los puntos de la historia para tener en cuenta el esfuerzo para ofrecer esa funcionalidad junto con el valor. Pero como el valor también es incierto, no te consideres Rico todavía.

Los puntos de la historia son sobre el esfuerzo. La complejidad, la incertidumbre y el riesgo son factores que influyen en el esfuerzo, pero cada uno por sí solo no es suficiente para determinar el esfuerzo.

2. Traducir los puntos de la historia a horas

al traducir los puntos de la historia a horas, deja de beneficiarse de la velocidad de la estimación relativa. Empiezas a trabajar en horas y te arriesgas a comprometerte., Proporciona una falsa sensación de precisión al reducir un punto de la historia con un rango de tiempo de 10-20 horas a un número preciso como 15 horas. Será más difícil llegar a un acuerdo en las estimaciones cuando se trabaja en el Reino exacto de las horas.

3. Promediando puntos de Historia

en una sesión de planificación de poker, la mitad del equipo estima un PBI en 3 puntos de Historia y la otra mitad en 5 puntos de Historia. Es fácil resolver la discusión simplemente poniendo 4 puntos de la historia como la estimación. El equipo no debe hacer esto, ya que una vez más intenta proporcionar una falsa sensación de precisión., El punto no es ser 100% exacto. El punto es ser lo suficientemente preciso como para planificar con anticipación. Además, puede perder una discusión valiosa al promediar. Tal vez 5 puntos de historia era una mejor estimación.

4. Ajustar las estimaciones de puntos de la historia de los problemas durante el Sprint

Cuando el equipo comienza a trabajar en un problema, el equipo no debe ajustar la estimación de puntos de la historia. Incluso si resulta que su estimación era inexacta. Si la estimación era inexacta, es parte de la velocidad final del Sprint. Es normal que las estimaciones sean a veces apagado., No perderás esta información, y será parte de la velocidad histórica de un equipo.

5. Nunca errores que apunten historias

un error no relacionado con el Sprint actual solo debe ser apuntado por historias. El error representa el trabajo que el equipo necesita completar. Esto no se aplica si el equipo reserva un porcentaje fijo de tiempo para trabajar en errores durante el sprint. Un error relacionado con un problema en el sprint no debe ser apuntado, ya que esto es parte de la estimación original.

6. Agregar puntos de historia a tareas pequeñas

un pequeño pico para investigar algo debería estar en caja de tiempo., Está claro que tomará 4 horas para hacerlo, y no hay necesidad de traer ningún punto de la historia en la mezcla.

7. Ajustar cada Sprint de PBI de referencia

Cuando un equipo ajusta cada sprint de PBI de referencia, la velocidad de diferentes Sprints ya no es comparable. El equipo pierde información ya no se puede utilizar la velocidad histórica para planificar con antelación. Es mejor usar una gama de PBI recientes como referencia.

8. Cuando se mueve un PBI inacabado al siguiente sprint, no es necesario volver a estimar., La estimación puede no haber sido exacta, pero eso no es ningún problema. Como resultado de la planificación de Sprint, el equipo sabrá todas las tareas necesarias para completar el problema. La estimación de estas tareas es en horas. Así que en el próximo Sprint, el equipo sabrá cuánto tiempo le queda para completar el PBI. El hecho de que el PBI no se haya completado será parte de la velocidad.

9. Ajustar la estimación de puntos de la historia porque un desarrollador específico trabajará en ella

señalar la historia un PBI es relativo a la historia del usuario de referencia y lo hace el equipo., Los miembros del equipo historia punto el PBI y llegar a un acuerdo sobre la estimación en una sesión de planificación de Poker. Un PBI puede ser 3 puntos de historia para un desarrollador senior, pero 8 puntos de historia para un desarrollador junior. El equipo debe llegar a un acuerdo sobre cuánto trabajo representa para el equipo y usarlo para la planificación. No debe ajustar los puntos de la historia porque una persona específica hará el trabajo. Tal vez en el momento en que comienzan a trabajar en el tema, El Desarrollador Senior está trabajando en un problema de producción. Entonces puede ser necesario que el desarrollador Junior lo recoja.

10., Nunca ajustar la referencia de PBI

cuando la composición del equipo cambia, esto puede afectar la velocidad y las estimaciones de puntos de Historia. Ambos dependen del equipo que realiza el trabajo. Imagine que la historia señaló el problema cuando dos desarrolladores Sénior estaban presentes. Para cuando quieras empezar a trabajar en estos temas, ambos dejaron la empresa. Ahora dos nuevos desarrolladores Junior están en el equipo. Es una buena práctica establecer una nueva historia de usuario de referencia en la que todo el equipo ha trabajado., Esto asegura que todos estén en la misma página cuando apunten la historia, y le da al equipo algo de tiempo para establecer una nueva velocidad. A medida que el equipo se vuelve más maduro y mejor en la estimación, puede ser una buena idea establecer nuevos PBI de referencia.

11. De acuerdo con el experto en la habitación.

al planificar Poker, existe el riesgo de que el equipo se ajuste al experto obvio en la sala. Una forma de resolver esto es dejar que el experto elabore el trabajo. Luego haga que el resto del equipo Calcule sin el experto. Es inevitable desarrollar conocimientos especializados específicos., No permita que esto socave el hecho de que la estimación es un esfuerzo de equipo.

12. No discutir incorrectamente temas relacionados con la historia en retrospectiva.

de vez en cuando, la historia del equipo señala un problema en el que está claro que la estimación estaba completamente fuera. Es importante discutir estos temas y tratar de aprender, para que las estimaciones futuras sean más precisas. En uno de mis equipos, olvidamos tener en cuenta la creación de datos de prueba a la hora de realizar la estimación. Así que hicimos un punto especial para discutir para cada problema si la creación de datos de prueba era aplicable., Cuando corresponda, preguntaríamos si tuvieron en cuenta la creación de datos de prueba. Esto mejoró mucho nuestras estimaciones.

conclusión

El concepto de puntos de la historia es simple pero difícil de aplicar. Casi todos los equipos de Scrum los usan, pero no forman parte de la Guía Oficial de Scrum. Debido a esto, las personas tienen diferentes opiniones sobre cómo debe usarlos. El término punto de la historia en sí ya es confuso, ya que puede usarlo para tipos de trabajo que no sean historias de usuario. Además de eso,’ punto ‘ sugiere que un punto de la historia representa valor., Como señaló un colega, tal vez el término «factor de planificación» ayudaría a reducir la confusión que muchas personas experimentan. Ser consciente de los errores que se pueden cometer al usar los puntos de la historia ayuda a aplicarlos de la manera correcta.