Un primer punto a destacar es que en un contexto ágil los ítems de trabajo deberían ser, en general, elementos de valor de cara al cliente. Es decir, los ítems deberían ser cambios en el producto o servicio que recibe el cliente. Aunque el equipo pueda descomponer un ítem de trabajo en tareas técnicas, lo relevante en términos de satisfacción del cliente es la entrega del ítem de trabajo como un todo y desde su perspectiva. Además, un ítem de trabajo debe tener una granularidad consecuente con las entregas frecuentes que se esperan realizar. A modo orientativo si un ítem de trabajo es una Épica, es decir , es demasiado grande/complejo para terminarlo en una semana (considerando la Capacidad del equipo), habría que descomponerlo en partes o incrementos que permitan hacer una entrega parcial. Pero dichas partes o incrementos deberían ser establecidos desde la perspectiva del cliente, es decir, apreciables por él como una entrega parcial.
Las estimaciones en sí mismas no aportan valor al cliente, con lo cual de entrada podrían ser prescindibles :-). No estimar es una opción válida en contextos de trabajo muy favorables para el enfoque ágil. Por ejemplo, cuando existe una estrecha colaboración y complicidad con el cliente y él está satisfecho consiguiendo continuamente funcionalidad, cuando la planificación es a corto plazo y solo se establece el Sprint actual y quizás el próximo, o cuando simplemente no se usan Sprints y se pone el foco en generar un buen flujo de trabajo terminado con entregas frecuentes, pero sin planificación a priori. Es decir, en un contexto muy flexibile, con constante posibilidad de negociación del alcance y plazos, la estimación podría ser prescindible. Desgraciadamente, aunque dichas condiciones favorables serían ideales para una aplicación del enfoque ágil, no es lo usual, ya que cuestiones contractuales tradicionales tienden a establecer compromisos de alcance, plazos y costos bajo condiciones poco flexibles. De todas formas, aunque fuera posible prescindir de las estimaciones, siempre puede rentabilizarse el esfuerzo invertido en ellas, por el simple hecho de que una estimación conlleva la definición, al menos preliminar, del trabajo que se va a realizar, lo cual es importante en ciertos ítems de trabajo que por envergadura o complejidad requieren una evaluación preliminar que nos advierta del desafío que involucran.
La estimaciones conllevan un nivel de precisión esperado el cual está condicionado por el nivel de definición de la unidad de trabajo. Obviamente la precisión de dicha estimación es mayor mientras más nos acercamos al término de la implementación del trabajo :-). Sin embargo, desde el momento de la identificación de un ítem de trabajo es interesante poder contar con una estimación al menos preliminar.
Estimación usando Puntos. Un punto es una medida de tamaño relativa a una unidad de trabajo de referencia. La estimación en Puntos puede ser consensuada fácilmente por el equipo, utilizando por ejemplo Planning Poker, donde los Puntos corresponden a una escala de Fibonacci modificada. El equipo establece una unidad de trabajo de referencia y le asigna unos determinados Puntos, así la estimación de cualquier otra unidad de trabajo se hace por comparación de tamaño respecto de la referencia establecida. Por ejemplo, si la referencia tiene 3 puntos, a una unidad de trabajo del doble de tamaño se le asociarían 6 Puntos, a una de la mitad 1.5 Puntos, una que es cuatro veces más grande 12 Puntos, etc. En todo caso por tratarse de estimaciones no tiene mucho sentido trabajar con decimales o complicarse por una precisión de un punto de más o de menos. Si además el equipo mantiene un registro de su capacidad en Puntos (registro de cuántos Puntos ha podido realizar en un cierto período de tiempo), dispondría con ello de un mecanismo probablemente suficiente para una evaluación de factibilidad y/o planificación global de sus Sprints o Proyectos, todo ello con muy poco esfuerzo y de forma temprana. Por ejemplo, si el equipo en el último Sprint terminó un conjunto de unidades de trabajo que sumaban 50 puntos, si planificamos un próximo Sprint (de la misma duración y con condiciones similares de trabajo para el equipo) sería razonable prever que se puede realizar un nuevo conjunto de unidades de trabajo cuya suma de Puntos no sobrepase 50 Puntos (la Capacidad actual del equipo).
Algunos inconvenientes de la estimación usando Puntos. Antes es importante insistir en que usando Puntos como una medida global del tamaño de cada unidad de trabajo y contrastándolo con la Capacidad disponible del equipo para un Sprint o Proyecto podría ser suficiente para gestionar el alcance durante el desarrollo del trabajo. Sin embargo, desde el punto de vista del seguimiento diario del trabajo restante (por ejemplo, en una gráfica Burndown) la pregunta ¿cuánto esfuerzo nos queda para terminar?, responder esto en Puntos no resulta tan directo, como tampoco el hacer un ajuste en la estimación cuando se detecta que se requerirá más o menos que el esfuerzo previsto. Si se trabaja con Puntos deberíamos esperar a que el trabajo termine para descontar los Puntos que se estimaron para él. Además, una estimación en Puntos se hace como una valoración global del esfuerzo de un ítem de trabajo, sin distinguir los esfuerzos particulares asociados a cada actividad que debe realizarse sobre ella. Podríamos tener una estimación para cada actividad que pensamos llevar a cabo en el ítem de trabajo, por ejemplo, estimar el esfuerzo de analizar, de implementarlo y de probarlo, etc., pero NO es lo que se pretende cuando se hace una estimación en Puntos. Al estimar usando Puntos se busca una estimación a nivel global, es decir, se quiere dimensionar el ítem de trabajo como un todo, no a nivel de actividad. Sin embargo, si durante el seguimiento queremos conocer el estado de avance en términos de esfuerzo restante, normalmente éste esfuerzo lo necesitaríamos a nivel de actividad, y no tiene sentido preguntarse cuántos Puntos le restan a una actividad, menos si la estimación inicial se hizo a nivel global. Por ejemplo, no tendría sentido preguntarle a un programador cuántos Puntos le faltan para terminar un ítem de trabajo. Finalmente, los Puntos son una medida relativa y en el marco de trabajo de un equipo, lo cual impediría obtener estadísticas de esfuerzo y capacidad más allá del ámbito de cada equipo. Paradójicamente y confirmando estos inconvenientes asociados a trabajar con Puntos, he leído en repetidas ocasiones comentarios recomendando establecer equivalencias entre un Punto de Historia de Usuario o de Tarea con semanas, días u horas, intentando hacer más intuitivo el concepto de Punto :-). Si al estimar en Puntos hacemos una correlación con tiempo de trabajo lo mejor es reconocer que NO estamos estimando en Puntos sino en tiempo (como comento a continuación).
Estimación usando Horas Ideales. Por los inconvenientes indicados, cuando es necesario un seguimiento más detallado (vuelvo a insistir que depende del contexto, y puede que NO se requiera ese detalle), de forma alternativa o complementaria se puede usar Horas Ideales. Una Hora Ideal es una hora ininterrumpida de trabajo, es decir, al estimar en Horas Ideales se piensa (idealmente) como si el trabajo se fuera a realizar en horas continuas, sin considerar pausas ni interrupciones. Normalmente cuando establecemos, por ejemplo, que una unidad de trabajo tomará 10 horas de programación, lo estaríamos haciendo de forma intuitiva y fácil pensando solo en el tiempo que se invertiría si se trabajara de forma continua y sin interrupciones. Luego en la práctica ese trabajo podría cronológicamente llevarse a cabo, por ejemplo, durante una semana puesto que desde cuando se empiece podría tener interrupciones, es decir, puede que no se llegará a trabajar continuamente 10 horas en dicha actividad, pero con respecto a comparar la Capacidad disponible con el Esfuerzo Estimado habremos conseguido nuestro propósito. Por otra parte, cuando el programador responsable reflexione respecto al esfuerzo restante para acabar la programación de la unidad de trabajo, le será sencillo volver a establecer las Horas Ideales que estima que le restan de trabajo,o si es necesario hacer ajustes a dicha estimación. Según lo anterior, es muy importante hacer la diferencia entre la estimación (en Horas Ideales) y la previsión o compromiso de término de un ítem de trabajo, esto último dependerá de la previsión de disponibilidad de tiempo que se tenga para realizar el trabajo y las interrupciones que podrían ocurrir. Esto es extensible al ámbito del Sprint o Proyecto como un todo, es decir, por una parte existe una estimación de esfuerzo y por otra la Capacidad que se prevé que el equipo tiene en el período de tiempo dentro del plazo de entrega.
Sigamos entonces comentando la estrategia de estimación usando Horas Ideales y a nivel de actividad realizada sobre un ítem de trabajo. Dichas actividades corresponden al workflow que sigue la unidad de trabajo, es decir, en términos de un tablero kanban, dichas actividades son las columnas por las cuales pasa el ítem de trabajo (como si fuese el post-it que transita en el tablero kanban). ¿Interesa estimar todas las actividades por las cuales pasará el ítem de trabajo?. Categóricamente NO, primero porque hay algunas actividades para las cuales a priori sería difícil prever cuánto esfuerzo requerirán (por ejemplo, cuánto se tardará en definir una unidad de trabajo sin todavía conocer más detalles de ella, detalles que se irían descubriendo durante esa misma actividad), además, habrá actividades que consumen un esfuerzo despreciable que no merece la pena estimar. Por otra parte, siempre podemos separar las actividades en dos grupos, las de preparación que normalmente deberían realizarse mientras la unidad de trabajo está en el Backlog, y las de implementación, aquellas actividades que se realizarán en el Sprint (cuando no se usa Sprints podemos considerar que todo el trabajo se realiza directamente sobre el Backlog). Como el propósito es establecer Sprints que supongan un esfuerzo que no supere la Capacidad del equipo, las actividades interesantes para ser estimadas y así establecer el esfuerzo asociado al Sprint serán aquellas que se realizan durante el período del Sprint. Más aún, NO es necesario/rentable realizar estimaciones para todas las actividades de implementación. La TOC (Theory of Constraints, propuesta por Goldratt) sugiere que para mejorar un proceso de producción hay que poner atención y centrarse en mejorar las actividades que constituyen una limitación para el sistema (aquellas que pueden constituir un cuello de botella). Así pues si identificamos una actividad que por escasez de Capacidad para realizarla (u otros motivos) es un posible cuello de botella, dicha actividad debería ser aquella para la cual se realice una estimación y para la cual correspondientemente se tenga un registro de la Capacidad del equipo. En desarrollo de software, los cuellos de botella en un Sprint podrían darse en algunas actividades asociadas a programación y/o a pruebas. Así pues, por ejemplo, si la capacidad en Horas Ideales de programación por semana para un equipo de desarrollo fuera de 200 horas, cuando se esté planteando un próximo Sprint de 3 semanas, la suma de las estimaciones de esfuerzo de programación para los ítems de trabajo asignados al Sprint no debería superar las 600 horas (ni tampoco ser mucho menor que ello).
Las estimación pueden variar según la experiencia/habilidad de quien ejecutará el trabajo. Este aspecto es muy importante pero debería ser circunstancial, es decir, solo debería ocurrir en determinadas situaciones, por ejemplo, cuando se trata de un trabajo totalmente nuevo para el equipo o cuando en el equipo exista una deferencia significativa entre el desempeño de sus integrantes ante la realización de un mismo ítem de trabajo. Podría ser el caso de una persona recién incorporada que requiere un período de formación y entrenamiento, luego del cual debería ir poniéndose a nivel del resto de miembros del equipo (el trabajo en parejas puede ser un medio para nivelar rápidamente el desempeño de un nuevo miembro). En un caso extremo, si se tratase de una persona que no llega a ponerse al nivel de rendimiento del resto del equipo posiblemente habrá que tomar la decisión de sacarla de ese equipo. Este inconveniente se puede presentar independientemente de la unidad de esfuerzo que se utilice, Puntos u Horas Ideales, aunque puede resultar más evidente la diferencia de estimación en dos personas con rendimiento muy desigual cuando se estima en Horas Ideales. Respecto del caso cuando se trata de un trabajo para el cual el equipo no tiene experiencia, lo que sugiere Extreme Programming (XP) es realizar un skipe, es decir, una exploración o investigación para conseguir mayor información respecto del esfuerzo que podría requerir dicho trabajo. Es decir, no debemos caer en la tentación de engordar la estimación solo porque no se tiene experiencia. Si abusamos de esto probablemente se caiga en la Ley de Parkinson ("La duración del trabajo se extiende hasta agotar el tiempo disponible para realizarlo"). Además, la recomendación es que la estimación de cada ítem de trabajo sea más bien agresiva, y en lugar de añadir holguras para cada ítem establecer explícitamente un búffer de Capacidad para el Sprint o Proyecto, del cual puedan disponer los ítems que lo necesiten y los cambios menores que aparezcan (lectura recomendada: Búffer de Capacidad para proyectos ágiles).
Finalmente, la estrategia de gestión del esfuerzo y en particular la asociada a estimación debe ser evaluada para cada línea de trabajo del equipo, es decir, un mismo equipo se podrían aplicar diferentes estrategias a los distintos productos o servicios con los cuales trabaja.
En nuestra metodología y herramienta TUNE-UP realizamos dicha configuración de la estrategia de estimación para cada producto o servicio. Sin embargo, de forma integrada se puede realizar el seguimiento de todos los Sprints (incluyendo también el seguimiento para aquellos productos o servicios que no requieren Sprints o estimación). Aunque difieran en cuanto a la estrategia de estimación, cada producto o servicio dispondrá de sus correspondientes mecanismos para el seguimiento, pudiendo corresponder a una implantación pura del método Kanban, una más cercana a Scrum, o incluso una aproximación mixta.
Estimación usando Puntos. Un punto es una medida de tamaño relativa a una unidad de trabajo de referencia. La estimación en Puntos puede ser consensuada fácilmente por el equipo, utilizando por ejemplo Planning Poker, donde los Puntos corresponden a una escala de Fibonacci modificada. El equipo establece una unidad de trabajo de referencia y le asigna unos determinados Puntos, así la estimación de cualquier otra unidad de trabajo se hace por comparación de tamaño respecto de la referencia establecida. Por ejemplo, si la referencia tiene 3 puntos, a una unidad de trabajo del doble de tamaño se le asociarían 6 Puntos, a una de la mitad 1.5 Puntos, una que es cuatro veces más grande 12 Puntos, etc. En todo caso por tratarse de estimaciones no tiene mucho sentido trabajar con decimales o complicarse por una precisión de un punto de más o de menos. Si además el equipo mantiene un registro de su capacidad en Puntos (registro de cuántos Puntos ha podido realizar en un cierto período de tiempo), dispondría con ello de un mecanismo probablemente suficiente para una evaluación de factibilidad y/o planificación global de sus Sprints o Proyectos, todo ello con muy poco esfuerzo y de forma temprana. Por ejemplo, si el equipo en el último Sprint terminó un conjunto de unidades de trabajo que sumaban 50 puntos, si planificamos un próximo Sprint (de la misma duración y con condiciones similares de trabajo para el equipo) sería razonable prever que se puede realizar un nuevo conjunto de unidades de trabajo cuya suma de Puntos no sobrepase 50 Puntos (la Capacidad actual del equipo).
Algunos inconvenientes de la estimación usando Puntos. Antes es importante insistir en que usando Puntos como una medida global del tamaño de cada unidad de trabajo y contrastándolo con la Capacidad disponible del equipo para un Sprint o Proyecto podría ser suficiente para gestionar el alcance durante el desarrollo del trabajo. Sin embargo, desde el punto de vista del seguimiento diario del trabajo restante (por ejemplo, en una gráfica Burndown) la pregunta ¿cuánto esfuerzo nos queda para terminar?, responder esto en Puntos no resulta tan directo, como tampoco el hacer un ajuste en la estimación cuando se detecta que se requerirá más o menos que el esfuerzo previsto. Si se trabaja con Puntos deberíamos esperar a que el trabajo termine para descontar los Puntos que se estimaron para él. Además, una estimación en Puntos se hace como una valoración global del esfuerzo de un ítem de trabajo, sin distinguir los esfuerzos particulares asociados a cada actividad que debe realizarse sobre ella. Podríamos tener una estimación para cada actividad que pensamos llevar a cabo en el ítem de trabajo, por ejemplo, estimar el esfuerzo de analizar, de implementarlo y de probarlo, etc., pero NO es lo que se pretende cuando se hace una estimación en Puntos. Al estimar usando Puntos se busca una estimación a nivel global, es decir, se quiere dimensionar el ítem de trabajo como un todo, no a nivel de actividad. Sin embargo, si durante el seguimiento queremos conocer el estado de avance en términos de esfuerzo restante, normalmente éste esfuerzo lo necesitaríamos a nivel de actividad, y no tiene sentido preguntarse cuántos Puntos le restan a una actividad, menos si la estimación inicial se hizo a nivel global. Por ejemplo, no tendría sentido preguntarle a un programador cuántos Puntos le faltan para terminar un ítem de trabajo. Finalmente, los Puntos son una medida relativa y en el marco de trabajo de un equipo, lo cual impediría obtener estadísticas de esfuerzo y capacidad más allá del ámbito de cada equipo. Paradójicamente y confirmando estos inconvenientes asociados a trabajar con Puntos, he leído en repetidas ocasiones comentarios recomendando establecer equivalencias entre un Punto de Historia de Usuario o de Tarea con semanas, días u horas, intentando hacer más intuitivo el concepto de Punto :-). Si al estimar en Puntos hacemos una correlación con tiempo de trabajo lo mejor es reconocer que NO estamos estimando en Puntos sino en tiempo (como comento a continuación).
Estimación usando Horas Ideales. Por los inconvenientes indicados, cuando es necesario un seguimiento más detallado (vuelvo a insistir que depende del contexto, y puede que NO se requiera ese detalle), de forma alternativa o complementaria se puede usar Horas Ideales. Una Hora Ideal es una hora ininterrumpida de trabajo, es decir, al estimar en Horas Ideales se piensa (idealmente) como si el trabajo se fuera a realizar en horas continuas, sin considerar pausas ni interrupciones. Normalmente cuando establecemos, por ejemplo, que una unidad de trabajo tomará 10 horas de programación, lo estaríamos haciendo de forma intuitiva y fácil pensando solo en el tiempo que se invertiría si se trabajara de forma continua y sin interrupciones. Luego en la práctica ese trabajo podría cronológicamente llevarse a cabo, por ejemplo, durante una semana puesto que desde cuando se empiece podría tener interrupciones, es decir, puede que no se llegará a trabajar continuamente 10 horas en dicha actividad, pero con respecto a comparar la Capacidad disponible con el Esfuerzo Estimado habremos conseguido nuestro propósito. Por otra parte, cuando el programador responsable reflexione respecto al esfuerzo restante para acabar la programación de la unidad de trabajo, le será sencillo volver a establecer las Horas Ideales que estima que le restan de trabajo,o si es necesario hacer ajustes a dicha estimación. Según lo anterior, es muy importante hacer la diferencia entre la estimación (en Horas Ideales) y la previsión o compromiso de término de un ítem de trabajo, esto último dependerá de la previsión de disponibilidad de tiempo que se tenga para realizar el trabajo y las interrupciones que podrían ocurrir. Esto es extensible al ámbito del Sprint o Proyecto como un todo, es decir, por una parte existe una estimación de esfuerzo y por otra la Capacidad que se prevé que el equipo tiene en el período de tiempo dentro del plazo de entrega.
Sigamos entonces comentando la estrategia de estimación usando Horas Ideales y a nivel de actividad realizada sobre un ítem de trabajo. Dichas actividades corresponden al workflow que sigue la unidad de trabajo, es decir, en términos de un tablero kanban, dichas actividades son las columnas por las cuales pasa el ítem de trabajo (como si fuese el post-it que transita en el tablero kanban). ¿Interesa estimar todas las actividades por las cuales pasará el ítem de trabajo?. Categóricamente NO, primero porque hay algunas actividades para las cuales a priori sería difícil prever cuánto esfuerzo requerirán (por ejemplo, cuánto se tardará en definir una unidad de trabajo sin todavía conocer más detalles de ella, detalles que se irían descubriendo durante esa misma actividad), además, habrá actividades que consumen un esfuerzo despreciable que no merece la pena estimar. Por otra parte, siempre podemos separar las actividades en dos grupos, las de preparación que normalmente deberían realizarse mientras la unidad de trabajo está en el Backlog, y las de implementación, aquellas actividades que se realizarán en el Sprint (cuando no se usa Sprints podemos considerar que todo el trabajo se realiza directamente sobre el Backlog). Como el propósito es establecer Sprints que supongan un esfuerzo que no supere la Capacidad del equipo, las actividades interesantes para ser estimadas y así establecer el esfuerzo asociado al Sprint serán aquellas que se realizan durante el período del Sprint. Más aún, NO es necesario/rentable realizar estimaciones para todas las actividades de implementación. La TOC (Theory of Constraints, propuesta por Goldratt) sugiere que para mejorar un proceso de producción hay que poner atención y centrarse en mejorar las actividades que constituyen una limitación para el sistema (aquellas que pueden constituir un cuello de botella). Así pues si identificamos una actividad que por escasez de Capacidad para realizarla (u otros motivos) es un posible cuello de botella, dicha actividad debería ser aquella para la cual se realice una estimación y para la cual correspondientemente se tenga un registro de la Capacidad del equipo. En desarrollo de software, los cuellos de botella en un Sprint podrían darse en algunas actividades asociadas a programación y/o a pruebas. Así pues, por ejemplo, si la capacidad en Horas Ideales de programación por semana para un equipo de desarrollo fuera de 200 horas, cuando se esté planteando un próximo Sprint de 3 semanas, la suma de las estimaciones de esfuerzo de programación para los ítems de trabajo asignados al Sprint no debería superar las 600 horas (ni tampoco ser mucho menor que ello).
Las estimación pueden variar según la experiencia/habilidad de quien ejecutará el trabajo. Este aspecto es muy importante pero debería ser circunstancial, es decir, solo debería ocurrir en determinadas situaciones, por ejemplo, cuando se trata de un trabajo totalmente nuevo para el equipo o cuando en el equipo exista una deferencia significativa entre el desempeño de sus integrantes ante la realización de un mismo ítem de trabajo. Podría ser el caso de una persona recién incorporada que requiere un período de formación y entrenamiento, luego del cual debería ir poniéndose a nivel del resto de miembros del equipo (el trabajo en parejas puede ser un medio para nivelar rápidamente el desempeño de un nuevo miembro). En un caso extremo, si se tratase de una persona que no llega a ponerse al nivel de rendimiento del resto del equipo posiblemente habrá que tomar la decisión de sacarla de ese equipo. Este inconveniente se puede presentar independientemente de la unidad de esfuerzo que se utilice, Puntos u Horas Ideales, aunque puede resultar más evidente la diferencia de estimación en dos personas con rendimiento muy desigual cuando se estima en Horas Ideales. Respecto del caso cuando se trata de un trabajo para el cual el equipo no tiene experiencia, lo que sugiere Extreme Programming (XP) es realizar un skipe, es decir, una exploración o investigación para conseguir mayor información respecto del esfuerzo que podría requerir dicho trabajo. Es decir, no debemos caer en la tentación de engordar la estimación solo porque no se tiene experiencia. Si abusamos de esto probablemente se caiga en la Ley de Parkinson ("La duración del trabajo se extiende hasta agotar el tiempo disponible para realizarlo"). Además, la recomendación es que la estimación de cada ítem de trabajo sea más bien agresiva, y en lugar de añadir holguras para cada ítem establecer explícitamente un búffer de Capacidad para el Sprint o Proyecto, del cual puedan disponer los ítems que lo necesiten y los cambios menores que aparezcan (lectura recomendada: Búffer de Capacidad para proyectos ágiles).
Finalmente, la estrategia de gestión del esfuerzo y en particular la asociada a estimación debe ser evaluada para cada línea de trabajo del equipo, es decir, un mismo equipo se podrían aplicar diferentes estrategias a los distintos productos o servicios con los cuales trabaja.
En nuestra metodología y herramienta TUNE-UP realizamos dicha configuración de la estrategia de estimación para cada producto o servicio. Sin embargo, de forma integrada se puede realizar el seguimiento de todos los Sprints (incluyendo también el seguimiento para aquellos productos o servicios que no requieren Sprints o estimación). Aunque difieran en cuanto a la estrategia de estimación, cada producto o servicio dispondrá de sus correspondientes mecanismos para el seguimiento, pudiendo corresponder a una implantación pura del método Kanban, una más cercana a Scrum, o incluso una aproximación mixta.
