Latest revision as of 13:48, 17 June 2024

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).

Dice:
o al simple uso de técnicas de gestión visual kanban para mantener un flujo continuo de tareas.

Nueva redacción:
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).

Dice:
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.

Nueva redacción:
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).

Dice:
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).

Nueva redacción:
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).

Dice:
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»: En un «grupo de trabajo» las personas tienen una asignación específica de tareas, responsabilidades, y siguen un proceso o pautas de ejecución. Los operarios de una cadena forman un grupo de trabajo; aunque tienen un jefe común, y trabajan en la misma organización, cada uno responde de forma individual. Un «equipo» tiene espíritu de colaboración y un propósito común: conseguir el mayor valor posible para la visión del cliente. Los desarrolladores se autogestionan para trabajar y responder de forma conjunta. No hay un gestor para delimitar, asignar y coordinar las tareas. Son los desarrolladores los que se coordinan. Todos aportan y colaboran con el propietario del producto en el desarrollo de la pila del producto, participan en la toma de decisiones, y respetan las opiniones y aportes de los demás. Comparten el objetivo de cada sprint y la responsabilidad del logro. Por último, todos están familiarizados con scrum.

Nueva redacción:
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»: En un «grupo de trabajo» las personas tienen una asignación específica de responsabilidades, y siguen un proceso o pautas de ejecución. Aunque el grupo trabaje en la misma organización, cada quien responde de forma individual. Un «equipo» tiene espíritu de colaboración y un propósito común: conseguir el mayor valor posible para la visión del cliente. Los desarrolladores se autogestionan para trabajar y responder de forma conjunta. No hay un gestor para delimitar, asignar y coordinar el trabajo. Son los desarrolladores los que se coordinan. Todos aportan y colaboran con el propietario del producto en el desarrollo de la pila del producto, participan en la toma de decisiones, y respetan las opiniones y aportes de los demás. Comparten el objetivo de cada sprint y la responsabilidad del logro. Por último, todos están familiarizados con scrum.

Artefactos más extendidos

Localización

Página 29 (nueva versión del manual).
Página 37 (versión anterior del manual).

Dice:
* 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 sprint / sprint backlog: Refleja los requisitos desde el punto de vista de los desarrolladores. Es una lista de los trabajos a realizar durante un sprint (→ «Eventos») para generar el «incremento» previsto. Incremento: resultado de cada sprint.

Nueva redacción:
* 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. Pila del sprint / sprint backlog: lista de trabajo que van a realizar los desarrolladores durante el sprint. (→ «Unidades de trabajo») Incremento: resultado de cada sprint. Es una parte del producto que funciona correctamente; debe estar probada y lista para usarse. 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).

Dice:
* 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 producto o burn up chart: si el gráfico de avance mide lo que falta, el de producto mide cuánto se ha construido o completado. Definition of Ready (DoR): acuerdo que define cuándo una historia de usuario se considera «lista» para ser descompuesta en tareas, estimada e incluida en un sprint. Definition of Done (DoD): acuerdo sobre los criterios para considerar que una parte del trabajo (tarea, historia...) está terminada.

Nueva redacción:
* 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. Gráfico de producto o burn up chart: si el gráfico de avance mide lo que falta, el de producto mide cuánto se ha construido o completado. Definition of Ready (DoR): un acuerdo que define cuándo una historia de la pila del producto está «listo» («ready») para incluirlo en un sprint. Definition of Done (DoD): acuerdo sobre los criterios para considerar que una parte del trabajo (tarea, historia…) está terminada. 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).

Dice:
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.

Nueva redacción:
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.

Dice:
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: Debe incluir sólo la información necesaria: Lista de tareas. Persona responsable de cada tarea. Estado en el que se encuentra y «esfuerzo» que queda para completarla. Debe servir de medio para registrar, en cada reunión diaria del sprint, el «esfuerzo» que le queda a cada tarea. Debe facilitar la consulta y la comunicación diaria y directa del equipo.

Nueva redacción:
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: Debe incluir sólo la información necesaria: Meta del sprint. Lista de historias o tareas. Persona que se ha auto-asignado, en principio, esa unidad de trabajo. Estado en el que se encuentra; cuánto queda para completarla. Debe servir de medio para registrar, en cada reunión diaria del sprint, el «esfuerzo» que le queda a cada unidad de trabajo. Debe facilitar la consulta y la comunicación diaria y directa del equipo.

Eventos

Localización

Página 34 (nueva versión del manual).
Página 44 (versión anterior del manual).

Dice:
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.

Nueva redacció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).

Dice:
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: Qué se entregará al terminar el sprint. Cómo se conseguirá el incremento, estimando el tiempo de trabajo y los requisitos necesarios.

Nueva redacción:
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: Qué se entregará al terminar el sprint. Cómo se conseguirá el incremento, estimando con puntos de historia o como el equipo considere los requisitos necesarios.

Localización

Página 36 (nueva versión del manual).
Página 47 (versión anterior del manual).

En la tabla, en "Resultados" dice:
Pila del sprint. Duración del sprint y fecha de la reunión de revisión. Objetivo del sprint. Definición de hecho para considerar terminado el incremento del sprint.

Nueva redacción:
Pila del sprint.

Localización

Página 37-38 (nueva versión del manual).
Página 47-49 (versión anterior del manual).

Dice:
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: Realizar esta reunión antes de cada sprint. Asegurar que se cuenta con una pila del producto preparada por el propietario del producto. Ayudar a mantener el diálogo entre el propietario del producto y los desarrolladores. Asegurar que se llegue a un acuerdo entre el propietario del producto y los desarrolladores respecto a lo que incluirá el incremento. Ayudar a comprender la visión y necesidades de negocio del cliente. Asegurar que se ha realizado una descomposición y estimación del trabajo realistas, y ha considerado las posibles tareas necesarias de análisis, investigación o apoyo. Asegurar que al final de la reunión están objetivamente determinados: Los elementos de la pila del producto que se van a ejecutar. El objetivo del sprint. La pila del sprint con todas las tareas estimadas. La duración del sprint y la fecha de la reunión de revisión. La «definición de hecho» que determinará que el incremento está terminado.

Nueva redacción:
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: Que con esta reunión arranque el sprint. Asegurar que se cuenta con una pila del producto preparada por el propietario del producto. Ayudar a mantener el diálogo entre el propietario del producto y los desarrolladores. Asegurar que se llegue a un acuerdo entre el propietario del producto y los desarrolladores respecto a lo que incluirá el incremento. Ayudar a comprender la visión y necesidades de negocio del cliente. Asegurar que se ha realizado una descomposición y estimación del trabajo realistas, y ha considerado las posibles tareas necesarias de análisis, investigación o apoyo. Asegurar que al final de la reunión están objetivamente determinados: Los elementos de la pila del producto que se van a ejecutar. El objetivo del sprint. La pila del sprint con todas las unidades de trabajo estimadas, detalladas y asignadas.

Scrum diario

Localización

Página 38 (nueva versión del manual).
Página 50 (versión anterior del manual).

Dice:
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.

Nueva redacción:
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.

Dice:
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.

Nueva redacció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).

Dice:
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.

Nueva redacción:
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).

Dice:
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.

Nueva redacción:
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).

Dice:
Personas sobre procesos La inteligencia colectiva del equipo, su conocimiento tácito, es responsable directa de la calidad del producto.

Nueva redacción:
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).

Dice:
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.

Nueva redacción:
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).

Dice:
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: Gráfico burn down. Estimación de póquer. Estimación sin puntos de historia. #Noestimates. Estimación en la pared. Kanban. Trabajo en pareja. Técnicas a prueba de errores. Gráfico de producto. Diagrama de espina. Diagrama de árbol. 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.

Nueva redacción:
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: Control de avance: Gráfico de avanceo burn down chart Gráfico de producto o burn up chart. Kanban. Estimación: Estimación de póquer. Estimación en la pared. Estimación sin puntos de historia. #Noestimates. Métodos de trabajo: Diagramas para retrospectivas: espina de pez y árbol. Técnicas a prueba de errores. Trabajo en pareja. 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).

Dice:
En el eje Y representa los puntos de trabajo que aún faltan por realizar. En el eje X representa los días del sprint. 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.

Nueva redacción:
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).

Dice:
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.

Nueva redacción:
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).

Dice:
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.

Nueva redacción:
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:


Sección	Páginas	Enlaces
Desmontando la gestión de proyectos	19, 20	Vídeo explicativo: Gestión predictiva y evolutiva. Vídeo explicativo: Objetivo de la gestión predictiva y de la gestión ágil.
El ciclo scrum	24	Video explicativo: el marco de desarrollo scrum.
Roles	27	Enlace de interés: Las 5 claves de un buen product owner, Scrum Manager Podcast.
Artefactos	29, 30	Enlace de interés: Cómo crear un backlog, Scrum Manager Podcast. Enlace de interés: Definition of Done, Scrum Manager Podcast. Enlace de interés: Cómo se crea una historia de usuario, Scrum Manager Podcast. Enlace de interés: 5 características de una buena historia de usuario, ScrumManager Podcast.
Eventos	34	Enlace de interés: Eventos de scrum, Scrum Manager Podcast.
Medición y estimación ágil	43	Enlace de interés: Estimaciones ágiles, métricas de productividad, #Noestimates y otros animales.
Prácticas para flexibilizar scrum	53, 55, 56,	Vídeo explicativo: Gráfico de avance “Burn down chart”. Vídeo explicativo: Gráfico de producto “Burn up chart”. Enlace de interés: Serie Fibonacci, Scrum Manager Podcast. Vídeo explicativo: Estimación en la pared. Enlace de interés: Estimar o no estimar, Scrum Manager Podcast.

Versión 3.07

Errata (DoR)

Localización

Página 20.

Dice:
y la definición de hecho (DoR).

Nueva redacción:
y la definición de hecho (DoD).

Enlace a vídeo explicativo del gráfico burn down

Localización

Página 68.

Dice:
https://www.youtube.com/watch?v=alafvKVTICA.

Nueva redacción:
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.

Dice:
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.

Nueva redacción:
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.

Dice:
Protocolo recomendado: El equipo expone el objetivo del sprint, la lista de funcionalidades que se incluían y el incremento desarrollado. El equipo hace una introducción general del sprint y demuestra el funcionamiento de las partes construidas. Se abre un turno de preguntas y sugerencias. Esta parte genera información valiosa para que el propietario del producto y el equipo en general puedan mejorar la visión del producto.

Nueva redacción:
Protocolo recomendado: El equipo expone el objetivo del sprint, la lista de funcionalidades que se incluían y las que se han desarrollado. El equipo hace una introducción general del sprint y demuestra el funcionamiento de las partes construidas. Se abre un turno de preguntas y sugerencias. Esta parte genera información valiosa para que el propietario del producto y el equipo en general puedan mejorar la visión del producto.

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.

Dice:
Información del avance de cada miembro del equipo

Nueva redacción:
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.

Nueva redacción:
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». Comprometidos: intervienen directamente en la construcción del producto o el desarrollo del servicio. Implicados: otras partes interesadas: dirección, gerencia, comerciales, marketing, operadores del sistema que se desarrolla, soporte a usuarios, etc. 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.

Dice:
... si el gráfico de avance mide lo que falta, el de producto mide cuánto se ha construido o completado.

Nueva redacción:
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.

Dice:
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.

Nueva redacción:
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.

Dice:
¿Por qué es valioso este sprint

Nueva redacción:
¿Por qué es valioso este sprint?

Versión 3.05 y corregidas en la 3.051

Actualización: ISO 15504 ha sido reemplazado por ISO 33000

Localización

Introducción > El Manifiesto Ágil.

Dice:
...SPICE (proyecto inicial de ISO 15504)...

Nueva redacción:
...SPICE (proyecto inicial de ISO 15504, a su vez precursor de ISO 15504).

Año en la nota bibliográfica de Extreme Programming Explained

Dice:
2000.

Nueva redacción:
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ágina 27.

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 (ver 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"

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.

Se actualiza en su descripción la recomendación de la participación del product owner:

Nueva redacción:
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

Página 71 en la edición impresa.
Página 64 en la edición en PDF.
Capítulo: Prácticas para flexibilizar scrum > kanban.

Dice:
WIP (work in progress)

Nueva redacción:
WIP (work in process)

Rol interesados

Localización

Página 31 en la edición impresa.
Página 27 en la edición en PDF.
Capítulo: Prácticas para flexibilizar scrum > kanban

En el esquema de componentes del ciclo estándar de scrum falta en el apartado de roles la mención de los "interesados".

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.