Guía Scrum | 23. Puntos de historia y estimación en Scrum
Publicado: 2022-05-26En el artículo de hoy, cubrimos el tema de Estimación y Puntos de historia en Scrum. La creación de estimaciones en Scrum ayuda a predecir la complejidad y el tiempo necesarios para completar las tareas. Al analizar el pasado, todo el Equipo Scrum pronostica colectivamente lo que depara el futuro.
Por lo tanto, cuanto más experimentado sea el Scrum Team, más precisas serán sus estimaciones. El equipo también colabora en establecer el tiempo estimado para completar las tareas durante Sprint Planning, teniendo en cuenta que no es un compromiso final sino una predicción. Su precisión depende de numerosas variables que constantemente sufren cambios imprevisibles y circunstancias inesperadas. Afortunadamente, la metodología Scrum incluye técnicas y herramientas para facilitar cierto grado de certeza, y hoy las discutiremos en detalle para que pueda comprenderlas y aplicarlas de inmediato.
Puntos de historia y estimación en Scrum - índice:
- Introducción
- La importancia de los puntos de historia en Scrum
- Los puntos de historia son unidades relativas. Esto significa que:
- Técnicas de estimación relativa
- Resumen
Introducción
En cada Planificación de Sprint, el Dueño del Producto presenta nuevas Historias de Usuario al equipo. El Product Owner los selecciona del Product Backlog para implementarlos en el próximo Sprint. Luego, los miembros del Equipo Scrum estiman conjuntamente la carga de trabajo necesaria para completar este nuevo lote de tareas. Este tipo de asignación es una estimación, una estimación de requisitos.
Parecería que la forma más sencilla es definir el tiempo necesario para completar la tarea en horas o días. Sin embargo, la práctica y la investigación realizadas desde la década de 1940 demuestran lo contrario. Los humanos no pueden estimar con precisión el tiempo requerido para completar incluso tareas muy bien definidas. Además, la cantidad de horas necesarias para completar una tarea depende de quién la esté realizando y de lo que se haya hecho o no antes. Esta es la razón por la que Scrum normalmente usa unidades llamadas Story Points.
La importancia de los puntos de historia en Scrum
Cada Equipo de Desarrollo pone en práctica el valor de un Story Point basándose en la experiencia y el tamaño de las tareas individuales, es decir, siguiendo el principio del empirismo. La mayoría de las veces, durante la planificación de Sprint, Scrum Master selecciona una o más muestras de User Stories completas, que sirven como punto de referencia para determinar el valor de las User Stories a desarrollar.
Es por eso que no puede asignar valores en Story Points sin el contexto. Por ejemplo, si a la primera tarea se le asigna un valor de 10, las tareas posteriores se evaluarán como mayores o menores. De esta forma, dentro de un proyecto Scrum Team, todas las tareas del Product Backlog están relacionadas entre sí. Esto significa que tareas similares realizadas por un Equipo de Desarrollo recibirán una cantidad similar de puntos.
Los puntos de historia son unidades relativas. Esto significa que:
El valor de Story Point se relaciona solo con las tareas realizadas por un Equipo Scrum en particular. Los Story Points describen la velocidad de finalización de las tareas de un equipo. En otras palabras, una Historia de Usuario estimada en 10 Puntos de Historia por el Equipo A, puede obtener 50 por el Equipo B. Esto se debe a que, como mencionamos, su valor está relativamente calculado para otras tareas realizadas por ese equipo, y su experiencia con tareas similares. .
El valor de los Story Points completados en un Sprint no puede ser la base para comparar el desempeño de dos Equipos Scrum. Para evitar errores en la gestión de proyectos Scrum, es importante recordar que la Velocidad de un Equipo de Desarrollo expresada en Story Points realizados en un Sprint no se puede utilizar para comparar el desempeño de dos Equipos. Esto se debe a que podrían hacer el mismo trabajo en Sprints paralelos, que un Equipo estimó en 10 y el otro en 50 Story Points.
Tampoco debe olvidarse que la estimación contiene muchos elementos desconocidos y se realiza sobre la base de datos incompletos. Por esta razón, las predicciones de incluso un Equipo Scrum con mucha experiencia a veces pueden ser muy diferentes del esfuerzo real necesario para completar una Historia de usuario.
Técnicas de estimación relativa
¿Cuáles son las técnicas de estimación más efectivas en Scrum? No existe un método único que funcione para todos los equipos.
Entre las técnicas de estimación dentro de las metodologías ágiles, las más comunes son:
- Planificación de póquer. Este método relativo más popular utiliza un juego de cartas para calcular la cantidad de trabajo necesario para completar una tarea. Son reglas y procesos detallados que cubriremos en un artículo separado.
- Juego de estimación en equipo. Este implica asignar la ejecución de Historias de usuario en un Sprint dado con valores numéricos apropiados seleccionados de la secuencia de Fibonacci. También le hemos dedicado un artículo aparte.
Scrum, por otro lado, rechaza la forma clásica de Estimación Absoluta de la metodología tradicional de gestión de proyectos. La forma en que estima las tareas es definiendo de antemano los meses-persona, la duración y el costo de todo el proyecto. Este es un proceso largo, difícil de implementar y requiere la participación de expertos que tienden a establecer la lógica y el código de conducta, pero no toman medidas que no necesariamente realizarán las tareas cuyo valor estimaron. En otras palabras, no solo es tedioso sino también altamente ineficiente.
Puntos de la historia y estimación: resumen
La estimación es una habilidad muy importante que caracteriza a todos los Equipos Scrum maduros. Estimar la cantidad de tiempo y esfuerzo requerido para completar tareas individuales se convirtió en el enfoque principal de muchas técnicas de estimación relativa, como el póquer de planificación o el juego de estimación en equipo.
User Stories with Story Points es otra técnica de medición eficiente que describimos, con la esperanza de proporcionar a nuestros lectores algunas herramientas útiles. Sin embargo, es importante tener en cuenta que sus cifras se relacionan solo con las tareas particulares realizadas por Scrum Team. Por lo tanto, la cantidad de Story Points no puede convertirse en la base para comparar la velocidad de los diferentes Equipos de Desarrollo.
Si le gusta nuestro contenido, únase a nuestra comunidad de abejas ocupadas en Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.
Guía Scrum:
- Glosario de términos básicos, roles y nociones
- ¿Qué es Scrum?
- valores de scrum
- ¿Cómo implementar Scrum en tu empresa?
- Equipo Scrum: ¿qué es y cómo funciona?
- ¿Quién es un propietario del producto?
- Los errores más comunes del Product Owner
- ¿Quién es el Scrum Master?
- Características de un buen Scrum Master
- Los errores más comunes de Scrum Master
- ¿Qué estadísticas y métricas debe rastrear el Scrum Master?
- Cooperación entre el propietario del producto y Scrum Master
- Equipo de desarrollo en Scrum
- Los errores más comunes de los Desarrolladores
- artefactos de scrum
- Escalamiento Scrum
- Pila de Sprint
- ¿Qué es la cartera de productos?
- ¿Qué son las historias de usuario?
- Creando la mejor historia de usuario con INVEST
- Los errores más comunes de las historias de usuario
- Criterios de aceptación de historias de usuario
- Estimación y puntos de historia en Scrum
- Planificación de póquer
- Juego de estimación en equipo
- Definición de incremento
- Eventos de scrum
- ¿Qué es Sprint en Scrum?
- Compromisos del equipo Scrum: objetivo del producto, objetivo del Sprint y definición de finalización
- ¿Qué es un gráfico Burndown?
- ¿Cómo crear e interpretar un gráfico de evolución?
- Ventajas y desventajas del Burndown Chart
- Tableros Kanban en Scrum y Scrumban
- Velocidad en Scrum - Velocidad del Equipo de Desarrollo
- Scrum diario
- Planificación de Sprint
- Revisión de Sprint
- ¿Qué es una retrospectiva de Sprint?
- Errores comunes durante una Retrospectiva de Sprint
- Nutrición de la cartera de productos