¿Qué ocurre con la velocidad del equipo cuando las horas estimadas de una historia de usuario son inferiores a la suma de las horas estimadas en las tareas correspondientes de la pila de sprint?

Este es un tema alrededor del cual suele producirse confusión. Aunque lo que estimamos es esfuerzo y no tiempo, la unidad "horas ideales" la asociamos inconscientemente al tiempo.

Para ilustrarlo veamos el siguiente ejemplo: Un historia de usuario estimada en 20 horas se ha descompuesto en la reunión de planificación del sprint en una tarea de 8, otra de 10 y otra de 4 horas. Sumando las tareas vemos que necesitaremos 22 horas, y suponiendo que solo realizamos esa historia de usuario en ese sprint, nos preguntamos si la velocidad del equipo es 20 o 22.

Fijaros que la estimación de la historia de usuario probablemente la hayamos realizado en unos pocos minutos, seguramente con estimación de póquer, mientras que las estimaciones de las tareas las hemos trabajado y pensado en profundidad. Simplemente no podemos comparar unas horas con las otras, sería como comparar manzanas con peras.

Por tanto la velocidad del ejemplo anterior es 20h/sprint, aunque se estimen 22 horas ideales para desarrollar las tareas.

Ahora cambiamos de escenario, en vez de la estimación de 20 horas, estimamos la historia de usuario en 5 puntos de historia. ¿A que ahora no hay duda de que la velocidad es de 5 puntos de historia/sprint? Recordad que las tareas de la pila de sprint siempre se estiman en horas, por tanto aquí tenemos una buena razón para medir el esfuerzo de la pila de producto en una unidad diferente a horas.

Las consecuencias de confusión en este tema pueden ser nefastas para un proyecto. Nuestra historia tiene un tamaño en esfuerzo de 20 horas, como hay cierta confusión pensamos que nuestra velocidad es de 22 horas/sprint, y por tanto cuando hagamos la siguiente reunión de planificación de sprint seleccionaremos historias por esas 22 horas... cuando realmente nuestra velocidad en horas de pila de producto es de 20. Tomaríamos la decisión equivocada de incluir la historia 3 del ejemplo anterior en el segundo sprint. La buena noticia es que al cabo de 2/3 sprints cualquier equipo se daría cuenta de ello y tomaría las medidas adecuadas.

Recordad, la velocidad siempre se ha de basar en, y solo en, las estimaciones de la pila de producto.

¿Dónde encaja el testing en proyectos de TI con Scrum?

Testing OK

Recordemos que los incrementos solo están finalizados si los desarrollos están acabados, probados y documentados tal y como se ha recogido en la definición de hecho (DoD), y eso implica que sea el propio equipo el que realice el testing y el control de calidad. En el equipo puede haber perfectamente un rol de tester, y de no haberlo, recordemos que se trata de equipos multidisciplinares y que en su conjunto, y si han sido formados, pueden tener perfectamente las habilidades y la independencia de un tester.

Scrum no es un modelo que ha surgido de arriba a abajo: de la teoría a la práctica, sino al revés: ha tomado forma y cuajado desde las prácticas empleadas por algunos equipos como antítesis a los modelos de procesos. Esto tiene sus ventajas y sus inconvenientes: no es un modelo diseñado para cubrir todas las áreas al estilo de una ISO 12207 o un modelo de procesos tipo CMMI o ISO 15504. Por esta razón, no hay un procedimiento (ni debería haberlo) para prescribir cómo hacer testing (dentro del área de SQA). Si existen una serie de patrones de testing que son más o menos cercanos a la Agilidad, mi más ferviente recomendación es la integración continua y las pruebas automatizadas.

Si a pesar de ello se requiriese de un procedimiento de calidad institucionalizado, el que resultaría válido para proyectos con niveles de integridad bajo correspondería al control de calidad considerado de independencia mínima (estándar IEEE 1012). Para proyectos con niveles de integridad elevado puede (debería) resultar aconsejable emplear modelos de mayor independencia. A quien interese puede encontrar un desarrollo en ese sentido en el artículo Scrum y aseguramiento de calidad.

¿Se puede aplicar Scrum en un proyecto con un equipo de 2/3 personas?

Realmente lo que me preguntaba el jefe de proyecto, uno de mis alumnos, era si Scrum es aplicable a pymes con un equipos de 2/3 personas y a proyectos pequeños.

Reunión diaria de un equipo de dos

En un equipo pequeño la dinámica de grupos es muy leve, ya que esta se da generalmente en equipos a partir de 3 personas, por tanto hay menos interacción entre personas distintas, menos diversidad y menos probabilidad de que surjan buenas ideas o golpes de inspiración. Por otro lado un equipo pequeño tiene sus riesgos, ya que tiene un bus factor muy bajo, si un miembro enferma o se va del equipo, este se ve seriamente afectado, lo que impacta fuertemente en las fechas de entrega o en la calidad por la pérdida de conocimiento.

Pero como todo en Agilidad, depende de lo adaptado que esté la empresa a Scrum. Si el equipo de 2/3 personas tiene todos los roles y habilidades necesarias, por tanto es multidisciplinar en la medida justa para sacar adelante el incremento del sprint, entonces perfecto, la empresa es ágil y aplica Scrum en su medida.

En un equipo pequeño la interacción con el cliente/usuario suele ser muy fuerte, el nivel de comunicación y cercanía que tienen proyectos pequeños hace que en cuanto aparezca un problema no se tarde más de unas horas en sacar la solución a producción, lo mismo ocurre con cualquier cambio pequeño.

Por otro lado el entorno suele dejar vía libre para que el equipo se pueda autoorganizar y saque el trabajo a buen ritmo. La parte de negocio marca la dirección a seguir y a la vez da mucha capacidad de decisión al equipo, y como todo suele funcionar bien, nadie empuja para tener resultados para ayer... lo que ocurre es que el propio equipo termina empujando de vez en cuando para tener las cosas cuanto antes.

También suelen ser equipos que no tienen kilos de "papel" acumulados ni procedimientos megalíticos a seguir, se basan en el conocimiento de las personas, hacen la documentación justa y sus procedimientos emergen de ellos mismos.

Uno de mis jefes me decía que antes de aplicar Scrum, ya lo hacíamos, hacíamos la reunión diaria cuando los jefes de proyecto nos sentábamos diariamente con el equipo para hablar de la situación de proyecto y decidíamos en equipo que haría cada uno. Aunque no es lo mismo, ejercíamos "Scrum" y no lo sabíamos. Pienso que las pymes al ser pequeñas, y habiendo rodado sus equipos, pueden acabar aplicando "Agilidad" de forma intuitiva y emergente.

¿Cuál es la unidad de tiempo empleada en Scrum técnico para calcular la velocidad del equipo?

Fórmula de la velocidad en Scrum

La velocidad del equipo es la magnitud determinada por la media de la cantidad de trabajo o esfuerzo completada (terminada y entregada) en un periodo de tiempo, y en Scrum técnico es la media de la cantidad de trabajo realizada por el equipo en los sprints.

La fórmula de la velocidad es la que vemos en la imagen de la derecha, la unidad de trabajo en el dividendo y la unidad de tiempo en el divisor.

En equipos maduros, que ya hayan transicionado a Scrum avanzado, puede darse el caso de que se realicen sprints de diferentes duraciones o con un número de miembros variable en el equipo. En ese caso, para poder tener una medida independiente, se puede expresar la velocidad refiriéndose a la media por persona, por ejemplo: "La velocidad media de una persona del equipo es de 5 puntos por día".

¿Cómo han de ser las personas que integran los equipos de trabajo?

Uno de los motivos que en un primer momento crea confusión es cuando les digo a mis alumnos que el equipo ha de ser multifuncional, cada persona ha de estar abierta a hacer de todo. Ocurre que suelen asociar esa afirmación a que todos hacen de todo y que no son necesarios los especialistas, y luego viene la inevitable pregunta ¿cómo puede funcionar sin especialistas?

Representación de las dos características

Hay dos características en las personas que están más o menos desarrolladas según cada persona. Tim Brown introdujo en 2009 el concepto de "t-shaped person", persona tipo "T", en que utilizando la letra "T" se representan dos características de la persona. La vertical representa la profundidad del expertise y habilidades en un campo concreto y trabajado (programador java, DBA Oracle, arquitecto funcional...), y en la horizontal el interés que tiene la persona por lo que le rodea y la disposición a colaborar en otras disciplinas, es la dimensión de aptitudes en las que no es experto pero puede ayudar.

Las personas de tipo "T" tienen ambas características, son especialistas en su campo y tienen una alta empatía que les ayuda a ver y a imaginar problemas desde otras perspectivas y así poder contribuir con su opinión en áreas en las que a priori no son expertos, y tienden a ser personas muy entusiastas y curiosas que se interesan por los campos de los demás y sienten el impulso de aprender y colaborar. Este es el tipo de persona ideal para formar cualquier tipo de equipo, sea ágil o no.

Normalmente las empresas tienen personas con diferentes profundidades en las dos características. Cuando un equipo formado por personas que en su mayoría tienen básicamente habilidades verticales, personas tipo "I", se suelen producir dificultades en la colaboración. Cada uno solo aporta el punto de vista que deriva de su especialidad y las reuniones se convierten en negociaciones en las que se busca más ser "ganador" que una solución al tema planteado.

Scrum, y la Agilidad en general, promueven la conversión a personas tipo "T", pero deben estar abiertas al cambio cultural que implica. Si tienes un equipo lleno de personas tipo "T" ya no necesitas supervisores, facilitadores y controladores, todo el mundo hace esas funciones en alguna medida, colaboran por ellos mismos allí donde más aportan.

Aquí os dejo una comparativa entre tipos "I" y "T":

Tipo "I" versus "T"

---

Cortesía
Clipartbest

Mencionar que también existen otros tipos como por ejemplo personas tipo "π" (Pi): personas con profundidad en dos especialidades, una primaria y otra secundaria. Las mayoría de personas tenemos la habilidad de manejarnos con dos especialidades, a veces un cambio profesional puede convertirnos en personas tipo "π", especialistas secundarios en nuestro pasado como de un buen jefe de proyecto, y especialistas primarios en la profesión actual como de un buen Scrum Master.

Cortesía
Pixabay

Las personas tipo "M" tienen múltiples conocimientos en sus campos o disciplinas, por tanto tienen múltiples especialidades. La profundidad de cada especialidad resulta en el mismo conocimiento o más que se espera de la misma especialidad de una persona tipo "T". Por tanto son personas más flexibles y competentes que alguien con una sola especialidad, el conocimiento práctico a lo largo de sus especialidades les permite trabajar mucho más rápido y garantizar un estándar de trabajo constante. Por ejemplo una persona con expertise como programador/codificador, diseñador gráfico y redactor será la persona ideal para crear sitios web de alta calidad. Las personas tipo "M" son en realidad miembros de equipos multifuncionales de alto rendimiento.

Cortesía
Pixabay

Luego están las personas tipo "E", que son personas que combinan expertise, experiencia, ejecución y exploración: expertise muy profundo en pocas áreas, experiencia en varias áreas, con habilidades de ejecución probadas y mentes exploradoras que siempre están innovando. Ponen mucho énfasis en la ejecución, son personas que llevan las ideas a la realidad. Las personas tipo "E", que estén dispuestas a explorar para satisfacer su curiosidad y a arriesgarse para ejecutar sus ideas e innovar, son las que tienen gran demanda para formar parte de equipos ágiles.

Cortesía
Pixabay

Finalmente las personas tipo "X", son aquellas que tienen un gran expertise basado en una sólida credibilidad, y que suelen liderar diversos equipos para lograr un objetivo. Suelen trabajar cada vez menos en su expertise original a medida que evolucionan hacia posiciones gerenciales y de liderazgo. Por lo general estas personas tienden a centrarse en la estrategia y en el desarrollo profesional de personas y equipos. En realidad la profundidad de su expertise es menos importante que su inteligencia emocional y sus cualidades de liderazgo.

¿Cuál es el mejor soporte para escribir las historias de usuario?

Como en todo lo referente a Agilidad el mejor formato es el que se adecua al equipo/proyecto/empresa. Si el equipo es distribuido, el formato ha de ser digital, igual que el tablero kanban. Pero en este post hablamos de equipos locales con tableros kanban físicos.

El formato ha de ser el que le resulte más cómodo y útil al Propietario del Producto para la organización y gestión de su pila de producto. Algunos Propietarios de Producto gestionan su pila digitalmente, con un excel, por ejemplo. Otros tienen su propio tablero kanban con su propio flujo de trabajo y por tanto tienen sus historias de usuario escritas en post-its o tarjetas.

Utilizar post-its es muy ágil, pero cuando los campos de las historias de usuario que tratamos siempre, o casi siempre, son los mismos, vale la pena utilizar tarjetas preimpresas, ya que nos ahorramos escribir los nombres de los campos y aumenta la sensación de orden (Algunos escribimos como los médicos y así al menos se sabe de qué trata lo que hemos escrito :-P).

Googleando me encontré una empresa americana, Braintrust, que ha diseñado sus propias tarjetas, muy bien diseñadas, con los campos recomendables y que adicionalmente dan un look profesional. Están preparadas para que se escriba la historia con el patrón "Como [rol del usuario], quiero [objetivo], para poder [beneficio]" y la aplicación del método de aseguramiento de calidad INVEST.

Aquí os dejo una imagen de las tarjetas, a mi me encantan...

Tarjetas para historias de usuario de Braintrust

¿Cuál es la diferencia entre valor, prioridad y orden en la pila de producto?

Uno de mis alumnos, un jefe de proyecto PMP, participó en el curso de forma muy proactiva y llegados a la pila de producto no entendía la diferencia entre prioridad y orden, y le dimos bastantes vueltas al tema...

El campo prioridad es uno de los que se consideran necesarios en las historias de usuario y se podría definir como un sistema de priorización que nos permite determinar el orden en el que las historias de usuario deben de ser implementadas.

El campo valor, normalmente numérico, representa el valor de negocio que la historia de usuario aporta al cliente o usuario. El objetivo del equipo es maximizar el valor y la satisfacción percibida por el cliente en cada sprint. Este campo servirá junto con la estimación del esfuerzo, que mide una mezcla de tamaño y complejidad técnica de la historia, para determinar la prioridad con el que las historias deben de ser implementadas.

Una forma para el Propietario del Producto de guiarse y determinar la prioridad es a través del ROI, la división del valor por el esfuerzo. Además en base al ROI obtenido podrá preguntarse si vale la pena construir una historia de usuario, o si hay varias opciones podrá decidir la mejor opción teniendo en cuenta la perspectiva económica.

El orden representa la urgencia de una historia, deriva de la prioridad que fuerza al Propietario del Producto o cliente a refinar el entendimiento de la pila de producto: solo puede haber una sola historia siguiente más importante. Resaltar que si mostramos las historias de usuario en formato de lista, la columna orden resulta claramente necesaria para cuando valor y esfuerzo de diferentes historias resultan en el mismo valor de prioridad.

Relación entre valor, prioridad y orden

Comentario en off: tengo de la absoluta convicción de que cualquier lista, desplegable, listado, select... deben de estar ordenados, por el criterio que sea, pero siempre estar ordenados.