Scrum Master 3 - fe de erratas
Versión 4.0
Desmontando la gestión de proyectos
Localización
- Página 19 (nueva versión del manual).
- Página 26 (versión anterior del manual).
| o al simple uso de técnicas de gestión visual kanban para mantener un flujo continuo de tareas. |
| o al simple uso de técnicas de gestión visual kanban para mantener un flujo continuo de trabajo. |
Diferenciando prácticas de principios y valores
Localización
- Página 21 (nueva versión del manual).
- Página 28 (versión anterior del manual).
| Cuando se empieza a trabajar con scrum, como con cualquier otra herramienta, es recomendable leer el manual y seguir las instrucciones; es decir, adoptar el marco estándar: el que se explica en la primera parte de este manual, con los roles, artefactos y eventos que lo configuran.
Conviene no engañarse: si el foco está puesto en el proceso y no en el conocimiento tácito de las personas no se está haciendo agilidad, sino ingeniería concurrente. Cuando se alcanza un flujo de avance iterativo, se puede intentar ir más allá. Llega el momento de desaprender las prácticas y de apoyarse en los principios y valores de scrum, adaptando éste y otras técnicas y marcos a las características concretas del proyecto o del equipo. En la mayoría de empresas ágiles estas prácticas se pueden adaptar, y de hecho se adaptan. |
| Cuando se empieza a trabajar con scrum, como con cualquier otra herramienta, es recomendable leer el manual de Scrum Master y seguir las instrucciones; es decir, adoptar el marco tradicional o estándar. En esta primera parte explicamos en qué consiste, y cuáles son los roles, artefactos y eventos que lo configuran. El marco es, por así decir, una plantilla, pero no un molde. No son reglas que deban seguirse al pie de la letra para garantizar velocidad o calidad, sino de un buen punto de partida para empezar a trabajar de forma iterativa.
Conviene no engañarse: si nuestro foco está puesto en el proceso, en seguir las reglas, y no en el conocimiento tácito o talento de las personas, no se está haciendo agilidad, sino ingeniería concurrente. La agilidad requiere confianza en las capacidades del equipo. Las herramientas y procesos que se usan deben ayudar a gestionar el trabajo; no a las personas. Ya que el objetivo final es que los equipos sean capaces de autogestionarse. Cuando se alcanza un flujo de avance iterativo, se puede intentar ir más allá de un marco estándar de scrum. Llega el momento de desaprender las prácticas y de apoyarse en los principios y valores de scrum, adaptando éste y otras técnicas y marcos a las características concretas del proyecto o del equipo. En la mayoría de empresas ágiles estas prácticas se pueden adaptar, y de hecho se adaptan. |
El ciclo scrum
Localización
- Página 24 (nueva versión del manual).
- Página 31 (versión anterior del manual).
| Se comienza con la visión general del resultado que se desea, y a partir de ella se especifica y da detalle a las funcionalidades que se desean obtener en primer lugar.
Cada ciclo de desarrollo o iteración (sprint) finaliza con la entrega de una parte operativa del producto (incremento). La duración de cada sprint puede ser de una hasta seis semanas, aunque se recomienda que no exceda de un mes. En scrum, el equipo monitoriza la evolución de cada sprint en reuniones breves diarias donde se revisa el trabajo realizado por cada miembro el día anterior, y el previsto para el día actual. Estas reuniones son de tiempo cerrado, de 5 a 15 minutos máximo, se realizan de pie junto a un tablero o pizarra con información de las tareas del sprint y el trabajo pendiente en cada una. Se denominan «reunión de pie» o «scrum diario» (en inglés stand-up meeting, daily scrum o morning rollcall). |
| Se comienza con la visión general del resultado que se desea, y a partir de ella se especifica y da detalle a las funcionalidades que se desean obtener en primer lugar.
Cada ciclo de desarrollo o iteración (sprint) finaliza con la entrega de una parte operativa del producto (incremento). La duración de cada sprint puede ser de entre 1 y 3 semanas. Lo más habitual es que tengan siempre la misma medida, marcando una cadencia, pero ésta puede ir evolucionando o ajustarse. Vídeo explicativo: El marco de desarrollo scrum (→ «Referencias bibliográficas»). |
Roles: desarrollador
Localización
- Página 28 (nueva versión del manual).
- Página 35 (versión anterior del manual).
| Cada uno de los profesionales que realizan el «incremento» (→ «Artefactos») de cada sprint.
Se recomienda que haya entre 3 y 9 desarrolladores. Más allá de 9 resulta difícil mantener la comunicación directa, y se manifiestan con más intensidad los roces habituales de la dinámica de grupos, que comienzan a partir de 6 personas. Son profesionales multifuncionales, que trabajan de forma solidaria con responsabilidad compartida. Es posible que algún desarrollador esté especializado en áreas concretas, pero la responsabilidad del desarrollo recae sobre todos por igual. Las principales responsabilidades, más allá de la autogestión y uso de tecnologías ágiles, son las que marcan la diferencia entre un «grupo de trabajo» y un «equipo»:
|
| Cada uno de los profesionales que realizan el «incremento» (→ «Artefactos») de cada sprint. Aunque se les denomine «desarrolladores» en scrum esto no significa que se hable siempre de programadores. Es un término que engloba a las personas cuyo trabajo contribuye directamente a «desarrollar» o construir el «incremento».
Se recomienda que haya entre 3 y 9 desarrolladores. Más allá de 9 resulta difícil mantener la comunicación directa, y se manifiestan con más intensidad los roces habituales de la dinámica de grupos, que comienzan a partir de 6 personas. Son profesionales multifuncionales, que trabajan de forma solidaria con responsabilidad compartida. Es posible que algún desarrollador esté especializado en áreas concretas, pero la responsabilidad del desarrollo recae sobre todos por igual. Las principales responsabilidades, más allá de la autogestión y uso de tecnologías ágiles, son las que marcan la diferencia entre un «grupo de trabajo» y un «equipo»:
|
Artefactos más extendidos
Localización
- Página 29 (nueva versión del manual).
- Página 37 (versión anterior del manual).
* Pila del producto / product backlog: Registra y prioriza los requisitos desde el punto de vista del cliente. Empieza con una visión inicial del producto y crece y evoluciona durante el desarrollo. Los requisitos suelen denominarse «historias de usuario», que se descomponen en «tareas» de menor tamaño, normalmente de un día de trabajo como máximo.
|
* Pila del producto / product backlog: lista priorizada de las necesidades del cliente, expresadas como historias de usuario. Al principio del proyecto refleja el MVP (producto mínimo viable) o la visión inicial. Es un documento vivo: durante el desarrollo, crece y evoluciona.
Enlace de interés: Cómo crear un backlog, Scrum Manager Podcast (→ «Referencias bibliográficas»). |
Otros artefactos
Localización
- Página 29 (nueva versión del manual).
- Página 38 (versión anterior del manual).
* Gráfico de avance o burn down chart: indica el trabajo pendiente y la velocidad a la que se están completando las tareas para deducir si se completarán todas en el tiempo estimado. Los desarrolladores lo actualizan a diario.
|
* Gráfico de avance o burn down chart: indica el trabajo pendiente y la velocidad a la que se están completando las unidades de trabajo, para deducir si se completarán todas en el tiempo estimado. Los desarrolladores lo actualizan a diario.
Enlace de interés: Definition of Done, Scrum Manager Podcast (→ «Referencias bibliográficas»). |
Unidad de trabajo
Localización
- Página 30 (nueva versión del manual).
Se ha añadido el concepto unidad de trabajo.
Pila del producto
Localización
- Página 31 (nueva versión del manual).
- Página 39-40 (versión anterior del manual).
| Las más prioritarias deben estar lo bastante detalladas como para descomponerse en tareas y pasar al siguiente sprint.
Las tareas de priorización, detalle y preestimación de las historias, previas al sprint, se suelen llamar «refinado» o «preparación». El propietario del producto y los desarrolladores pueden realizarlas en cualquier momento, de forma colaborativa, pero nunca deberían consumir más del 10% de la capacidad de trabajo del equipo. Más tarde los desarrolladores realizarán una segunda estimación más detallada, en la «reunión de planificación del sprint» (→ «Eventos»), al descomponer las «historias» en «tareas». La responsabilidad de estimar el esfuerzo previsible para cada elemento de la posterior lista de tareas (→ «Pila del sprint») es de los desarrolladores. (→ «Medición y estimación ágil»). Las historias de usuario de la pila del producto que pueden ser incorporados a un sprint se denominan «preparadas» o «ready». Se aplica este término (o similar) para indicar que el propietario del producto y el equipo de desarrollo están de acuerdo en que la historia está lista para ser seleccionada para el sprint. Es decir: está definida, preestimada, es asumible por sí misma en un único sprint, y se han establecido los criterios para considerarla terminada, así como la persona responsable de verificar que se cumplen. |
| Las más prioritarias deben estar lo bastante detalladas como para incluirse en el sprint. Acordar una DoR puede ayudar. A la labor de priorizar, detallar y preestimar las historias, se le suele llamar «refinado» o «preparación». Se trata de una tarea colaborativa; el propietario del producto y los desarrolladores pueden realizar una reunión de refinado en cualquier momento, sin que esto consuma nunca más del 10% de la capacidad de trabajo del equipo. Conviene recordar que las estimaciones, el esfuerzo previsible para cada elemento de la pila del sprint, son a juicio de los desarrolladores, ya que son quienes realizarán el trabajo (→ «Medición y estimación ágil»).
Las historias de usuario de la pila del producto que pueden ser incorporados a un sprint se denominan «preparadas» o «ready». Se aplica este término (o similar) para indicar que el propietario del producto y el equipo de desarrollo están de acuerdo en que la historia está lista para ser seleccionada para el sprint. Es decir: está definida, preestimada, es asumible por sí misma en un único sprint, y se han establecido los criterios para considerarla terminada, así como la persona que los verificará. |
Pila del sprint
Localización
- Página 32-33 (nueva versión del manual).
- Página 41-42 (versión anterior del manual).
La imagen que representaba la pila del sprint se ha modificado.
| La «pila del sprint» o «sprint backlog» es la lista de todas las tareas necesarias para construir las historias de usuario que se van a realizar en un sprint. En ella las historias de usuario se descomponen en unidades de tamaño adecuado para monitorizar el avance a diario, así como para identificar riesgos y problemas sin procesos de gestión complejos.
Todo el equipo colabora en la confección de esta pila, durante la «reunión de planificación del sprint» (→ «Eventos»), indicando para cada tarea el esfuerzo previsto para realizarla. Para calcular el «esfuerzo» de cada tarea en «puntos» o «tiempo ideal» (→ «Medición y estimación ágil») es habitual emplear técnicas como la estimación de póquer (→ «Prácticas para flexibilizar scrum», «Estimación de póquer»). Las tareas de mayor tamaño se dividen en otras, de modo una sola nunca dure más de un día de trabajo. Si la pila del producto es territorio del propietario del producto, la pila del sprint es territorio de los desarrolladores. Son los únicos que pueden modificarla durante el sprint. Proporciona además comunicación visual directa y sobre ella el equipo de desarrollo revisa a diario el avance del sprint. Lo ideal es que se encuentre en un tablero o pared en el mismo espacio físico donde se trabaja, para que sea visible por todos. Algunos soportes habituales son tableros físicos, hojas de cálculo compartidas, y herramientas colaborativas de gestión de proyectos tales como Todoist, Flow o Trello. Lo apropiado es utilizar el formato más cómodo para todos, teniendo en cuenta los siguientes criterios:
|
| La «pila del sprint» o «sprint backlog» es la lista de todas las unidades de trabajo (historias, tareas…) para completar el incremento. En ella las historias de usuario se descomponen en unidades de tamaño adecuado para monitorizar el avance a diario, así como para identificar riesgos y problemas sin procesos de gestión complejos.
Todo el equipo colabora en la confección de esta pila, durante la «reunión de planificación del sprint» (→ «Eventos»), indicando para cada unidad de trabajo el esfuerzo previsto para realizarla. Es habitual estimar este esfuerzo en «puntos» o «tiempo ideal» (→ «Medición y estimación ágil») empleando técnicas como la estimación de póquer (→ «Prácticas para flexibilizar scrum», «Estimación de póquer»). Durante la reunión de planificación los desarrolladores pueden, si así lo deciden, dividir las historias en tareas más pequeñas. En tal caso se aconseja que una tarea no dure más de un día de trabajo. Si la pila del producto es territorio del propietario del producto, la pila del sprint es territorio de los desarrolladores. Son los únicos que pueden modificarla durante el sprint. Proporciona además comunicación visual directa y sobre ella el equipo de desarrollo revisa a diario el avance del sprint. Lo ideal es que se encuentre en un tablero o pared en el mismo espacio físico donde se trabaja, para que sea visible para todos. Algunos soportes habituales son tableros físicos, hojas de cálculo compartidas, y herramientas colaborativas de gestión de proyectos tales como Todoist, Flow o Trello. Lo apropiado es utilizar el formato más cómodo para todos, teniendo en cuenta los siguientes criterios:
|
Eventos
Localización
- Página 34 (nueva versión del manual).
- Página 44 (versión anterior del manual).
| El protocolo más frecuente es que cada miembro informe de lo realizado el día anterior, lo que tiene previsto hacer a continuación y si prevé algún impedimento.
Cada persona actualiza en la pila del sprint el tiempo o esfuerzo pendiente de sus tareas, y con esta información se actualiza a su vez el gráfico con el que el equipo monitoriza el avance del sprint: el gráfico de avance o burn down. Revisión del sprint: análisis e inspección del «incremento» generado, y adaptación de la pila del producto si resulta necesario. Retrospectiva del sprint: reunión al finalizar el sprint en la que el equipo analiza aspectos operativos de su forma de trabajo y crea un plan de mejoras, para aplicarlo en la siguiente iteración. |
| El formato estándar es que cada miembro informe de lo realizado el día anterior, lo que tiene previsto hacer a continuación y si prevé algún impedimento.
Cada persona actualiza en la pila del sprint el tiempo o esfuerzo pendiente del trabajo que tiene asignado, y con esta información se actualiza a su vez el gráfico con el que el equipo monitoriza el avance del sprint: el gráfico de avance o burn down. Revisión del sprint: análisis e inspección del «incremento» generado, y adaptación de la pila del producto si resulta necesario. Retrospectiva del sprint: reunión al finalizar el sprint en la que el equipo analiza aspectos operativos de su forma de trabajo y crea un plan de mejoras, para aplicarlo en la siguiente iteración. Un evento que no forma parte del marco tradicional de scrum pero ha ido ganando popularidad son las reuniones de refinamiento del backlog, que ya se ha mencionado al hablar de los artefactos y la estimación de unidades de trabajo. No hay consenso sobre cuándo hacer estas reuniones; se acaba resolviendo de una forma u otra en cada casuística. Parece frecuente que tengan lugar antes de la reunión de planificación del sprint. Realizar estas reuniones, sea cuando sea, permite llegar a las de planificación con historias ya detalladas y estimadas por los desarrolladores. Enlace de interés: Eventos de scrum, Scrum Manager Podcast (→ «Referencias bibliográficas»). |
Reunión de planificación del sprint
Localización
- Página 36 (nueva versión del manual).
- Página 46 (versión anterior del manual).
| 3. ¿Cómo se va a realizar el trabajo seleccionado?
Los desarrolladores descomponen cada elemento de la pila del producto en tareas que se deberían poder realizar en un día de trabajo o menos. Se recomienda articular la reunión en dos partes de duración similar, separadas por una pausa:
|
| 3. ¿Cómo se va a realizar el trabajo seleccionado?
Este punto puede ser opcional; es recomendable en equipos con menos experiencia. Puede ser beneficioso que los desarrolladores descompongan cada historia del sprint en tareas, de un día de trabajo o menos. Ayuda a ir generando una mejor intuición de lo que entrañan diferentes tipos de historia, y a visualizar el avance del sprint día a día. Se recomienda articular la reunión en dos partes de duración similar, separadas por una pausa:
|
Localización
- Página 36 (nueva versión del manual).
- Página 47 (versión anterior del manual).
|
|
Localización
- Página 37-38 (nueva versión del manual).
- Página 47-49 (versión anterior del manual).
| Primera mitad: ¿por qué es valioso este sprint y qué se puede hacer en él?
El propietario del producto es el responsable de la presentación en esta primera mitad de la reunión. Expone las historias de usuario de mayor prioridad, explicando qué se necesita y qué prevé que se podrá desarrollar en el siguiente sprint. Si la pila ha tenido cambios significativos desde la anterior reunión, explica las causas que los han ocasionado. El objetivo es que todos comprendan, con un nivel de detalle suficiente, el incremento que se desea obtener con el sprint. La exposición debe estar abierta a preguntas y se pueden solicitar aclaraciones. Cualquier desarrollador puede proponer sugerencias, modificaciones y soluciones alternativas, y modificar la pila en consecuencia. Esta reunión es un punto caliente de scrum para favorecer la fertilización cruzada de ideas y añadir valor a la visión del producto. Tras reordenar y replantear las historias de la pila, el equipo define el «objetivo del sprint»: una frase que sintetiza cuál es el valor que se va a entregar al cliente. Exceptuando sprints dedicados a colecciones de tareas desordenadas, la elaboración de este lema de forma conjunta en la reunión es una garantía de que todo el equipo comprende y comparte la finalidad del trabajo, y durante el sprint sirve de criterio de referencia en la toma de decisiones. Segunda mitad: ¿cómo se conseguirá el incremento? Esta segunda parte debe considerarse como una «reunión del equipo», en la que deben estar todos los desarrolladores y ser ellos quienes descompongan, estimen y asignen el trabajo. El papel del propietario del producto es atender a dudas y comprobar que comprenden y comparten su objetivo. El equipo desglosa cada elemento de la pila del producto en tareas y estima el esfuerzo para cada una de ellas, componiendo así la pila del sprint. Se establecen cuáles serán las prioritarias para los primeros días y se asignan tomando como criterios los conocimientos e intereses de cada miembro y procurando distribuir el trabajo de forma homogénea. Funciones del scrum master durante la reunión de planificación del sprint En caso de haber un scrum master asignado, éste será el moderador de la reunión. Es responsable y garante de:
|
| Primera mitad: ¿por qué es valioso este sprint y qué se puede hacer en él?
En esta primera mitad, el propietario del producto expone las historias de usuario de mayor prioridad, explicando qué se necesita y qué prevé que se podrá desarrollar en el siguiente sprint. Si la pila ha tenido cambios significativos desde la anterior reunión, explica las causas que los han ocasionado. El objetivo es que todos comprendan, con un nivel de detalle suficiente, el incremento que se desea obtener con el sprint. La exposición debe estar abierta a preguntas y se pueden solicitar aclaraciones. Cualquier desarrollador puede proponer sugerencias, modificaciones y soluciones alternativas, y modificar la pila en consecuencia. Esta reunión es un punto caliente de scrum para favorecer la fertilización cruzada de ideas y añadir valor a la visión del producto. Tras reordenar y replantear las historias de la pila, el equipo define el «objetivo del sprint»: una frase que sintetiza cuál es el valor que se va a entregar al cliente. Exceptuando sprints dedicados a colecciones de historias desordenadas, la elaboración de este lema de forma conjunta en la reunión es una garantía de que todo el equipo comprende y comparte la finalidad del trabajo, y durante el sprint sirve de criterio de referencia en la toma de decisiones. Segunda mitad: ¿cómo se conseguirá el incremento? Esta segunda parte debe considerarse como una «reunión del equipo», en la que deben estar todos los desarrolladores y ser ellos quienes descompongan, estimen y asignen el trabajo. El papel del propietario del producto es atender a dudas y comprobar que se comprende y comparte el objetivo. El equipo compone la pila del sprint y desglosa las historias que necesiten mayor nivel de detalle en unidades más pequeñas. Se establecen cuáles serán las historias o tareas prioritarias para los primeros días. La priorización sigue el orden marcado por el product owner; una vez establecido, los desarrolladores se asignan las unidades de trabajo que mejor se ajusten a su perfil respetando el orden de prioridad, procurando distribuir el trabajo de forma homogénea. Funciones del scrum master durante la reunión de planificación del sprint En caso de haber un scrum master asignado, éste será el moderador de la reunión para garantizar que:
|
Scrum diario
Localización
- Página 38 (nueva versión del manual).
- Página 50 (versión anterior del manual).
| Reunión diaria breve, de no más de 15 minutos, en la que los desarrolladores sincronizan el trabajo y establecen el plan para las 24 horas siguientes. |
| En scrum, el equipo monitoriza la evolución de cada sprint en reuniones diarias muy breves, coloquialmente llamadas dailies. Reciben otros nombres como «reunión de pie» (stand-up meeting), «scrum diario» (daily scrum) o morning rollcall. El tiempo máximo recomendado es de 15 minutos, y aunque ahora es frecuente que también se hagan en remoto, en persona se aconseja hacerlas de pie. En cualquier caso, con acceso a un tablero o pizarra con información sobre el avance del sprint.
Durante estos minutos, los desarrolladores sincronizan el trabajo y establecen el plan para las 24 horas siguientes. |
Localización
- Página 38-39 (nueva versión del manual).
- Página 51 (versión anterior del manual).
Se ha actualizado la imagen del formato de reunión del scrum diario.
| Se recomienda realizarla de pie junto a un tablero con la pila del sprint y el gráfico de avance o tablero kanban, para que todos puedan compartir la información y anotar.
En la reunión están presentes todos los desarrolladores, y pueden asistir también otras personas relacionadas con el proyecto o la organización, aunque éstas no intervienen. Cada miembro del equipo de desarrollo explica lo que ha logrado desde el anterior scrum diario, lo que va ha hacer hasta el siguiente, y si está teniendo algún problema o si prevé que puede encontrar algún impedimento. Se actualiza sobre la pila del sprint el esfuerzo que estima pendiente en las tareas que tiene asignadas, o se marcan como finalizadas las ya completadas. Al final de la reunión el equipo de desarrollo refresca el gráfico de avance del sprint (→ «Prácticas para flexibilizar scrum», «Gráfico burn down») con las estimaciones actualizadas. Los desarrolladores son responsables de esta reunión, no el scrum master; y no se trata de una reunión de inspección o control, sino de comunicación entre el equipo, para compartir el estado del trabajo, chequear el ritmo de avance y colaborar en posibles dificultades. El scrum master realizará las gestiones adecuadas para resolver estas últimas tras la reunión. |
| Formato de la reunión
Se recomienda realizarla de pie junto a un tablero con la pila del sprint y el gráfico de avance o tablero kanban, para que todos puedan compartir la información y anotar. En la reunión están presentes todos los desarrolladores, y pueden asistir también otras personas relacionadas con el proyecto o la organización, aunque éstas no intervienen. Los desarrolladores conducen esta reunión, no el scrum master. No se trata de una reunión de control: es para que el equipo colabore, comparta el estado del trabajo y posibles dificultades. El papel del scrum master es facilitar, y encargarse de realizar las gestiones adecuadas para resolver estas últimas tras la reunión. Es frecuente que cada desarrollador explique lo que ha logrado desde el anterior scrum diario, lo que va a hacer hasta el siguiente, y si está teniendo algún problema o si prevé que puede encontrar algún impedimento. Al final de la reunión el equipo de desarrollo refresca el gráfico de avance del sprint (→ «Prácticas para flexibilizar scrum», «Gráfico burn down») con las estimaciones actualizadas. Sin embargo, se ha observado que este formato de participación individual puede tener efectos negativos en la motivación y las dinámicas de equipo. Aunque puede ser un punto de partida, se recomienda evolucionar hacia un formato de reunión que se enfoque en el trabajo, no en las personas. Este formato alternativo de la reunión sería así: los desarrolladores, que son quienes llevan la reunión, observan el estado de avance. Viendo qué hay en curso, se auto-asignan el trabajo aún pendiente siguiendo el orden de prioridad y asegurándose de que no se formen cuellos de botella. Este formato, que se centra en las historias o tareas en lugar de ir persona a persona, reduce la duración de las reuniones, aumenta la autonomía de los equipos, y mejora la colaboración. Por ejemplo, se ve con más frecuencia que varios desarrolladores decidan trabajar juntos en la misma historia prioritaria para garantizar que salga adelante si puede generar retrasos. |
Medición y estimación ágil
Localización
- Página 43 (nueva versión del manual).
- Página 55 (versión anterior del manual).
| Scrum mide el trabajo pendiente, primero: para estimar el esfuerzo y tiempo previstos para realizar determinadas tareas, historias de usuario y «epics» (historias de gran tamaño). Y segundo: para determinar el grado de avance del proyecto, y en especial de cada sprint. |
| Scrum mide el trabajo pendiente, primero: para estimar el esfuerzo y tiempo previstos para realizar determinadas tareas, historias de usuario y «epics» (historias de gran tamaño). Y segundo: para determinar el grado de avance del proyecto, y en especial de cada sprint. |
Localización
- Página 43 (nueva versión del manual).
- Página 55 (versión anterior del manual).
| Cada organización, según sus circunstancias y criterio, institucionaliza su métrica de trabajo, su «punto». Es el tamaño relativo de tareas que se suele emplear. Es importante que el significado y la forma de aplicar la métrica sea siempre la misma en las mediciones de la organización, y que sea conocida por todos.
El tipo de «punto» dependerá de la organización. En un equipo de programación el punto puede ser equivalente a preparar una pantalla de login; para un equipo de diseño gráfico, la maquetación de un tríptico. |
| Cada organización, según sus circunstancias y criterio, institucionaliza su métrica de trabajo, su «punto». Es el tamaño relativo de tareas que se suele emplear. Es importante que el significado y la forma de aplicar la métrica sea siempre la misma en las mediciones de la organización, y que sea conocida por todos.
El tipo de «punto» dependerá de la organización. En un equipo de programación el punto puede ser equivalente a preparar una pantalla de login; para un equipo de diseño gráfico, la maquetación de un tríptico. |
Principios
Localización
- Página 47 (nueva versión del manual).
- Página 63 (versión anterior del manual).
| Personas sobre procesos
La inteligencia colectiva del equipo, su conocimiento tácito, es responsable directa de la calidad del producto. |
| Personas sobre procesos
La inteligencia colectiva del equipo, su conocimiento tácito, es responsable de la calidad del producto. |
Las personas y sus roles
Localización
- Página 49 (nueva versión del manual).
- Página 64-65 (versión anterior del manual).
| Desarrolladores
El equipo de desarrolladores es responsable de producir un incremento para el cliente con cada iteración, así como de mantener un ritmo de trabajo sostenible. Comprometidos con su trabajo, son responsables de aplicar una mirada crítica para mejorar sus resultados y sus métodos. Por último, deben ser conscientes de la importancia que tienen su talento e inteligencia colectiva, no sólo a nivel individual. Scrum master Es quien garantiza que el marco scrum funcione, moderando las reuniones de scrum diarias y gestionando la resolución de impedimentos identificados en éstas, para mantener el avance del equipo. Agrupar la responsabilidad del funcionamiento de scrum en el rol de scrum master resulta aconsejable cuando el product owner o el equipo tienen poca experiencia utilizando scrum, o en organizaciones grandes, con un flujo continuo de rotación o formación de personal. En equipos pequeños, estables y con niveles de agilidad consolidados, las responsabilidades de funcionamiento y mejora del marco de scrum pueden estar ya interiorizadas y asumidas por el equipo en conjunto. |
| Desarrolladores
El equipo de desarrolladores es responsable de producir un incremento con cada iteración, así como de mantener un ritmo de trabajo sostenible. Comprometidos con su trabajo, deben aplicar una mirada crítica para mejorar sus resultados y sus métodos. Por último, deben ser conscientes de la importancia que tienen su talento e inteligencia colectiva, no sólo a nivel individual. Scrum master Es quien garantiza que el marco scrum funcione, moderando las reuniones de scrum diarias y gestionando la resolución de impedimentos identificados en éstas, para mantener el avance del equipo. Asignar la responsabilidad del funcionamiento de scrum a un scrum master es más aconsejable para equipos con poca experiencia o en organizaciones grandes, con un flujo continuo de rotación o formación de personal. En equipos pequeños, estables y con niveles de agilidad consolidados, las responsabilidades de funcionamiento y mejora del marco de scrum pueden estar ya interiorizadas y asumidas por el equipo en conjunto. |
Prácticas para flexibilizar scrum
Se ha cambiado el orden en el que aparecen estas prácticas.
Localización
- Página 52 (nueva versión del manual).
- Página 67 (versión anterior del manual).
La comunidad profesional aporta «prácticas» para dar forma a pilas de producto, historias de usuario, representar con imágenes la visión del producto, conducir eventos y reuniones, y estimar tareas. Las dos más empleadas en la formación inicial del marco scrum son el gráfico burn down y la estimación de póquer. Vamos a verlas junto con algunas otras:
Para el propósito de este manual no nos interesa entrar a explicar la operativa de estas prácticas en profundidad, sino presentarlas como ejemplos y animar al lector a investigar y experimentar. Son sólo algunas de las técnicas de gestión ágil que pueden ayudar a personalizar el modelo de gestión de un proyecto o equipo. |
La comunidad profesional aporta «prácticas» para dar forma a pilas de producto, historias de usuario, representar con imágenes la visión del producto, conducir eventos y reuniones, y estimar unidades de trabajo. Las dos más empleadas en la formación inicial del marco scrum son el gráfico burn down y la estimación de póquer. Vamos a verlas junto con algunas otras:
Para nuestro propósito no nos interesa entrar a explicar la operativa de estas prácticas en profundidad, sino presentarlas como ejemplos y animar al lector a investigar y experimentar. Son sólo algunas de las técnicas de gestión ágil que pueden ayudar a personalizar el modelo de gestión de un proyecto o equipo. |
Localización
- Página 52-53 (nueva versión del manual).
- Página 68 (versión anterior del manual).
Día a día, cada desarrollador estima en la pila del sprint el esfuerzo pendiente para cada tarea, hasta que se termina. Con esa información se actualiza el gráfico, reflejando cada día el esfuerzo pendiente total de todas las tareas que aún no se han terminado. El avance ideal de un sprint estaría representado por la diagonal que reduce el esfuerzo pendiente de forma continua y gradual hasta el último día previsto. Como es de suponer, esto no es lo habitual. Se puede llevar un patrón de avance adecuado sin que la diagonal del gráfico sea perfecta. Si la línea de avance se mantiene durante varios días muy por encima de la diagonal, es señal de que se ha subestimado el sprint y de que éste requerirá más tiempo. Cuando ocurre lo contrario y la línea desciende más deprisa que la diagonal, se terminará antes de lo previsto. |
| Día a día, cada desarrollador estima en la pila del sprint el esfuerzo pendiente para cada unidad de trabajo, hasta que se termina. Con esa información se actualiza el gráfico, reflejando cada día el esfuerzo total pendiente.
Cuando se trabaja con historias de usuario en lugar de tareas (que, recordemos, deberían ser de un día de duración o menos) el gráfico de avance se puede actualizar por historia acabada, en lugar de por esfuerzo estimado pendiente en cada historia día a día. La historia se convierte en la medida de avance principal, y se restan todos los puntos estimados para cada historia una sola vez, cuando ésta se completa. |
Localización
- Página 53 (nueva versión del manual).
- Páginas 68 y 75 (versión anterior del manual).
Se han añadido los enlaces a los vídeos explicativos de cada gráfico (de producto y de avance) y se ha recolocado la imagen del gráfico de avance.
Localización
- Página 54 (nueva versión del manual).
- Página 73 (versión anterior del manual).
| El tablero no sólo ayuda a gestionar de manera clara y visual y a mantener el ritmo, sino que también es una herramienta útil para compartir información entre el equipo. Muestra de inmediato, con cada actualización, el estado de las tareas y si se están formando cuellos de botella.
La ausencia de hitos temporales como los sprints evita la ley de Parkinson. Por el contrario, esta ausencia podría provocar retrasos, por perfeccionismo o por procrastinación. Pero gracias al WIP (work in process), la estructura y la visibilidad que ofrece el tablero kanban, se consigue paliar este efecto negativo también. El WIP es el número máximo de tareas que pueden estar a la vez en la misma fase del proceso. Un WIP=3 de la fase «en curso» indica que el equipo no puede trabajar en más de 3 tareas de forma simultánea. |
| El tablero no sólo ayuda a gestionar de manera clara y visual y a mantener el ritmo, sino que también es una herramienta útil para compartir información entre el equipo. Muestra de inmediato, con cada actualización, el estado de cada unidad de trabajo y si se están formando cuellos de botella.
La ausencia de hitos temporales como los sprints evita la ley de Parkinson. Por el contrario, esta ausencia podría provocar retrasos, por perfeccionismo o por procrastinación. Pero gracias al WIP (work in process), la estructura y la visibilidad que ofrece el tablero kanban, se consigue paliar este efecto negativo también. El WIP es el número máximo de unidades de trabajo que pueden estar a la vez en la misma fase. Un WIP=3 dela fase «en curso» indica que el equipo no puede trabajar en más de 3 historias o tareas de forma simultánea. |
Localización
- Página 54-55 (nueva versión del manual).
- Página 69-70 (versión anterior del manual).
| Jane Grenning ideó este juego de planificación que se utiliza para conducir las reuniones en las que se estima el esfuerzo y la duración de las tareas (planificación del sprint). El modelo inicial de Grenning consta de 8 cartas, con los valores 1⁄2, 1, 2, 3, 5, 6, 7 e infinito.
Cada participante dispone de un juego de cartas y, en la estimación de cada tarea, muestra la combinación que suma el esfuerzo estimado. El uso más extendido, sin embargo, es empleando una baraja con números en sucesión de Fibonacci, como en la ilustración. En este caso no se combinan números, sólo se muestra una carta para estimar cada tarea: aquella con la cifra más aproximada. Esta variante se basa en que, al aumentar el tamaño de las tareas, aumenta también el margen de error. Así, por ejemplo, si una persona cree que el tamaño adecuado de una tarea es 6, se ve obligado a reconsiderar. Puede aceptar que parte de la incertidumbre apreciada no es tal y levantar la carta de 5, o aceptar una estimación más conservadora y levantar el 8. Es frecuente añadir una carta con un símbolo de duda o interrogación para indicar que, por las razones que sean, no se puede precisar una estimación. También es posible incluir otra carta con alguna imagen alusiva para indicar que se necesita un descanso. El símbolo de infinito se saca cuando la tarea excede el máximo esfuerzo estimable, para indicar que debería dividirse en unidades más pequeñas. Cuando las estimaciones son muy dispares, el responsable de la reunión puede optar por varias alternativas. Se puede preguntar a las personas con las estimaciones más extremas el por qué de su estimación y repetir el proceso. Otra opción es dejar de lado la tarea por el momento y estimarla de nuevo más tarde. O pedir al propietario del producto que descomponga la tarea y valorar cada una de las sub-tareas resultantes. También puede tomar la decisión de optar por la estimación más optimista, más pesimista, o sacar la media. Dependerá de la tarea y del estilo de gestión de cada equipo. |
| Jane Grenning ideó este juego de planificación que se utiliza para conducir las reuniones en las que se estima el esfuerzo y la duración de las unidades de trabajo (planificación del sprint). El modelo inicial de Grenning consta de 8 cartas, con los valores ½, 1, 2, 3, 5, 6, 7 e infinito.
Cada participante dispone de un juego de cartas y, en la estimación de cada unidad, muestra la combinación que suma el esfuerzo estimado. El uso más extendido, sin embargo, es empleando una baraja con números en sucesión de Fibonacci, como en la ilustración. En este caso no se combinan números, sólo se muestra una carta para cada estimación: aquella con la cifra más aproximada. Esta variante se basa en que, al aumentar el tamaño de la tarea o historia, aumenta también el margen de error. Así, por ejemplo, si una persona cree que el tamaño adecuado de una historia es 6, se ve obligado a reconsiderar. Puede aceptar que parte de la incertidumbre apreciada no es tal y levantar la carta de 5, o aceptar una estimación más conservadora y levantar el 8. Es frecuente añadir una carta con un símbolo de duda o interrogación para indicar que, por las razones que sean, no se puede precisar una estimación. También es posible incluir otra carta con alguna imagen alusiva para indicar que se necesita un descanso. El símbolo de infinito se saca cuando la historia excede el máximo esfuerzo estimable, para indicar que debería dividirse en unidades más pequeñas. Cuando las estimaciones son muy dispares, el moderador de la reunión puede optar por varias alternativas. Se puede preguntar a las personas con las estimaciones más extremas el por qué de su estimación y repetir el proceso. Otra opción es dejar de lado la unidad a estimar por el momento, y estimarla de nuevo más tarde. O pedir al propietario del producto que la descomponga para valorar cada sub-unidad resultante. También puede tomar la decisión de optar por la estimación más optimista, más pesimista, o sacar la media. Dependerá del trabajo a estimar y del estilo de gestión de cada equipo. |
Apéndice
Localización
- Página 60-62 (nueva versión del manual).
- Página 79-80 (versión anterior del manual).
Se han añadido nuevas referencias bibliográficas.
Se han actualizado la información, recursos y comunidad profesional; y las redes sociales y profesionales.
Enlaces
Se han añadido enlaces de interés en las siguientes secciones:
Versión 3.07
Errata (DoR)
Localización
- Página 20.
| y la definición de hecho (DoR). |
| y la definición de hecho (DoD). |
Enlace a vídeo explicativo del gráfico burn down
Localización
- Página 68.
| https://www.youtube.com/watch?v=alafvKVTICA. |
| https://www.youtube.com/watch?v=hveuhx7rZgw. |
Versión 3.06 y corregidas en la 3.07
Revisión del sprint
Localización
- Página 52.
| Reunión realizada al final del sprint para comprobar el incremento. Lo habitual es que dure una o dos horas; en caso de incrementos de especial relevancia o complejidad, puede extenderse hasta 4 como máximo. Asiste todo el equipo scrum y todas las personas implicadas en el proyecto que lo deseen. Esta reunión marca, a intervalos regulares, el ritmo de construcción, y la trayectoria que va tomando la visión del producto. Al ver y probar el incremento, el propietario del producto y el equipo en general obtienen feedback relevante para revisar la pila del producto. Se identifican las historias de usuario que se pueden considerar «hechas» («done») y las que no. Reunión realizada el final del sprint para enseñar el incremento y recoger sugerencias. |
Por la experiencia y sugerencias de la comunidad profesional Scrum Manager, no es necesario considerar "hechas" (done) las historias en esta reunión, y en muchas circunstancias puede resultar aconsejable no vincularlo a la revisión del sprint.
| Reunión realizada al final del sprint para enseñar el incremento y recoger sugerencias. Lo habitual es que dure una o dos horas; en caso de incrementos de especial relevancia o complejidad, puede extenderse hasta 4 como máximo. Asiste todo el equipo scrum y todas las personas implicadas en el proyecto que lo deseen. Esta reunión marca, a intervalos regulares, el ritmo de construcción y la trayectoria que va tomando la visión del producto permitiendo un espacio donde recibir sugerencias de los interesados que permitan seguir evolucionando el producto. El equipo presenta las historias de usuario que planificaron, las que han desarrollado, las que no y los impedimentos encontrados. Es importante situar las expectativas de los interesados en la realidad al principio de la reunión. |
Protocolo recomendado:
|
Protocolo recomendado:
|
Resultados del scrum diario
Localización
- Página 50. Capítulo: Aprendiendo las prácticas estándar > Artefactos > Otros artefactos > Tabla del scrum diario > Resultados.
| Información del avance de cada miembro del equipo |
| Identificación de posibles necesidades e impedimentos. |
Versión 3.052 y corregidas en la 3.06
Comprometidos e implicados
Localización
- Página 29.
| Comprometidos e implicados
Durante el desarrollo del proyecto son muchas las personas que intervienen y aportan valor al desarrollo, si bien con diferentes niveles de compromiso y responsabilidad, en función de lo cual se suele diferenciar entre «comprometidos» e «implicados».
En círculos de scrum es frecuente llamar a los primeros (sin ninguna connotación peyorativa) «cerdos» y a los segundos «gallinas». El origen de estos nombres está en la siguiente historia, que ilustra de forma gráfica la diferencia entre compromiso e implicación en el proyecto: Una gallina y un cerdo paseaban por la calle. La gallina preguntó al cerdo: -¿Quieres abrir un restaurante conmigo? El cerdo consideró la propuesta y respondió: - Sí, me gustaría. ¿Cómo lo llamaríamos? - Huevos con Jamón. El cerdo se detuvo, hizo una pausa y contestó: - Pensándolo mejor, creo que no voy a abrir un restaurante contigo. Yo estaría realmente comprometido… mientras que tu estarías sólo implicada. |
Localización
- Página 75.
Se ha revisado el texto del diagrama de árbol para retrospectiva.
Participación del propietario del producto en la retrospectiva
Localización
- Página 53.
Se eliminan las consideraciones acerca de la conveniencia de la participación en las retrospectivas del propietario del producto cuando no se trata de un miembro implicado, por encontrarnos más en una implementación más de ingeniería concurrente que de "Agilidad" con condiciones contractuales que pudieran desaconsejarlo.
Se elimina por ser una consideración que excede el ámbito de formación estándar del marco scrum.
Actualización de contenido en el tema de estimación ágil: NoEstimates
Se actualiza el tema de estimación ágil, reflejando algunas de las críticas y alternativas más frecuentes al uso de puntos de historia. Éstos siguen formando parte del temario que explica el marco estándar de scrum, y las alternativas se han incluido entre las «Prácticas para flexibilizar scrum», en dos apartados:
- Estimación sin puntos de historia.
- #NoEstimates.
En ambos casos se destacan ventajas e inconvenientes, explicando en qué contextos pueden resultar más adecuados.
Versión 3.051 y corregidas en la 3.052
Mejora de la definición del gráfico de producto o burn up chart
Localización
- Capítulo: Aprendiendo las prácticas estándar > Artefactos > Otros artefactos.
| ... si el gráfico de avance mide lo que falta, el de producto mide cuánto se ha construido o completado. |
| El gráfico de producto o gráfico “burn up” es una herramienta de planificación propia del propietario de producto, que presenta visualmente la evolución previsible del producto. |
Desvinculación de la validación de historias de usuario con la reunión de revisión del sprint
Localización
- Página 47 > descripción de la reunión de revisión del sprint.
| Esta reunión marca, a intervalos regulares, el ritmo de construcción, y la trayectoria que va tomando la visión del producto. Al ver y probar el incremento, el propietario del producto y el equipo en general obtienen feedback relevante para revisar la pila del producto. Se identifican las historias de usuario que se pueden considerar «hechas» («done») y las que no. |
| Esta reunión marca, a intervalos regulares, el ritmo de construcción, y la trayectoria que va tomando la visión del producto permitiendo un espacio donde recibir sugerencias por parte de los interesados que permitan seguir evolucionando el producto. |
Falta cierre de interrogación
Localización
- Página 41.
| ¿Por qué es valioso este sprint |
| ¿Por qué es valioso este sprint? |
En la versión 3.05 y corregidas en la 3.051
Actualización: ISO 15504 ha sido reemplazado por ISO 33000
Localización
Capítulo: Introducción -> El Manifiesto Ágil
- Dice "...SPICE (proyecto inicial de ISO 15504)..." Debe decir "...SPICE (proyecto inicial de ISO 15504, a su vez precursor de ISO 15504)"
Año en la nota bibliográfica de Extreme Programming Explained
- Tiene como año de publicación 2000 y debe tener 1999
Enlace a FAQ de scrummanager.com
Localización
Apéndices.
- El enlace está desfasado.
Supresión del término grooming
- Para aludir a la preparación o refinado de la pila de producto se elimina como sinónimo "grooming" al quedar en desuso en la comunidad angloparlante por las connotaciones que le ha dado al término la acepción de abuso de menores.
Actualización de la imagen del marco de scrum
Localización
Pág. 27 (versión pdf)
- Actualización del nombre del rol del equipo de desarrollo por desarrollador.
Uso homogéneo del término auto-gestión en relación al modo organizativo del equipo scrum
- Se mantiene el término auto-organización al hacer referencia a las fuentes que se refieren a los equipos ágiles como "auto-organizados".
- Origen de scrum. Los autores de la definición de los equipos scrum (Nonaka y Takeuchi "The New New Product Development Game") usan la denominación "self-organizing project teams"
- Manifiesto ágil. El manifiesto ágil prefiere también el término "self-organizing" ("The best architectures, requirements, and designs emerge from self-organizing teams")
- En el resto se adopta la tendencia a preferir el término auto-gestionados. (Scrum Manager recomienda abordar el grado de autonomía de los equipos de forma coherente con la cultura de la orgnanización. V. Scrum Level)
En la versión 3.04 y corregidas en las 3.05
Fecha del Manifiesto Ágil
Localización
Capítulo: Introducción -> El Manifiesto Ágil
- Dice "En marzo de 2001" y debe decir "En febrero de 2001"
En la versión 3.03 y corregidas en la 3.04
Imagen ejemplo pila del sprint
Localización
Capítulo: Artefactos -> Pila del sprint. La imagen de ejemplo resulta confusa por indicar erróneamente en la cabecera de las columnas de tareas "Pila del producto"
En la versión 3.02 y corregidas en la 3.03
Participación de Product Owner en la reunión retrospectiva
Localizaciones
- Figura "LAS REGLAS DE SCRUM"
- Capítulo Eventos -> Retrospectiva del sprint. Actualiza en su descripción la recomendación de la participación del product owner:
"En la retrospectiva del sprint participan: el equipo de desarrollo, el scrum master y el propietario de producto. Es importante que el propietario de producto se considere “equipo” más que “cliente”. Que la persona que desempeña el rol sea participativa y conocedora de los principios y valores de scrum. Si esto no fuera así, el scrum master debe actuar como facilitador para lograr su compromiso y participación o, si la situación lo requiere, no incluirlo en la retrospectiva."
WIP
Localización
Capítulo: Prácticas para flexibilizar scrum - kanban- (página 71 de la edición impresa y 64 de la edición PDF)
En el cuarto párrafo dice "WIP (work in progress)" y debe decir "WIP (work in process)
Rol interesados
Localización
Capítulo: Prácticas para flexibilizar scrum - kanban- (página 31 de la edición impresa y 27 de la edición PDF)
En el esquema de componentes del ciclo estándar de scrum falta en el apartado de roles la mención de los "interesados".
En la versión 3.01 y corregidas en la 3.02
DoD / DoR
Localización
Capítulo: Artefactos, "Otros artefactos"
Las definiciones de "Definition of Ready (DoR)" y "Definition of Done (DoD) están cruzadas.