Uso de hojas de cálculo ágiles para la estimación de descubrimiento

Este artículo incluye una hoja de cálculo con formato previo para ayudarlo a desarrollar estimaciones de descubrimiento Agile. También incluye información para ayudarlo a seguir el ejemplo presentado. Puede hacer una copia editable (Archivo>Hacer una copia o Archivo>Descargar) desde la plantilla aquí.

Los clientes a menudo me piden que proporcione estimaciones ágiles antes de tener un equipo o conocer los requisitos de MVP. En esta etapa inicial, no tengo acceso a las métricas tradicionales como la velocidad, la cantidad de sprints o el costo del equipo para calcular esas estimaciones. Pero los clientes quieren respuestas. ¿Pueden lanzar un producto hipotético en dos meses o en seis? ¿Será factible para su presupuesto (generalmente bajo)?

Ingrese a la hoja de cálculo Agile.

Las hojas de cálculo son una opción adecuada, pero a menudo pasada por alto, para una mentalidad ágil. Son herramientas de baja tecnología y alto contacto que fomentan la colaboración. Dicho esto, a su cliente probablemente no le importe si sus herramientas están "aprobadas por Agile", siempre que el costo y la calidad del producto cumplan con sus requisitos. El verdadero valor de las hojas de cálculo radica en su accesibilidad para los administradores de proyectos y las partes interesadas de todos los niveles de experiencia.

Muchas herramientas de gestión de proyectos especializadas tienen curvas de aprendizaje que son demasiado empinadas para usuarios sin experiencia en proyectos de rápido movimiento. Por lo tanto, cuanto más fácil sea para los clientes, propietarios de productos y desarrolladores actualizar los requisitos y los costos de mano de obra, antes llegará a una estimación realista. Con una hoja de cálculo preformateada, los gerentes de proyecto pueden ajustar valores y parámetros para demostrar los efectos de cada recurso fluctuante o cronograma cambiante.

Las hojas de cálculo también son una excelente manera de compartir conocimientos con sus colegas. La hoja de cálculo que uso se originó con un colega de Toptal, y desde entonces hice una copia y la modifiqué para adaptarla a mis necesidades. Te animo a que tú también lo hagas.

En este artículo, demuestro cómo entregar estimaciones de descubrimiento exitosas que empoderan a los clientes y partes interesadas para alinearse con los objetivos del proyecto y continuar con el desarrollo. Aquí le mostramos cómo completar los espacios en blanco y entregar una estimación inicial que pueda respaldar.

Aborde primero la visión del producto y la hoja de ruta

Supongamos que su cliente quiere desarrollar un sitio web de citas con un presupuesto fijo, pero los detalles del producto son confusos. Sin conocer el costo y la velocidad del equipo, la visión del producto es el mejor lugar para comenzar porque requiere que las partes interesadas acuerden un objetivo de diseño y promueve la transparencia en todo el equipo.

Me gusta el formato de visión de producto de Scrum.org por su estilo narrativo intuitivo. Esto es lo que parece:

Una vez que se establece la visión del producto, puede agregar la Hoja de ruta del producto en una nueva pestaña de la hoja de cálculo para darle al cliente una idea del cronograma del proyecto a largo plazo. La hoja de ruta debe enumerar los objetivos, las características clave y los plazos para cada versión de la hoja de ruta del producto.

Las versiones de hoja de ruta son ediciones planificadas, orientadas al consumidor o al cliente, de un producto que guían su trayectoria de mercado. La primera versión de hoja de ruta es el producto que puede debutar en el mercado. Las versiones subsiguientes de la hoja de ruta representan lanzamientos al mercado con características nuevas y convincentes que se alinean con la visión del producto.

Para usar Microsoft como ejemplo: Windows 8 probablemente era una versión de hoja de ruta. Windows 10 fue otra versión de hoja de ruta que presentaba muchas características nuevas y deseables.

Una vez que la visión del producto y la hoja de ruta están completas, es hora de pedirle al cliente que se comprometa con un MVP.

Negociar características de MVP con el gráfico de triple restricción

Este es el momento de dar forma a las expectativas de su cliente en cuanto a tiempo y gastos utilizando el gráfico de Triple Restricción:

En un enfoque en cascada, las características fijas dictan el tiempo y el costo, y el desarrollo avanza de acuerdo con un plan de proyecto detallado. Por el contrario, los costos fijos y el cronograma de Agile determinan las características del producto, y estas características se vuelven a priorizar constantemente en función de la visión más flexible del proyecto.

El gráfico de Triple Restricción muestra al cliente que incluir todas las características deseadas en la primera versión aumentará el tiempo de desarrollo y los costos de globo. En su lugar, trabaje con el cliente para seleccionar solo las funciones "imprescindibles" para un MVP y anote las funciones restantes para versiones futuras.

Las hojas de cálculo facilitan la agrupación y reasignación de características a diferentes versiones, lanzamientos y prioridades en función de las necesidades cambiantes del cliente, y muestran instantáneamente los costos de estos cambios.

Mientras identifica las funciones de MVP, solicite ayuda a sus expertos en la materia (SME) para enumerar los pasos del proyecto en función de proyectos similares en los que hayan trabajado. Usará estos pasos para crear epopeyas más adelante. Una vez que tenga esas entradas listas, puede comenzar a construir una estimación.

Comience con el tamaño de la camiseta

Para comenzar con el primer trabajo pendiente, pídale al propietario del producto una descripción detallada de las funciones del producto, luego asigne una talla de camiseta a cada función en función de su nivel de dificultad.

El tamaño de la camiseta mostrará la complejidad relativa y la duración de cada tarea de desarrollo antes de que tenga valores absolutos. A medida que avancemos en la planificación de proyectos, convertiremos estos tamaños relativos en puntos de historia y horas de trabajo.

Por ejemplo, si su cliente quiere que desarrolle una serie de ventanas emergentes en el sitio de citas, eso llevaría mucho tiempo pero sería sencillo. Puede caracterizar la complejidad de esa tarea como "Pequeña", pero el esfuerzo sería "Medio". Podría abreviar esto como "SM". Por otro lado, desarrollar una conexión back-end para una nueva API sería una tarea más compleja debido a toda la documentación y pruebas requeridas. La habilidad y la atención necesarias para esto podrían convertirlo en un "Grande" tanto en esfuerzo como en nivel de habilidad: "LL".

Una vez que termine de medir el tamaño de la camiseta, tendrá una idea de la carga de trabajo relativa y los requisitos de habilidades para cada futuro miembro del equipo. Un experto técnico del equipo de desarrollo puede ayudarlo a correlacionar el tamaño de su camiseta con rangos de horas y puntos de la historia.

Establezca sus parámetros

Ahora está listo para poner a trabajar su hoja de cálculo y calcular su estimación. Comience creando una pestaña de Parámetros. Esto servirá como la clave para sus cálculos, y los valores que ingrese aquí se incorporarán a las fórmulas utilizadas en sus pestañas Backlog/User Stories y Budget Summary by Release.

Aquí está todo lo que necesitará en la pestaña Parámetros:

Divisa. Aquí es donde ingresa las conversiones de moneda. Por ejemplo, si el presupuesto del cliente está en reales brasileños, puede ingresar la tasa de conversión actual para dólares o euros.

Fecha de inicio. La fecha prevista de inicio del desarrollo se utilizará para crear un cronograma del proyecto. En cada ejemplo, nuestra fecha de inicio es el 25 de octubre.

Presupuesto Inicial. El presupuesto proporciona restricciones que muestran si todas las funciones de MVP encajarán o no en él.

Talla de camiseta. Ingrese sus tallas de camiseta como una tabla y asigne puntos de historia y un rango de horas a cada combinación de tallas. En este ejemplo, usamos de una a dos horas para un SS y de 33 a 48 horas para un LL.

Ten en cuenta que la duración de tu sprint limitará las horas de tu talla máxima de camiseta. Si el sprint es de solo una semana, el tamaño más grande no puede exceder las 40 horas. Por eso es tan importante consultar a una pyme a la hora de asignar tallas de camiseta a las tareas .

Tarifas por Hora. Use esta tabla para documentar las tarifas de pago para cada función. Si sus desarrolladores de back-end tienen tarifas diferentes, use el promedio de los dos.

Gastos generales. Asigne un porcentaje del esfuerzo total del proyecto a tareas administrativas, como reuniones de estado, sesiones de comentarios y revisiones del proyecto. El diez por ciento (o cuatro horas de la semana laboral de cada participante) es un buen lugar para comenzar, pero los gastos generales pueden ser más altos para proyectos más complejos.

Contingencia. Esto indica la variación potencial en su estimación. Comenzar con una contingencia del 0 % le mostrará el presupuesto y el cronograma del mejor de los casos (es decir, improbable) dados los valores que ingresó en la hoja de cálculo. Más adelante en nuestro ejemplo, aumentaremos la contingencia a una variación aproximada del orden de magnitud (ROM) del 50 % para mostrar el extremo superior potencial de los costos y la duración del proyecto. La contingencia se reducirá a medida que obtenga números más precisos.

Dimensione cada lanzamiento con epopeyas

Comenzamos con un dimensionamiento aproximado del producto completo para asegurarnos de no desperdiciar el tiempo o el dinero del cliente. Dependiendo de qué tan cerca se acerque el dimensionamiento a su presupuesto y plazo propuestos, el cliente puede decidir abandonar el proyecto o invertir en estimaciones más detalladas. Debido a que no tenemos muchos detalles en este punto, ingresamos las características principales como epopeyas en la pestaña Backlog/User Stories. Luego, para cada épica, ingresamos la cantidad de horas que las pymes y los líderes de desarrollo sugirieron para cada pila de desarrollo en función de la tabla de tallas de camisetas en la pestaña Parámetros.

Primero, seleccione la columna "¿EPIC?" y asegúrese de que solo esté seleccionado "Épico".

Luego, escriba la descripción épica e ingrese la cantidad de horas para cada columna de la pila de desarrollo. Por ejemplo, la épica "Conexión e inicio de sesión seguros" llevará alrededor de ocho horas de desarrollo de la interfaz de usuario, 40 para el back-end, y así sucesivamente.

Tenga en cuenta que, en la mayoría de los casos, las celdas de la columna "Punto" muestran "34*". Si regresa a la pestaña Parámetros, verá que 34 puntos corresponden a un rango horario entre 33 y 48 horas. Esa cantidad de horas es demasiado grande si la duración de nuestro sprint es de solo una semana.

Una vez que tengamos más detalles, será necesario reducir estas horas o dividir las épicas en historias más manejables. Sin embargo, por razones de tiempo, ignoraremos la columna Puntos y continuaremos con la estimación aproximada.

Ahora vaya a la pestaña Resumen de estimación por lanzamiento. En la parte superior de la hoja de cálculo, verá los valores de "Gastos generales" y "Contingencia" tal como se definen en la pestaña Parámetros. También hay un botón que puede seleccionar para mostrar estimaciones por épicas o historias de usuarios.

Debido a que aún no tenemos historias de usuarios para mostrar, marque el botón "Modo épico".

Ahora puede ver el costo aproximado y los plazos para el MVP y las funciones y actualizaciones menos urgentes en futuras versiones (R3 y R4). En este ejemplo, la segunda versión (R2) está vacía porque el cliente ha solicitado que todas las épicas de MVP se lancen en la primera versión.

Ahora puede ver el costo agregado más optimista: $28,810. Esta cifra es la suma del costo de cada lanzamiento desde el MVP hasta el R4.

También tenemos una estimación del cronograma más corto para la entrega del producto, que corresponde a la última fecha de finalización en la pila de desarrollo R4. Los gerentes de proyecto llaman a estas pilas de desarrollo más lentas "caminos críticos" porque dictan la velocidad de todo el lanzamiento.

En este caso, la ruta crítica es el desarrollo front-end, con fecha de finalización el 31 de enero.

Ahora es el momento de ajustar los parámetros para simular el presupuesto del peor de los casos y la línea de tiempo más larga.

Ajustar la Contingencia al 50%

Todavía sabemos relativamente poco sobre los requisitos de esfuerzo y experiencia para el producto, por lo que agregaremos una contingencia de ROM del 50 % en la pestaña Parámetros. La contingencia irá disminuyendo a medida que conozcamos más detalles sobre el proyecto.

Una vez más, aquí está la estimación total del proyecto al 0% de contingencia.

Y aquí está al 50% de contingencia.

Eso significa que la estimación de ROM para todo el proyecto está entre $ 28,810 y $ 41,860. En el mejor y el peor de los casos, el presupuesto de $20,000 del cliente no será suficiente para incluir todas las funciones en su lista de deseos.

La fecha de finalización total del proyecto al 50 % de contingencia ahora cae el 14 de marzo, seis semanas después de la fecha de finalización del 0 % de contingencia.

Mientras tanto, el MVP estará listo el 10 de enero.

En lugar de abandonar el proyecto, el cliente solicita un presupuesto más detallado para ver si podría acercarse más a su presupuesto objetivo en un plazo más corto.

Repriorizar para cumplir con los plazos

Suponga que el cliente establece una fecha objetivo del 25 de diciembre para el MVP, dos meses después del inicio del 25 de octubre.

Para adelantar la fecha actual de finalización de MVP del 10 de enero, el cliente acordó retrasar dos épicas de MVP hasta el próximo lanzamiento (R2).

La hoja de cálculo calcula el efecto cascada de este ajuste. En este caso, el cronograma de MVP se acorta hasta el 27 de diciembre. El desarrollo de front-end y back-end son las rutas críticas en esta simulación porque tomarán más tiempo en completarse.

En función de esta información, puede decidir agregar otros dos desarrolladores para alinear las fechas de finalización de front-end y back-end con las otras pilas de desarrollo. Para hacer esto, aumente las horas de 40 a 80 en la fila "Horas por semana" de MVP.

Las pilas de desarrollo de front-end y back-end finalizan ahora en noviembre, y el control de calidad se convierte en la nueva ruta crítica (con una fecha de finalización del 20 de diciembre). Tenga en cuenta que el costo no cambia. Eso es porque el total de horas de trabajo en cada pila sigue siendo el mismo. En lugar de que un desarrollador trabaje durante dos semanas (80 horas), dos desarrolladores trabajan durante una semana (80 horas).

La hoja de cálculo también tiene en cuenta las diferencias entre el trabajo a tiempo completo y el de medio tiempo. Supongamos que el desarrollador de la interfaz de usuario trabajará a tiempo parcial. Podemos cambiar la interfaz de usuario "Horas de diseño por semana" a 20 para simular el retraso en la entrega.

En un horario de tiempo completo, UX/UI estará completo el 29 de noviembre.

En un horario de medio tiempo, UX/UI estará completo el 27 de diciembre.

Una vez más, el costo no cambia, pero UX/UI se convierte en la nueva ruta crítica, extendiendo la línea de tiempo para el MVP hasta el 27 de diciembre.

Puede continuar con este enfoque de prueba y error hasta que llegue a una ruta crítica aceptable según sus recursos y la fecha límite del cliente. Una vez que se establece una fecha límite adecuada, es hora de comenzar a ajustar su estimación.

Refine su estimación con historias de usuarios

Debido a que la estimación de contingencia del 50 % quedó fuera del presupuesto del cliente, vale la pena refinar sus variables para que pueda reducir la contingencia y obtener una estimación más realista.

Para hacer esto, trabaje con sus desarrolladores y pymes para dividir sus épicas en historias de usuario detalladas. Las historias están mejor definidas que las épicas, por lo que podemos dimensionarlas con mayor precisión.

A continuación, ajuste los valores en la pestaña Parámetros en función de cualquier información nueva. Por ejemplo, su PYME y su equipo de desarrollo pueden tener un conjunto de tarifas más preciso para cada función y también pueden querer ajustar las tallas de las camisetas y las asignaciones de puntos. Con esos nuevos parámetros implementados, puede tener mayor confianza en sus cálculos y reducir la contingencia al 25%.

Veamos cómo dividimos las epopeyas en historias de usuarios más pequeñas y detalladas:

A diferencia de la estimación épica que requería ingresar manualmente las horas estimadas para cada pila, la estimación de la historia usa el tamaño de la camiseta como atajo. Aquí es donde los tamaños de camiseta que ingresó en la pestaña Parámetros son útiles.

En "T-shirt Sizing" en la pestaña Backlog/User Stories, ingresa la combinación de tallas que tus desarrolladores y PyMEs asignaron a sus stacks para cada historia. A partir de ahí, la fórmula de la hoja de cálculo completará automáticamente las horas correspondientes desde la pestaña Parámetros. Recuerda que el tamaño más grande, LL, debe permanecer por debajo de los 34 puntos para garantizar que se pueda completar dentro de la duración del sprint acordada. Cualquier historia que aún califique 34 puntos o más deberá subdividirse.

Una vez que se haya asegurado de que se asignan menos de 34 puntos a todas las historias, desmarque el botón "Modo épico" en la pestaña Resumen estimado por lanzamiento para ver solo "Historia".

Ahora verás un nuevo conjunto de números:

Después de detallar todas las tareas y ceñirse únicamente a las características de MVP, el cronograma y el costo ahora coinciden con los requisitos del cliente. Dado que el saldo está dentro de su presupuesto, el cliente decide continuar con el MVP y probarlo antes de comprometerse con lanzamientos adicionales.

Haz lo tuyo

Las hojas de cálculo son fáciles de usar y, con algunos conocimientos básicos de fórmulas (no se necesitan macros), puede adaptarlas a casi cualquier necesidad. Si su conocimiento de Excel está oxidado, los cursos en línea en Udemy y edX lo ayudarán a repasar estas habilidades.

Este artículo cubrió la estimación de descubrimiento, pero puede usar la misma hoja de cálculo para generar gráficos de avance y avance, ajustar cronogramas y calcular estimaciones en función de la velocidad y los sprints para etapas posteriores. Uso mis hojas de cálculo personalizadas para complementar aplicaciones, como Jira, Asana y Trello, y mantengo que son una herramienta poderosa en mi kit de gestión de proyectos. Espero que te resulten igual de útiles y versátiles.

¿Prefiere las hojas de cálculo personalizadas a las herramientas de gestión de proyectos listas para usar? Cuéntanos por qué o por qué no en los comentarios.