Buscar en Gazafatonario IT

Mostrando las entradas con la etiqueta Empirismo. Mostrar todas las entradas
Mostrando las entradas con la etiqueta Empirismo. Mostrar todas las entradas

miércoles, febrero 16, 2022

Nuestro Scrum empírico de todos los días

Imagen tomada de Pixabay

“El verdadero método de conocimiento es el experimento”.

-          [William Blake. Poeta, pintor y grabador inglés.]

Muchos dicen usar Scrum, dicen usarlo bien. Según los “lineamientos” ágiles, los he escuchado decir. Pero he aquí una observación: la gran mayoría quizás ni lo están haciendo, a pesar de los eventos, las responsabilidades y los artefactos. En general a casi todos les hace falta lo que llamo “el espíritu de Scrum”. Ese que tiene que ver con la teoría del marco de trabajo, con sus pilares y con sus valores.

Me concentraré específicamente en la teoría. En esa que nos dice que Scrum se basa en el empirismo y en el pensamiento Lean. De hecho, mi foco será esto del empirismo. Para empezar, es bueno reconocer que un entorno empírico es aquel en el que la mejora y la dirección están guiadas por los experimentos y la experiencia.

Esta última se basa en lo que ya ha ocurrido, en el pasado. Muchos siguen usando Scrum tratando de predecir lo que va a pasar en el futuro, a veces incluso, en un futuro distante. Nada más alejado de las prácticas erróneas. Mi primera recomendación: usa la experiencia para experimentar con la planificación en el muy corto plazo, la planificación de un sprint; es más, con la planificación de un día de trabajo.

Para hacerlo, haz que tu equipo planifique teniendo en cuenta lo que pasó en el último sprint. Quizás en los tres últimos. Tampoco te vayas tan atrás. Seguramente hay cosas que han cambiado en el entorno. No es lo mismo si hace unas semanas tu equipo estaba disperso por el mundo y apenas si lograbas identificar un icono en una pantalla de alguna de las herramientas favoritas de comunicación, a si en este momento están trabajando con un modelo “híbrido” o presencial del todo. Mientras escribo esto, algunas empresas ya lo están intentando.

Promueve un entorno donde todos en el equipo y los interesados clave, además de los usuarios, esperen lo inesperado. Es lo que sucede cuando trabajas bajo el manto de la incertidumbre y la volatilidad inherentes a los escenarios que enfrentas habitualmente, sin hablar de la complejidad propia del ADN de las iniciativas con las que convives a diario. Es en estos escenarios donde un proceso empírico tiene vigor.

La realidad del Scrum que haces

Photo by Yan Krukov from Pexels
Todo el tiempo escuchas decir:

La mejor duración de sprint es de dos semanas. Pero ¿has experimentado con otra duración? ¿Una mejor, por ejemplo?

En nuestras Daily Scrum seguimos usando las “tres preguntas”. Nos parecen muy buenas. Sí, pero ¿has experimentado con otro tipo de conversaciones?

Nuestra definición de terminado es muy completa. Pero ¿la has mejorado con el tiempo?

En cada sprint implementamos entre 4 y 8 historias de usuario. Pero ¿has experimentado con otros rangos?

Nos funciona bien un equipo de 8 personas. Pero ¿has ensayado con otro tamaño de equipo?

Te haré otras preguntas:

¿Has dejado de usar la velocidad como medida de capacidad para el equipo?

¿Sigues usando puntos de historia para estimar las historias de usuario?

¿Has intentado con tu Product Owner alguna técnica distinta a MoSCoW para ordenar el Product Backlog? ¿Has usado MoSCoW?

¿En realidad todos en el equipo y en el entorno, es decir, interesados clave, patrocinadores y usuarios, entre otros, comparten no solo la misma información sobre lo que está sucediendo, sino el mismo significado de las cosas?

¿Has experimentado o has promovido cambios en la forma como hacen la planificación del sprint, el refinamiento, la revisión o la misma retrospectiva? Sobre esta última, ¿te limitas a los “pasos” generados por Retromat, Fun retrospectives o el muy buen libro sobre el tema de mi gran amigo Jorge Abad, pero nunca has intentado crear tu propia retrospectiva, más adecuada a las necesidades de tu equipo en un momento dado?

Finalmente, ¿te basas y promueves que el equipo y la organización se basen en lo que ya ha sucedido, datos cuantitativos, sobre todo, para tomar decisiones sobre qué hacer y cómo hacerlo en el futuro inmediato?

Algo del Scrum que deberías estar haciendo

Photo by fauxels from Pexels

¿Y por qué todo este cuestionamiento?

Bueno, precisamente porque Scrum es útil en un entorno donde la experimentación debe(ría) estar a la orden del día. Como dije al principio, a eso se refieren Schwaber y Sutherland cuando dicen que Scrum se basa, además del pensamiento Lean, en el empirismo. Este último “afirma que el conocimiento proviene de la experiencia y de la toma de decisiones con base en lo observado”.

Por ejemplo, no te desgastes mucho, ni entretengas a tu equipo haciendo estimaciones, aunque sean “ágiles”, en el primer sprint. Simplemente empieza. Al final del primer sprint tendrás un dato verificable de cuánto hizo el equipo. De inmediato, en el segundo sprint, toma la decisión de que la velocidad del equipo sea justamente el número de puntos que acaban de lograr en el sprint anterior. De hecho, esto es un patrón Scrum conocido como El clima de ayer.

Ahora bien, los experimentos no tienen que proponer cambios sustanciales a lo que se está haciendo. Puedes usar mejoramiento continuo de un paso a la vez, crea una expectativa de experimentación y mejora bastante baja, de tal forma que para nadie sea una carga impositiva sino más bien un camino a transitar, desafiante pero divertido. Eso sí, primero enséñales a todos a mejorar, a proponer esos experimentos que tanto quieres.

Por ejemplo, enséñales a prepararse para una Daily Scrum.

Puedo contar por centenares las reuniones diarias a las que he asistido con personas que van muy mal preparadas a la misma. Todo el tiempo están titubeando, desenfocados, desmotivados y mirando el reloj a que simplemente terminen los infames 15 minutos de la reunión porque saben que eso sí lo van a respetar. Una de las principales razones que he encontrado para que esto suceda es que es una sesión subvalorada, a la que le dan poca o ninguna importancia, porque no terminan de entender qué significa la inspección y adaptación como pilares esenciales de un entorno empírico.

Lo he resuelto con entrenamiento, preparación y acompañamiento. Además de crear todo un movimiento cultural alrededor del evento:

1.    Al principio del sprint fijas una táctica o técnica para llevar a cabo la reunión.

2.    Les enseñas a todos en el equipo cómo será, haces una simulación. Llevas a cabo conversaciones de mejora para que cada uno llegue a conocer muy bien los detalles.

3.    Antes de las primeras sesiones, te aseguras de que todos efectivamente estén preparados. Indagas si necesitan ayuda para estarlo. Les proporcionas la ayuda que necesitan.

4.    Durante el evento estás atento a cómo lo llevan a cabo para, a continuación de este, mantener otras conversaciones de mejora y perfeccionar en consecuencia.

5.    Indaga cómo se sienten, qué les hace falta, qué quieren proponer.

6.    Precisamente sobre este último asunto, lo más importante es, enséñales a mejorar ese paso a la vez. Por ejemplo, enséñales con ejemplos claros a que cada vez digan más con menos palabras. Pero sin atribularlos.

Por sobre todas las cosas, siempre ten en cuenta lo que sucedió los días anteriores. Y haz que ellos en el equipo también lo tengan presente. No puedes encontrar nada de eso que sucedió en un cuerpo de conocimiento, mucho menos en la guía de Scrum. De hecho, Scrum se basa en la inteligencia colectiva de las personas que lo usan. Y es precisamente esa diversidad de perspectivas, una de las formas cómo enfrentamos la complejidad que nos rodea, lo que posibilita que encontremos soluciones más acertadas o apropiadas a los problemas que nos desafían cotidianamente.

Quieres saber más

Para saber más del Scrum que deberías estar haciendo, te invito a mi próximo curso para Scrum Masters. Encuentras toda la información de este en:

https://luchosalazar.com/portfolio/nuevo-curso-scrum-master/

Mientras tanto:

Para saber más de cómo mejorar la Daily Scrum:

http://www.gazafatonarioit.com/2022/01/como-ayudar-tu-equipo-mejorar-su-daily.html

https://luchosalazar.com/2021/04/23/daily-scrum-kaizen/

Para saber más sobre el clima de ayer y otros patrones Scrum:

https://luchosalazar.com/2020/05/21/patrones-scrum-un-enfoque-adaptativo/


Nuevo curso: Scrum Master

Es un hecho: la notoriedad de las prácticas ágiles para el desarrollo de productos ha crecido y sigue creciendo, hasta el punto de convertirse en ese oscuro objeto del deseo de las organizaciones, grandes y pequeñas, que han estado adoptándolos en distintos niveles. Típicamente, los enfoques de adopción se implementan vía Transformaciones Ágiles y la historia ha mostrado resultados mixtos: éxitos y fracasos de estas iniciativas de cambio. Las tácticas usadas y los métodos específicos seleccionados para la adopción varían ampliamente dependiendo del contexto.

Scrum es un marco de trabajo liviano que ayuda a las personas, equipos y organizaciones a generar valor a través de soluciones adaptativas para problemas complejos. Scrum ayuda a poner de manifiesto o en práctica los valores y principios que definen el pensamiento ágil y Lean a través de una serie de lineamientos simples pero efectivos que habilitan a las personas y equipos para ser más productivos mientras mantienen la energía y la motivación al hacer su trabajo.

Este curso permitirá al asistente adquirir y dominar los conceptos necesarios y suficientes para poner en uso el marco de trabajo Scrum y prácticas relacionadas en iniciativas de todo tipo. El curso contribuye a que los equipos y las organizaciones den un paso más en el mejoramiento continuo como corporaciones de alto desempeño y empiecen a mirar la transformación digital como una opción capital en tiempos de alta incertidumbre y complejidad.

Prerrequisitos del curso:

Este taller no tiene ningún prerrequisito. Sin embargo, se recomienda ampliamente:

·       Leer la guía de Scrum (http://www.scrumguides.org/download.html). Aquí la encuentran en original inglés y en muchos otros idiomas, incluyendo español. Buscar la línea “Spanish (South/Latin American) (November 2020))” y hacer clic allí para descargar.

·       Leer el Manifiesto Ágil (http://agilemanifesto.org/iso/es/manifesto.html)

Objetivos del curso:

Al finalizar este curso, el participante estará en capacidad de:

·       Conocer, interiorizar, practicar y empezar a promover los Valores y Principios del Manifiesto Ágil, qué significa ser Ágil y de qué se trata la Filosofía Ágil.

·       Adquirir el conocimiento básico de las prácticas Ágiles para desarrollo de productos y los aspectos fundamentales del marco de trabajo Scrum. Incluyendo las responsabilidades, los eventos y los artefactos propuestos por el marco de trabajo.

·       Entender varias técnicas para mitigar la incertidumbre y el riesgo de los proyectos aplicando valores y principios Ágiles.

·       Aplicar el marco de trabajo Scrum para conocer las necesidades en las operaciones específicas de los negocios.

·       Aumentar la transparencia, inspección y adaptación, pilares de Scrum, mediante la vivencia de los cinco valores de Scrum: coraje, foco, franqueza, apertura y compromiso.

Para quién es valioso este curso:

Este curso y certificación son apropiados para cualquier persona interesada en empezar a ejercer como Scrum Master, pero también que busque conocer los principios fundamentales de Scrum, que estén o vayan a participar en iniciativas ágiles con Scrum; también, y para interesados en las iniciativas y proyectos que están en la cadena de valor de proporcionar características o requisitos a los equipos de desarrollo de productos o servicios.

·       Gerentes o Líderes de producto

·       Dueños de Producto

·       Mercadeo de productos

·       Analistas del negocio

·       Analistas funcionales

·       Patrocinadores de los proyectos de desarrollo

También a las áreas de TI de la organización:

·       Líderes técnicos

·       Gerentes de Proyectos

·       Desarrolladores

·       Arquitectos de software

·       Analistas de Prueba

·       Diseñadores

·       Scrum Masters

·       Desarrolladores Scrum

·       Consultores Comerciales,

·       Consultores de Preventa de Proyectos

·       Líderes Funcionales de Áreas Usuarias de Software o similares

Entre otras personas interesadas en mejorar las interacciones de manera efectiva con los demás miembros del equipo y de su empresa mediante el uso de las prácticas propuestas por Scrum.

Contenido:

1.    Introducción Ágil

2.    Qué es Scrum

3.    Valores de Scrum

4.    Scrum Team

o   Product Owner

o   Developer

o   Scrum Master

5.    Eventos de Scrum

o   Sprint

o   Sprint Planning

o   Daily Scrum

o   Sprint Review

o   Sprint Retrospective

6.    Artefactos de Scrum

o   Product Backlog

o   Sprint Backlog

o   Increment

7.    Otros Conceptos de Scrum

8.    Prepárate para ser el mejor Scrum Master

Formación:

Tipo de Curso: Profesional.

Código de la Certificación: SMPC®.

Examen de Certificación:

El curso incluye el examen de certificación SMPC® por Certiprof.

·       Formato: Opción múltiple

·       Preguntas: 40

·       Idioma: Español/Inglés/Alemán/Portugués

·       Puntaje de aprobación: 32/40 o 80 %

·       Duración: 60 minutos

·       Libro abierto: No

·       Entrega: Este examen está disponible en línea

·       Supervisado: Será a discreción del Partner

Información del próximo curso:

Duración: 15 horas

Modalidad: en línea (virtual)

Fechas y horarios:

Sesión 1: miércoles 23 de marzo de 2022. 5 p.m. a 8 p.m. (GMT – 5. Bogotá, Lima, Quito)

Sesión 2: jueves 24 de marzo de 2022. 5 p.m. a 8 p.m. (GMT – 5. Bogotá, Lima, Quito)

Sesión 3: lunes 28 de marzo de 2022. 5 p.m. a 8 p.m. (GMT – 5. Bogotá, Lima, Quito)

Sesión 4: miércoles 30 de marzo de 2022. 5 p.m. a 8 p.m. (GMT – 5. Bogotá, Lima, Quito)

Sesión 5: jueves 31 de marzo de 2022. 5 p.m. a 8 p.m. (GMT – 5. Bogotá, Lima, Quito)

Inversión:

U$479 precio regular.*

Descuento de 10 % a grupos de tres o más personas. Escríbeme a contacto@luchosalazar.com si quieres acceder a este descuento.

Atención: Incluye certificación Scrum Master Professional Certificate. SMPC®

Escríbeme a contacto@luchosalazar.com para reservar tu cupo en un nuevo curso o para despejar cualquier duda que tengas.

¿Quieres este curso para tu empresa? Contáctame para más detalles.


lunes, marzo 09, 2020

El imposible y desatinado caso de SCRUMStudy®

Imagen de Sophie Janotta en Pixabay
Una colega lanzó esta pregunta en una comunidad de Scrum Masters:
Que tal grupo, […],
Duda: (corríjanme si estoy mal, por favor)
Entre las diferentes compañías tales como SCRUMstudy®, Scrum Alliance, Scrum.org, etc.
En cuestión a la teoría que imparten todas las diferentes compañías/empresas ¿existe alguna diferencia entre el contenido que imparten para enseñar a sus receptores Scrum? o ¿Todas las compañías en cuestión a teoría enseñan lo mismo pero te certifican según la compañía en la que tomaste la capacitación o curso?
[…]
Saludos.
[Texto copiado con permiso de su autora]

Recordé que hace ya algún tiempo estuve involucrado en otro foro sobre la muchas veces discutida pregunta “¿dónde me certifico?”. Mis ideas de entonces quedaron registradas en:

Pero esta nueva pregunta iba más allá. Hablaba de la teoría. Y lo que más me llamó la atención fueron las respuestas iniciales de otros foristas quienes, de alguna manera, no diferenciaban en el tratamiento de Scrum que hace el así llamado SBOK® y la guía oficial de Scrum, escrita por sus creadores.
Como es un tema escabroso, de esos que elevan las pasiones, lo pensé mucho antes de involucrarme. Finalmente, pudo más la responsabilidad que tengo con el “hacer bien las cosas”, el compromiso que tengo con el mejoramiento del uso de Scrum por parte de las personas, equipos y organizaciones a mi alrededor. Así que esta fue mi respuesta:

Imagen de David Mark en Pixabay
A ver si trato de explicar esto con una analogía:

Aunque la FIFA no inventó el Fútbol, es hoy el organismo que “rige” los estándares, que regula, que establece las “reglas” de ese deporte. A pesar de ello, es posible jugar al fútbol con variantes y no “pasa nada”: fútbol playa, fútbol 5, fútbol 7, fútbol sin porterías, etcétera. Cada una de estas otras versiones tiene distintas reglas, creadas o inventadas por nosotros mismos, las personas, o por algún organismo distinto a la FIFA. Hay menos jugadores en algunos, hay variaciones en las reglas, en fin. Pero en definitiva, el Fútbol como tal, el deporte del balón, el universal, es el de la FIFA.

Así ocurre con Scrum. Este marco de trabajo fue creado por Jeff Sutherland y Ken Schwaber y fueron ellos quienes escribieron originalmente lo que hoy se conoce como la guía de Scrum. El primer documento lo presentaron al mundo en 1995. Puedes encontrar más de los orígenes de Scrum en:


Ahora bien, son Jeff Sutherland y Ken Schwaber quienes siguen actualizando y manteniendo la guía (la teoría) de Scrum de tanto en tanto. Ellos reciben la retroalimentación de la comunidad pero finalmente ellos son sus creadores y, por decirlo de alguna manera, sus guardianes. Aunque bien todos nosotros deberíamos ser custodios de esa guía oficial también.

Después de Scrum llegaron organizaciones como la Scrum Alliance, creada precisamente para fomentar el uso del framework. Ellos crearon algunas certificaciones asociadas: Scrum Master, Product Owner y Scrum Developer. Y basaron sus cursos y certificaciones en la guía de Scrum escrita por Sutherland y Schwaber.

Más tarde aparecieron empresas como Scrum.org de Ken Schwaber y Scrum Inc., de Jeff Sutherland.

Y luego otras empresas certificadoras. Incluyendo SCRUMStudy®. Casi todas estas últimas empresas certificadoras de Scrum son independientes, de terceros, pero basan sus certificaciones en la guía de Scrum escrita por Sutherland y Schwaber, la guía oficial.

Casi todas, excepto SCRUMStudy®, que basa sus entrenamientos (teoría) y exámenes de certificación en un libro que ellos llaman Scrum Body of Knowledge (SBOK®). Un libro de más de 400 páginas la última vez que lo consulté. Mientras que la guía oficial solo tiene unas 18 páginas en español.
Imagen de LhcCoutinho en Pixabay
Este SBOK® es como esas otras versiones de Fútbol de las que te hablé al comienzo. Tiene otras reglas, muy diferentes a las que tiene la guía de Sutherland y Schwaber, los creadores de Scrum.  Imagina las diferencias nada más en número de páginas. De 18 a más de 400. Pero quisiera poner tres ejemplos de las disparidades que presenta la una versus la otra:
  1. Roles propuestos: en Scrum “oficial” (en la guía de Sutherland y Schwaber, la de 18 páginas), los tres roles propuestos son: Dueño de Producto, Scrum Master y Equipo de Desarrollo. Solo tres y nada más que tres. Estos tres roles forman lo que conocemos como Equipo Scrum. Mientras tanto en el SBOK® se proponen 2 tipos de roles: Roles Core y Roles Non-core. A los primeros pertenecen los tres roles de la guía oficial aunque con una discrepancia: el equipo de desarrollo se llama Equipo Scrum. En la guía oficial, como dije antes, este Equipo está compuesto por los tres roles. Aquí no. Y los roles non-core son Stakeholders (dentro de los cuales cuentas Customer, Usuarios y Patrocinador), Vendedores y Cuerpo de asesoramiento de Scrum. En definitiva, son reglas distintas.
  2. En la guía oficial de Scrum, el tamaño del equipo de desarrollo va de 3 a 9 personas. En la sección 3.6.2 (Tamaño del Equipo Scrum), el SBOK® dice que “El tamaño óptimo de un Equipo Scrum es de seis a diez miembros”. Otra vez, una regla disímil.
  3. En la guía oficial de Scrum, la duración máxima del Sprint es de un mes. Mientras que en la sección 2.7.1 (Scrum Time-boxes), el SBOK® dice que “Un Sprint es una iteración Time-boxed de una a seis semanas de duración”. Otra disparidad.

Y así podemos encontrar muchas. De 18 a más de 400 páginas. Simplemente son reglas desiguales, algunas muy opuestas. El SBOK® No es Scrum.

Con esto solo estoy tratando de señalar que la guía de Scrum, la cual puedes descargar de inmediato desde https://www.scrumguides.org/download.html o directamente la edición en español desde: https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Spanish-SouthAmerican.pdf, es la guía oficial que te presenta la teoría y las reglas de Scrum. Es la única fuente fiel, escrita y mantenida por sus creadores.

¿Quién sabe? Seguramente, si vas a jugar Fútbol y tomas el balón con la mano o si en tu equipo hay trece jugadores en la cancha recibirás una infracción y quizás hasta no puedas jugar.

Espero que sea de utilidad.

Saludos,

Las primeras reacciones a mis ideas en el foro fueron bastante positivas. De hecho, mucho más de lo que merezco. Pero eso me motivó a trasladar la explicación hasta mi Gazafatonario, para que más personas tuvieran acceso a ella. Por favor, déjame saber qué piensas al respecto.

miércoles, julio 17, 2019

Estimaciones en los tiempos de la agilidad



Presentación

Hace algunos días, mis amigas Valeria Vásquez y Alejandra García, un par de cómplices caleñas convencidas de esto de generar espacios para compartir conocimiento que nos permita cambiar, me invitaron al cierre de una iniciativa que decidieron liderar desde el día mundial de la Retrospectiva en 2019, la cual consistía en realizar reuniones virtuales abiertas sobre distintos temas seleccionados por la gente. Mi tema era precisamente este de las estimaciones. Aquí les presento algunas conclusiones, no sin antes felicitar en grande a estas dos intrépidas que se han tomado este asunto de ser líderes de una comunidad que sigue expandiéndose y creciendo y que cada día presenta nuevos retos, como lo es Ágiles Colombia.

Ahora sí, vamos a lo que nos ocupa.

Sobre estimaciones bajo el manto ágil

Decíamos en la reunión que una Estimación es un proceso analítico e imparcial para predecir la duración o el costo de un proyecto o desarrollo de producto, de una iniciativa en general. Y hacíamos énfasis en que la estimación es una predicción, no es una planificación, ¡no es un compromiso! Además, “una estimación es buena cuando quienes estimaron consideraron toda la información que tenían a su disposición para el momento y el propósito de la estimación”, o algo así nos contaba mi gran amigo Wilmar Hincapié en una conversación anterior.

Pero ¿qué es eso de “considerar toda la información” disponible? Bien, debemos considerar el entorno VUCA en el que nos movemos hoy día, donde la volatilidad, la incertidumbre, la complejidad y la ambigüedad están a la orden del día, en donde no es posible predecir o planear con absoluta certeza lo que vamos a entregar, cuándo lo vamos a entregar y cuánto será su costo. Lo que sí podemos hacer es empezar con planes iniciales, planes cuya elaboración no tome mucho tiempo y sobre los cuales haya certeza de que van a cambiar, quizás tanto como todos los días. Después de todo, la meta es entregar el mejor producto o servicio posible, no la planificación en sí y mucho menos la estimación. Es lo que hemos dado en llamar “filosofía ágil”. Más sobre esto en mi artículo “Cultura ágil: ese oscuro objeto del deseo”.

No estimamos en el universo de lo simple ni de lo complicado, sino en el entorno de lo complejo, de lo caótico y hasta del desorden (Cynefin). Por ello es que no existen las “buenas” técnicas de estimación ágil, aunque tampoco existen las malas, son simplemente técnicas, experimentos que hacemos para tratar de calmar el ansia de todos los interesados en temas como la duración de una iniciativa o en las fechas de entrega de producto.

Debemos deshacernos de una vez por todas y para siempre de las cadenas que nos impuso el triángulo de hierro de los proyectos tradicionales, ese que establecía el éxito de un proyecto si este se encontraba dentro de los límites de tiempo, alcance y costo estimados. En este orden de ideas los invito a que consideren mi enfoque integral de gestión de personas y desarrollo de productos (resultados y restricciones) que expongo en el triángulo ágil extendido.

Técnicas de Estimación



Sobre este asunto de las técnicas o experimentos para estimar también hablamos un poco.

1. Planning Poker

La experiencia nos ha enseñado a usarla cuando tenemos un número relativamente pequeño de elementos a estimar y con un equipo pequeño de personas. Más sobre esta técnica en https://www.mountaingoatsoftware.com/agile/planning-poker.

2. Tallas de camiseta

Esta es una técnica muy buena para estimar un backlog grande de producto. Especialmente cuando tenemos varios equipos concurrentes trabajando en el mismo producto. Es una manera informal y rápida de tener una idea aproximada del esfuerzo requerido para hacer algo. Para saber más sobre la técnica, accede a http://getskillsblogs.com/agile-estimation-with-t-shirt-sizes/.

3. Puntos de votación (dot voting)

Útil cuando nos enfrentamos a un conjunto relativamente pequeño de elementos y necesitamos una técnica súper simple y efectiva para estimar. El método se originó a partir de la toma de decisiones. Funciona bien tanto para equipos pequeños como para grandes, pero tenemos que limitar el número de elementos estimados. Más sobre la técnica en http://www.informit.com/articles/article.aspx?p=2117898&seqNum=3.

4. El sistema del cubo

Mucho más rápido que el planning poker es el sistema de cubos. Este sistema es una buena alternativa al estimar un gran número de elementos con un gran grupo de participantes. Más sobre este curioso método en:

5. Grande / Incierto / Pequeño

Un método muy rápido de estimación aproximada es el método Grande / Incierto / Pequeño. Se le pide al equipo que coloque los artículos en una de estas categorías. El primer paso es categorizar los elementos obvios en las dos categorías extremas (Grande y Pequeño). A continuación, el equipo puede discutir los elementos más complejos. Esto es en realidad una simplificación del sistema de cubos. El sistema es especialmente bueno para usar en equipos más pequeños con elementos comparables. Como siempre, podemos asignar tamaños numéricos a estas 3 categorías.

6. Mapeo de afinidad

Funciona mejor con un grupo pequeño de personas y un número relativamente pequeño de elementos. Más información sobre la técnica en:

7. Método de ordenamiento

Este es un ejercicio donde se obtiene una imagen precisa del tamaño relativo de los elementos. Funciona mejor con un pequeño grupo de expertos. Todos los elementos se ponen en orden aleatorio en una escala que va de “pequeña” a “grande”. A cada participante se le pide que mueva un elemento en la escala. Cada movimiento es solo un punto más bajo o uno más alto en la escala (muy pequeños, pequeños, medianos, grandes, muy grandes), o simplemente el participante cede el turno. Esto continúa hasta que ningún miembro del equipo quiera mover elementos o ceda su turno.

El método funciona mejor con un grupo relativamente pequeño de personas y una gran cantidad de elementos.

Más sobre una “buena” estimación


  • Siempre demos un rango, nunca demos un número. Los números son para hechos, los rangos son para estimaciones
  • Siempre preguntemos para qué serán usadas nuestras estimaciones. ¿A qué nos hemos comprometido? ¿Basados en qué información?
  • La estimación es diferente de un compromiso. Realizar una estimación “errónea” no hace daño.
  • Primero tratemos de medir, contar y calcular. Estimemos solo cuando sea necesario.
  • Por sobre todas las cosas, ¡nunca negociemos las estimaciones! Siempre preguntemos las razones y los supuestos detrás de las estimaciones.
Juegos de estimación dañinos que debes evitar

La estimación es un juego pero evita los juegos de estimación dañinos:
  • ¡Adivina el número que estoy pensando!
  • ¡Un equipo increíble como el de ustedes puede hacer mucho más que esto!
  • Esta vez será mucho más rápido porque hemos aprendido mucho del proyecto anterior.
  • ¡Este proyecto será muy diferente!
  • Si trabajamos un poco más duro, aumentaremos la velocidad.
  • ¡Puedo programar esto en la mitad del tiempo! O el infame arte de hacer el doble de trabajo en la mitad del tiempo.
  • Si bajamos la estimación, el proyecto se hará más rápido (esto realmente funciona en algunos escenarios).
Recomendaciones finales
  • Si sigues estimando como hace dos años o más seguramente no eres  ágil, es más, quizás ni estés haciendo estimaciones propiamente dichas.
  • Experimenta con muchos tipos de estimación
  • Estimas trabajo de conocimiento, trabajo creativo, no trabajo predecible y repetitivo.
  • Toma la estimación como un juego, un juego serio pero juego al fin y al cabo.
  • Usa técnicas de estimación relativa.
  • Con cautela, hazle caso a La ley de los grandes números.
  • Fija objetivos y resultados clave (OKR), no números fríos.
  • No estimes, a nivel de iteraciones, si no conoces la Definición de Terminado ni los criterios de aceptación.
  • Cuando se trate de productos o de características de producto, estima en iteraciones o, a lo sumo, en días. Deja las horas para las actividades diarias.
  • Estima para un rango que va desde la Mínima Entrega Viable hasta la Entrega Completa. Es decir, asegúrate de que en ese rango de tiempo harás una entrega de valor.
  • Evita a los “influenciadores” expertos y, en general, a quienes pueden crear distractores al momento de realizar la estimación.
  • Estima valor de negocio, no puntos de historia.
  • Experimenta, crea tu propio método de estimación. Por ejemplo, el método 1 – 5 – 9 es una técnica simple que consiste en establecer si el elemento se puede elaborar o no en una iteración junto a otros 5 a 9 elementos. De ser afirmativo, es porque contamos con la suficiente información para desarrollarlo a continuación. Útil para usar durante la planificación de una iteración de menos de un mes de duración.
  • ¡O simplemente no estimes del todo! Enfócate en entregar Valor, en reducir el Time to Market, en eliminar desperdicios y en mejorar continuamente.