¿Cómo luce la EDT para un proyecto Ágil / Scrum?

Hola a todos

Cuando desde la gerencia de proyectos tradicional (PMP) nos enfrentamos a un proyecto ágil creemos que todo encaja y que podemos emplear los mismos artefactos, entregables y estrategias para ambos tipos de proyectos, esta aproximación nos lleva "gerenciar" de forma equivocada y en consecuencia a fallar, es necesario reconocer que gerenciar un proyecto tradicional o de gestión predictiva es diferente a gerenciar un proyecto adaptativo - como son los ágiles, y en especial los que adoptan scrum como marco de trabajo-. En este post quiero compartirles la diferencia entre una EDT tradicional y una EDT ágil (si es que se le puede decir así)

Comencemos

Recordemos que la línea base del alcance para proyectos tradicionales esta constituida por tres artefactos.

• Enunciado del Alcance
• EDT (esquema de desglose de trabajo) (1)
• Diccionario de la EDT

Donde la EDT reflejará TODO Y SOLO TODO EL ALCANCE A SER CONSTRUIDO. A continuación presento un ejemplo de una EDT correspondiente a un proyecto de software tipo RUP con alcance fijo.

EDT de un proyecto de software realizado empleando RUP

Y justo en la palabra alcance es donde comienza la fricción entre tradicional y ágil, pues en software nos interesa es generar valor, no alcance, y es probable que la solución encuentre el resultado esperado del negocio antes (o después (2)) de haber construido todo el alcance planteado

Diferencia entre tradicional y Scrum

Aun así, si de obstinados fuéramos a realizar la EDT del proyecto en Scrum  resultaría en algo como:

EDT de un Proyecto en Scrum

Y la fracción a correspondiente correspondiente a cada sprint sería similar a la siguiente imagen

EDT correspondiente al Sprint 1

Donde, para acabar de ajustar no tenemos certidumbre sobre:

• si el producto en cuestión requerirá todos estos releases
• o si un release requerirá todos los sprints planteados
• o si un sprint contendrá todos las historias planeadas pues la continua repriorización del backlog no nos permite predecirlo(3)

Es por tanto que en un artefacto como la EDT no quedaría registrado todo el alcance a ser construido y podría llegar a verse de la siguiente manera

Propuesta de EDT para proyectos Scrum

Este artefacto - la EDT - , como vemos. se queda corto para la gestión del valor y del alcance del proyecto scrum, es por eso que para este tipo de proyectos se emplean otro tipo de herramientas para la gestión del alcance y por ende del Product Backlog (que es en donde reside el alcance y el valor del producto y del proyecto), una de esas herramientas es el mapa de historias de usuario (user story map), el cual permite:

• Identificar y gestionar los releases
• Identificar y repriorizar las historias épicas a construir
• Visualizar los objetivos de negocio a cumplir

Para saber más del User Story Map  hacer clic aquí.

La "EDT" podría verse así:

"EDT" Proyecto Ágil considerando un MVP y varios Releases (en negro están los elementos con incertidumbre a ser construidos)

Nota importante: Para complementar el entendimiento de cómo se construye un "proyecto" o mejor un producto ágil te sugiero estos dos post:

• Un ejemplo sobre: Épicas, MVP, Historias de Usuario, Agregar Valor Incrementalmente y Agregar Valor - clic aquí -
• De Colección: De la Idea hasta las Historias de Usuario del Sprint Backlog - Un Ejemplo Completo - clic aquí -

Bueno hasta acá esta disertación y lo que quería compartirles, bienvenido el feedback.

Saludos ágiles

Jorge Abad

Notas, Aclaraciones, Comentarios y Referencias

1. También conocida como WBS - Work Breakdown Structure - en inglés
2. Dependiendo del product owner.
3. La constante repriorización agotaría cualquier gestión rigida del proceso de control de cambios.

Elaborando el Plan de Mejora: Obteniendo la Pila del Producto (Product Backlog) o Alcance.

Cuando las organizaciones deciden comenzar un plan de mejora con miras a cumplir alguna normatividad o alguna meta planteada, sugiero se sigan los siguientes pasos con el objeto de construir lo que se va a realizar de una manera eficiente y de alto valor:

1. Identificar la meta a cumplir (TO-BE) (DEBER SER)

Consiste en decidir que se va a cumplir, hacia que meta se está apuntando ya sea:

• cumplir una norma, conjunto de normas y/o estándares
• lograr algún / algunos objetivos organizacionales

Tabla 1. Aspectos de la norma o mejora.

2. Identificar el estado actual de la organización respecto al objetivo (AS-IS) (COMO ES ACTUALMENTE)

Respecto a cada aspecto a mejorar se debe identificar el valor evaluado y el cumplimiento del mismo.

Tabla 2. Estado Actual vs la  Norma o Mejora

3. Identificar el GAP (diferencia) entre la norma (o mejora) y el estado actual

Tabla 3. Análisis GAP

Nota: Pueden existir aspectos que se cumplen en los cuales no existe GAP.

4. Calificar el estado del GAP

De acuerdo al resultado del GAP, se puede calificar el estado en que se encuentra el cumplimiento del aspecto a mejorar, se sugiere una calificación con la siguiente escala:

1. no re realiza

2. se realiza con deficiencias

3. se realiza satisfactoriamente

4. se realiza  sobresalientemente

Tabla 4. Calificación del estado actual vs la Norma o Mejora

5. Determinar la calificación objetivo

Para cada aspecto se debe determinar el valor objetivo a alcanzar. Existen casos en los que las organizaciones no están satisfechas con cumplir la norma, estándar o mejora propuesta, sino que quieren ir más allá, de igual forma pueden existir aspectos en los cuales no hay interés de avanzar o mejorar debido a razones económicas, técnicas, jurídicas, ambientales, etc.

Tabla 5. Valor deseado de calificación respecto a la norma o mejora.

6. Identificar las mejoras a realizar

Determine cuales son las mejoras que va a realizar. Es probable que una mejora soporte varios aspectos.

Tabla 6. Mejoras a realizar respecto a cada aspecto de la norma o mejora

6. Califique las Mejoras

A cada mejora realícele una calificación ya sea por:

• mayor impacto menor esfuerzo
• menor valor
• mayor ROI (Retorno de inversión) en el corto plazo
• mayor ROI en el mediano plazo 
• etc.

El ejemplo muestra una calificación de 1 a 4 para el concepto "mayor impacto - menor esfuerzo" (para esto se puede realizar un taller donde los involucrados en el proyecto de mejora califiquen cada mejora de acuerdo a parámetros establecidos)

Tabla 7. Mejoras Calificadas de acuerdo a su Mayor impacto-Menor Esfuerzo

Ordene de acuerdo a la calificación

Tabla 8. Mejora Calificada

Y de acuerdo a su criterio o al criterio de expertos priorice, recuerde que siempre existirá una mejora más importante que otra, por lo tanto no permita que queden dos o más con la misma prioridad.

Tabla 9. Mejora Priorizada

Con esta última tabla ya se tiene el Product Backlog / Pila de Producto (listado de necesidades) de lo que se desea realizar. Esta pila de producto o ítemes del proyecto de mejora se puede ejecutar empleando SCRUM -Ver guía acá- ( el cual es un marco de trabajo para ejecución de proyectos -construcción de productos- de forma iterativa e incremental en ciclos cortos para escenarios adaptativos complejos.)

Si se desea también este es el insumo para la EDT - Estructura de Desglose de Trabajo - (WBS -  work breakdown structure. ) en el esquema tradicional de gestión de proyectos en el cual la EDT es la pieza clave (es la definición del alcance) para la elaboración del cronograma.

---

Siguiendo la sugierencia de Lucho Salazar (bloguero de gazafatonarioit ) realizo la siguiente adición:

7. Califique las Mejoras considerando la criticidad

Adicional al criterio del punto anterior (ROI, rentabilidad o impacto, etc) se puede adicionar la columna de criticidad, pues hay unas mejoras que son más criticas que otras en un proceso de mejora. Bajo este criterio la tabla 7 quedaría de la siguiente forma:

Tabla 10. Mejora con criticidad asignada

Por lo tanto reorganizando, el listado de mejoras a realizar teniendo como primer criterio de ordenamiento la criticidad y segundo el impacto, la Pila de Producto (Product Backlog) de la mejora quedaría:

Tabla 11.  Mejora priorizada por los criterios de criticidad e impacto.

.