La información irrelevante en una especificación o Product Backlog suele conllevar a mayores estimaciones

No es la primera vez que suelo comentarte que en lo nuestro hay que tener cuidado con los estudios (véase ¿Cuántos proyectos fallan?, año 2008), y las deducciones que se hacen desde los mismos, ya que muchos de ellos, que propugnan ideas que parecen irrefutables… hay dudas sobre su validez, datos sobre la aplicación a tu mismo contexto, país, tipología de las cosas que tú haces, etc.
Para saber si puedes extrapolar lo que dice algún estudio, en mi caso, lo que pretendo aplicar es usar el sentido común (aunque este es un bien escaso en el mundo), que sea de una fuente fiable y que mucha gente con cierto nombre haya opinado de él.
Según, y cumpliendo, lo anterior vamos con uno que ya tiene sus años, y sus referencias de renombre… aumentar el tamaño de la especificación de necesidades, requisitos, etc., (o como quieras llamarlo) con información irrelevante suele llevar a hacer estimaciones mayores (puedes leer más en How to avoid impact from irrelevant and misleading information on your cost estimates o The Impact of Irrelevant and Misleading Information on Software)
Derivaciones de lo anterior, y casos de estudio…
– Dada la misma especificación a dos grupos, proporcionándole a uno la información justa y a otro la misma especificación pero en más páginas… el segundo grupo estima más horas de trabajo. Y no sólo por meter más información en un documento u otro, sino incluso con el mismo número de palabras pero aumentando el interlineado para que haya más páginas.
– Dada un Product Backlog a dos grupos, al primero le pedimos que estime un conjunto de items, y sólo le pasamos esos items, al segundo le decimos lo mismo, que estime los mismos items, pero le pasamos un product Backlog con más items (que no tiene que estimar)… el segundo grupo estima más horas de trabajo.
Datos sobre los anteriores experimentos los puedes encontrar en los anteriores estudios, no te aburro con ellos, si los necesitas ahí están. Y si metes en google este tema verás muchos otros autores que hablan sobre ello.
Moraleja… reduce al máximo la información irrelevante.

Elimina la información irrelevante que se cuela por todas partes

Las antiguas especificaciones de requisitos, y otros, típicamente incluyen información irrelevante para la estimación, quizá de importancia para otros fines, pero no de importancia para el equipo, como contexto, introducción al documento, quién lo ha versionado, pre-condiciones, listas de autorizados para leerlo, etc..
Eso por lo que respecta al mundo más clásico, si te vas al mundo ágil… no le pases al equipo todo el Product Backlog, con centenares de items para que estime solo unos pocos. Como Product Owner selecciona un pequeño subconjunto, priorizado por valor, del que obtener una estimación.
Ya sabes… elimina desperdicios.

jgarzas

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.

Dejar un comentario

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