.

Como estimar el Backlog de Producto

En nuestra última lección sobre el sprint y su planificación, concluimos preguntándonos quién debía estimar el tamaño de los artículos del Backlog de Producto. Bien, ¿ a ti quien o quienes te parece que deben ser los responsables de hacerlo?

Estimación

La estimación debe realizarse por aquellos que se supone que harán el trabajo, y en Scrum son el equipo de desarrollo.

equipo de desarrolloEl equipo de desarrollo es el segundo rol en el marco de trabajo Scrum, el primero fue el Dueño del Producto, sobre el que ya hemos hablado. En un equipo de trabajo que utilice Scrum debe haber entre 3 y 9 desarrolladores. “Desarrolladores” es un término que se refiere a los analistas, diseñadores, programadores, testers, diseñadores de interfaz de usuario, y cualquier otra persona que tiene un papel en la producción de la solución.

Cuando el Dueño del Producto crea un nuevo elemento del Backlog de Producto, se dirige al equipo de desarrollo, explica su significado y pide a al equipo de desarrolladores que realicen una estimación. Los desarrolladores, tras discutirlo, acordaran una estimación. El propietario del producto agrega la estimación al elemento del Backlog de Producto. Esto se conoce como el “aseo” o “refinamiento” del Backlog de Producto.

Ahora ya sabes algo más a cerca de la estimación de los elementos del Backlog de Porducto, pero aún hay algunas otras cuestiones al respecto que resolver. ¿Cuál piensas que debería ser la unidad para estimar el tamaño de los elementos del Backlog de Producto, tiempo, esfuerzo…?

Unidades de estimación en Scrum

En Scrum preferimos estimar en base a unidades de esfuerzo relativo,  en lugar de en unidades basadas en tiempo, tales como horas-hombre. Si empleáramos horas-hombre siempre podría haber alguien que dijera: “durante este Sprint habéis creado 10 elementos del Backlog de Producto por un valor estimado de 381 horas-hombre. Sois 6 personas trabajando en Sprints de dos semanas, lo que hacen un total de 528 horas-hombre. ¿Por qué vuestra producción ha sido tan baja? ¿Qué va mal?”

Queremos evitar la anterior situación, pues tan pronto como se empiece a culpar a los desarrolladores  estos empezaran a añadir márgenes de seguridad es sus estimaciones; en lugar de decir que algo requiere 20 horas-hombre, dirán que necesitan 35 horas-hombre para evitar ser cuestionados, lo que creará un montón de problemas. Para empezar, el “sindroma del estudiante”, que consiste en extender el tiempo necesario para realizar un trabajo durante tanto tiempo como del que se disponga. Cuando se suman los márgenes, automáticamente se produce menos.

Por esto no nos gustan las unidades basadas en tiempo. A cambio preferimos utilizar unidades basadas en el esfuerzo relativo que se conocen como puntos de historia. ¿Sabes lo que son? Te lo contaré en nuestra próxima lección que dedicaremos a los Puntos de Historia, y al concepto de velocidad.

Saludos,

JLVG

QuieresCursoGratisImagen700X150_3

Otras lecciones de este curso

01. Curso Gratis de Introducción a Scrum

02. Entonces… ¿qué son los sistemas predictivos y adaptativos?

03. El Backlog de Producto

04. El scrum team: el Dueño del Producto

05. Los sprints

06. La estimación de los elementos de Backlog de Producto

07. Puntos de historia y velocidad

08. Póker de Planificación

09. El scrum team: el Scrum Máster

10. ¿Quien es el Project Manager en scrum?

11. ¿Cómo se desarrolla un sprint?

12. El desarrollo del sprint: medición y cancelación

13. Eventos scrum: el Scrum Diario

14. Eventos scrum (II): la Retrospectiva del Sprint

15. Artefactos scrum (I)

16. Artefactos scrum (II)

17. La “definición de completo”

18. ¿Cómo funciona scrum?

19. Certificaciones scrum

20. Referencias

Una respuesta a “Como estimar el Backlog de Producto”

  1. […] 06. La estimación de los elementos de Backlog de Producto […]

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

AUTOR:  Juan Luis Vila Grau

PRINCE2® practitioner, Scrum Master (PSMI), EXIN Agile Scrum Foundation, AgilePM® Foundation, Management_of_Risk (M_o_R®) Foundation. and an enthusiastic of Agile management. Especialistas en técnicas participativas para la gestión de proyectos, y en el Enfoque del Marco Lógico (EML). Faclilitador certificado en el método LEGO® Serious Play®

Utilizamos cookies de terceros para mejorar nuestros servicios. Si continúa navegando, considera que acepta su uso. Más información aquí.  CERRAR