Las empresas viven con la obsesión de medir sus costes, invertir en la dirección correcta y maximizar sus beneficios. De esta manera se aseguran invertir o no en un proyecto concreto al ver su rentabilidad. Por lo general, esta estimación del beneficio se hace en horas / hombre, pero sin embargo scrum lo realiza en puntos de historia.
Las empresas necesitan saber el coste, así como las horas que le llevará al equipo desarrollar ese producto concreto:
* Los mandos necesitan esta estimación para justificar presupuestos.
* Los gestores necesitan medir el valor entregado para determinar la rentabilidad.
* El departamento de compras quiere tener estimado el esfuerzo para tomar las decisiones correctas a través de sus vendedores.
En equipos nuevos, con poca experiencia en estimación y en metodologías ágiles, esta estimación de puntos de historia / días hombre se hace difícil. En esta estimación influye la experiencia previa en proyectos, las características del proyecto, la complejidad tecnológica, la complejidad funcional así como el tener o no equipos maduros y experimentados.
Si no se dispone de todo esto y estamos en el punto inicial de una nueva implantación con un equipo nuevo, las estimaciones deben tener un porcentaje de error o adaptación. Se puede hacer una primera estimación por valor de complejidad. La historia x es 2 veces más compleja que la historia y estimada inicialmente con un valor de 1. Lógicamente esto se irá ajustando una vez el equipo vaya madurando y adquiriendo conocimiento en los proyectos. Aporta valor al equipo en cuanto a complejidad de historias del backlog, y con el tiempo una velocidad más o menos ajustada al plano real.
La estimación se debe revisar para cada sprint, el equipo debe revisar el alcance global y las historias de usuario restantes con la velocidad del equipo. Si el equipo encuentra fallos o problemas del alcance, se debe discutir y acordar con el cliente, con dirección, ventas, etc. En metodologías tradicionales se solicitaría un esfuerzo adicional, pero Scrum no fomenta eso, fomenta el diálogo con el cliente, el acuerdo y la modificación del alcance. Esto favorece el ajuste necesario de velocidad en base a los sprints realizados con anterioridad.
Para que todo esto funcione hay que educar, a la empresa, las personas, departamentos de ventas, marketing, etc. Con el tiempo puede llegar a haber correspondencia punto de historia / día hombre, pero en un punto inicial no tiene porque ser así, puesto que puede ser punto de historia / complejidad e ir ajustándose.
La mejor aportación a todo esto es priorizar desde el principio correctamente, realizar incluso un MVP (mínimo valor posible) si el cliente así lo acepta y desea, siendo esto el núcleo de la aplicación que deje satisfecho a ambas partes y sobre este MVP ir trabajando añadiendo nuevas funcionalidades. Establecerá un área de seguridad y de confort a ambas partes (desarrolladores y cliente) y servirá de periodo de maduración del equipo para coger experiencia en cargas de trabajo, resolución de sprints y mejora de estimaciones y velocidad.
Esta estimación viene dada por la justificación del dinero, del coste de un proyecto, y se puede optimizar en función de las necesidades del cliente y de la confianza mutua entre empresa – cliente. Existen métodos como paquete cerrado, coste de sprints o coste de punto de historia. Es conseguir el equilibrio entre que los equipos ágiles cumplan con el negocio y/o que el negocio crezca apoyado en los equipos ágiles.
Con el tiempo estas dos perspectivas podrán confluir, y con un equipo suficientemente maduro llegar a decir al cliente: "un punto de historia equivale a 1,2 días de un desarrollador lo que te equivale a xxx euros diarios por persona".
Pero ese es un tema de marketing y finanzas de la empresa, no de desarrollo, donde al equipo ágil le interesa decir : nuestra carga de trabajo por sprint es de x puntos de historia que desarrollaremos entre n personas que conforman el equipo en un sprint que dura z días.
Un equipo se debe centrar en su velocidad, medida en puntos de historia, aunque internamente un departamento de la empresa establezca que cada punto de historia equivale a xxx dinero por persona y día, e incluso dicha valoración con el tiempo llegue a ser visible por el equipo de desarrollo. Esa balanza es la que la empresa deberá de establecer, sin imponer ruido al equipo de desarrollo, viendo la madurez y transparencia de dicho equipo en cuanto a su velocidad / rendimiento / coste, tratando de proteger en caso necesario al equipo de dichos factores externos y evitando manipulación / falsificación de puntos de historia para justificar un presupuesto o un coste de proyecto, con la mejora continua y la transparencia, puesto que puede suceder en momentos concretos que el equipo sea muy productivo y consiga una velocidad superior a la estimada, o por el contrario se reduzca dicha velocidad, y esto no debe adulterar el proceso, al contrario en base a la mejora continua permitirá ajustar dichos parámetros y favorecer la transparencia total entre desarrollo y cliente.
