En Scrum, ¿es obligatorio estimar la cantidad de horas necesarias para terminar cada historia de usuario antes de ponerla en el Sprint? ¿O deberíamos usar el póquer de planificación y usar puntos en lugar de horas?
Scrum no exige ningún tipo de estimación, en realidad. Ni siquiera exige que las historias de los usuarios sean honestas. Jeff Sutherland y Ken Schwaber elaboraron una guía rápida con los elementos esenciales de Scrum aquí http://www.scrumguides.org/ ; vale la pena leerla.
Dicho esto, es muy difícil para un equipo cumplir constantemente con sus compromisos de sprint Y asumir algunos riesgos para innovar y aumentar su productividad de manera incremental sin una medición constante de todo el trabajo que debe completarse en ese período de tiempo. Si no estima historias más pequeñas, o tareas que no llama historias pero en las que va a trabajar, o una investigación técnica (punta) que se está tomando en un sprint, ¿cómo sabe qué nivel de esfuerzo necesita? debería ser capaz de aceptar en los siguientes sprints? ¿Cómo sabe si un tipo particular de historia (o tarea, o investigación, o lo que sea) es una que su equipo siempre tiene un buen manejo (es decir, una estimación precisa) o no?
Pido a mis equipos que calculen todo el trabajo que realizan en un sprint, generalmente con puntos de historia de Fibonacci. Ha tenido mucho éxito en ayudar a descubrir problemas con historias de usuarios mal escritas, tecnologías desconocidas, comunicación insuficiente y muchos otros problemas que impiden que un equipo funcione bien. Puede ser una molestia, y no desea obsesionarse con la precisión de las estimaciones o sobrevalorar su valor, pero la estimación es una gran herramienta para eliminar las ineficiencias de desarrollo a lo largo del proceso.
Los puntos de historia se utilizan para estimar el tamaño relativo de las historias (es decir, "La historia A es aproximadamente el doble de grande que la historia B"), pero esto intencionalmente no dice nada sobre el tamaño absoluto de las historias (es decir, "La historia A dura aproximadamente 6 horas). para terminar, mientras que Story B 3 horas").
La planificación del póquer es una forma de optimizar el tiempo dedicado a la estimación y de hacer que los miembros del equipo discutan historias para llegar a un entendimiento común de las tareas, las preguntas abiertas y los riesgos incluidos en ellas.
No todos los equipos de Scrum utilizan la estimación de puntos de la historia y el póquer de planificación, aunque la mayoría de los expertos que conozco recomiendan ambos. Siempre se requiere cierto nivel de estimación en cualquier tipo de planificación de proyectos; El punto de Scrum es hacer solo el mínimo esfuerzo absolutamente necesario para obtener estimaciones lo suficientemente buenas, y luego refinarlas y ajustarlas durante el proyecto según sea necesario. (A diferencia de otros métodos tradicionales que pueden poner un mayor énfasis en el detalle y la precisión de la estimación, mientras que los resultados finales en la práctica apenas justifican el esfuerzo realizado y solo dan una falsa sensación de seguridad a la gestión).
Entonces, si desea hacer planes con respecto a cuándo puede entregar el próximo lanzamiento o alcanzar un hito importante, debe estimar la velocidad de su equipo , es decir, qué tan rápido pueden completar historias en promedio o cuántas historias pueden completar en un determinado marco de tiempo (sprint). Y para que eso sea significativo, también necesita conocer el tamaño relativo de las historias. Es por eso que se recomienda que los equipos Scrum estimen los puntos de la historia.
Luego, durante la planificación del sprint, el equipo se compromete a completar una cierta cantidad de historias dentro del próximo sprint. Esto es difícil, especialmente para los equipos inexpertos que aún no tienen una idea de su velocidad, no son buenos en la estimación del punto de la historia y/o tienen un rendimiento fluctuante. Aquí es donde puede ser útil pasar por una segunda ronda de estimación, donde cada tarea individual que pertenece a una historia se estima en horas/días. Esto requiere que el equipo tenga una discusión más profunda sobre los detalles de la historia, brindándoles más oportunidades para nivelar los errores de estimación y tener en cuenta todos los factores. Y al final, pueden volver a verificar su estimación sumando el tiempo total requerido para completar las historias seleccionadas para ese sprint.
La parte negativa de estimar por horas es, por supuesto, que requiere más tiempo, lo que ralentiza al equipo y es posible que no brinde suficiente valor para justificarlo. Por lo tanto, los equipos experimentados pueden decidir estimar solo los puntos de la historia, no el tiempo. Pero en las primeras fases de adopción de Scrum, o al formar un nuevo equipo, puede ser útil estimar las horas y los puntos de la historia.
En Scrum, solo dos cosas son obligatorias: (1) envíe algo todos los meses que crea que puede vender y (2) mire cómo lo hizo e intente mejorarlo.
Los "puntos u horas de la historia?" cuestión ha sido objeto de acalorados debates durante 15 años. Muchas personas informan que el mero hecho de contar el número de historias (ni los puntos de la historia ni las horas) se correlacionó mejor con la capacidad a largo plazo que cualquier otra técnica de estimación o escala que hayan usado.
Otras personas recomiendan desechar las estimaciones de costos de las historias y, en cambio, centrarse en completar las historias más valiosas lo antes posible. Cuando eres bueno en eso, importa mucho menos si Story 128 fue un 2 o un 3.
Su pregunta hace parecer que preferiría no estimar el costo de cada historia en horas antes de incluirla en el sprint. Así que no lo hagas. Te apuesto a que estará bien.
Respuesta simple: no. Scrum no requiere que proporcione una estimación de las horas necesarias para finalizar cada elemento de la cartera de productos antes de colocarlo en el Sprint.
De hecho, Scrum simplemente lo invita a proporcionar una estimación. Cómo lo haces, depende de ti.
La técnica más común con la que me encuentro es estimar los elementos de la cartera de productos en puntos de la historia y las tareas en horas.
No, Scrum no requiere horas a nivel de Historia. De hecho, esto se consideraría un antipatrón. Si desea usar horas, solo se aplican en el nivel de Tarea, donde las tareas se consideran los "pasos" necesarios para completar una historia según la Definición de Listo de su equipo.
Mi consejo es saltarse tareas y horas por completo. Las horas a menudo son estimadas por individuos y están sujetas a una amplia gama de incertidumbre. Los Story Points (o simplemente puntos) son estimados por el equipo y están sujetos a refinamiento y mejora con el tiempo a medida que el equipo mejora en la estimación.
Tal como lo explicó @Péter Török, Scrum usa puntos para estimar las historias de los usuarios.
Existen diferentes técnicas para las estimaciones (Fibonacci, Planning Poker , Potencias de dos, etc.) y se relacionan con cuán importante, grande y compleja es la historia. Cuando se combinan, todos esos puntos dan como resultado la velocidad del Sprint (cuánto trabajo es capaz de hacer el equipo en futuros Sprints).
Se recomienda que los desarrolladores sean los que estimen cada historia ya que saben mejor cuánto esfuerzo y tiempo van a tomar.