Scrum: la guía extendida

La Guía Scrum es un documento breve. Demasiado sucinto, quizás. En su última versión, de 2020, la Guía ocupa tan solo 13 páginas. De un lado, esto quiere decir que los que utilizamos Scrum tendremos libertad para dotarlo de contenido. De otro lado, sin embargo, la falta de detalles o ejemplos prácticos puede dejar a algunos equipos “en el limbo”, sin saber cómo interpretar lo que la Guía quiere decir. Por ello, hemos creado esta Guía Scrum extendida, con todo lo que necesitas saber sobre Scrum, expresado en un lenguaje llano, pero siempre siendo fieles a la Guía oficial.

 

1. ¿Qué es Scrum?

Scrum es un framework ligero y empírico para la creación de un producto complejo, que nos permite obtener un Incremento de este durante o al final de cada Sprint o ciclo corto de desarrollo. Scrum es lo que la Guía Scrum dice que es: tan sencillo y liviano a priori como difícil de dominar.

El Sprint es el corazón de Scrum: contiene a los diferentes eventos, en los cuales se crean o revisan los artefactos, y a lo largo de este se produce todo el trabajo de desarrollo, incluyendo las pruebas que sean necesarias e, incluso, el despliegue o puesta en producción del Incremento obtenido. El trabajo es realizado por el Equipo Scrum, que es un equipo pequeño, de un máximo de entorno a diez miembros, que se compone por un Scrum Master, un Product Owner y los Desarrolladores.

 

1.1. Scrum como framework ligero

Scrum no es una técnica, un método o un proceso predefinido, con pasos que puedan aplicarse de principio a fin. Al contrario, es el continente en el que aplicar todo ese conjunto de técnicas. Scrum nos da “las reglas del parchís”, pero no nos dice cómo o con qué tácticas ganar. Esto es potestad de cada Equipo Scrum, que irá creando su propio proceso, con Scrum como framework base.

Este framework esencial se integra por:

• Tres responsabilidades (antes llamadas “roles”): Scrum Master, Product Owner y desarrolladores.
• Cinco eventos: el Sprint (que contiene al resto de eventos, que son reuniones o ceremonias), el Sprint Planning, el Daily Scrum, la Sprint Review y la Retrospectiva del Sprint.
• Tres artefactos y sus compromisos asociados: el Product Backlog, el Sprint Backlog y el Incremento de producto.
• Los valores Scrum (compromiso, foco, sinceridad o apertura, respeto y coraje) y reglas como el timebox, que envuelven y dan sentido a dichas responsabilidades, eventos y artefactos.

Decimos que es un marco de trabajo ligero precisamente por la brevedad de los elementos que lo componen y de la propia Guía Scrum, a la que antes aludíamos. No estamos ante un manual cerrado y pormenorizado sobre cómo crear software. Scrum solamente define las reglas del juego, el tablero en el que jugar.

Hay que tener en cuenta que, si alteramos u omitimos los elementos del framework, ya no estaremos haciendo Scrum, sino otra cosa. Esto afectará a la probabilidad de que hagamos working software de calidad con éxito. Continuando con el símil, si nos saltamos las reglas del parchís, ya no estaremos jugando al parchís, sino a otro juego distinto e inventado. Es habitual encontrarse con equipos que dicen hacer Scrum con “adaptaciones”, “porque a ellos les funciona mejor así”; no se dan cuenta de que, con esos ajustes, simplemente han dejado de utilizar Scrum y han renunciado a sus beneficios potenciales.

 

1.2. Scrum y el empirismo

Scrum se sustenta en el empirismo, esto es, en la toma de decisiones basada en aquello que ya ha sucedido. El típico grafico de Gantt, creado con todo lujo de detalles y que nunca se cumple, no tiene ningún sentido. En Scrum, nuestras predicciones deben basarse en el rendimiento que observamos en el pasado. Nada de adivinar el futuro. Por ejemplo, si un Equipo Scrum tuvo una velocidad de 10 puntos en el primer Sprint y de 12 en el segundo, sería razonable estimar que, en el tercer Sprint, la velocidad será de entre 10 y 12 puntos.

El empirismo, aplicado a Scrum, se sustenta en tres pilares:

• Transparencia. Todos los usuarios de Scrum deben tener a su disposición y comprender el estado de los artefactos.

• Inspección. Los artefactos han de poder auditarse con frecuencia, con objeto de identificar variaciones no deseadas.

• Adaptación. En caso de que se detecten variaciones, es el momento de corregir el curso.

Por ejemplo, si, al presentar el Incremento de producto en la Sprint Review, los stakeholders detectan carencias en el mismo, o apuntan a cambios de mercado, el Product Backlog podrá ser convenientemente adaptado.

 

1.3. Scrum como marco de trabajo para desarrollar productos complejos

Scrum no es adecuado para cualquier contexto. En situaciones de caos, o de carácter simple o complicado, Scrum no tiene porqué funcionar y puede haber otros modelos más pertinentes.

Scrum brilla en entornos complejos, es decir, donde las incertidumbres superan a las certidumbres y es preciso que la solución emerja a medida que avanzamos. 

Esta clasificación de contextos es la auspiciada por el modelo de Cynefin.

 

2. Historia de Scrum

El germen de Scrum tiene su origen en el artículo The new new development game, escrito por los profesores japoneses Hirotaka Takeuchi y Ikujiro Nonaka, publicado en Harvard Business Review en 1986. En este trabajo aluden a cómo empresas americanas y japonesas habían descubierto una forma de trabajar holística, en fases solapadas, contrapuesta a la tradicional o secuencial, y utilizaban el rugby como metáfora. Se referían a cómo los jugadores avanzaban por el terreno de juego como una unidad: «as in rugby, the ball gets passed within the team as it moves as a unit up the field». Esta era una mención indirecta a la posición de rugby denominada Scrum o melé.

 

Este artículo fue retomado siete años después, en 1993, por Jeff Sutherland y su equipo en la empresa Easel, donde trasladaron sus conceptos, orientados al manufacturing, al ámbito de la creación de software. En OOPSLA 1995 Sutherland y Ken Schwaber presentaron SCRUM development process, cuyo paper original puede consultarse aquí. Scrum, por las propias experiencias profesionales de Sutherland, nace como contraposición a la metodología waterfall, como forma alternativa de gestionar equipos de desarrollo más eficientemente y de construir mejores productos de software. Sutherland y Schwaber crearon también la Guía Scrum, que es algo así como “la Biblia de Scrum”. Scrum se ha aplicado también en ámbitos diferentes al software, como el hardware, las ventas o el marketing, si bien es en el desarrollo de software donde su aplicación sobresale.

Por cierto, si deseas profundizar sobre la historia de Scrum, quizás te interese el libro Scrum, The Art of Doing Twice the Work in Half the Time (Scrum: El revolucionario método para trabajar el doble en la mitad de tiempo), escrito por el co-creador de Scrum Jeff Sutherland. Personalmente no lo recomiendo: está lleno de “batallitas” redundantes de escaso valor didáctico y a veces parece que lo que más preocupa a Sutherland es dejar claro que él inventó Scrum. Sé que otros agilistas sí que recomiendan esta lectura… Para gustos, los colores.

 

 

2.1. ¿Por qué usar Scrum? Los resultados de Scrum

Desde los inicios, Scrum demostró enormes aumentos de productividad, de hasta el 800% según Sutherland. La fórmula de equipos de desarrollo pequeños, multifuncionales y autónomos funcionaba. Conceptos como el de Sprint, Product Backlog o Daily Scrum se han popularizado enormemente gracias a los números.

Traigo a colación las métricas de la empresa Genomica -empresa de bioinformática y que fue una de las pioneras en la adopción de Scrum, allá por el año 2000- antes y después de implantar Scrum, que hablan por sí solos.

Medida	Waterfall	Scrum
Esfuerzo	x10	x1
Velocidad	x1	x7
Satisfacción del cliente	Pobre	Excelente

 

2.2. Principales organizaciones relacionadas con Scrum

El uso de Scrum ha sido promocionado por diversas organizaciones, entre las que destacan dos: Scrum Alliance y Scrum.org. En particular, Scrum.org ofrece certificaciones de reconocido prestigio y que no caducan para Scrum Master y Product Owner. Destacamos las certificaciones Professional Scrum Master I y Professional Product Owner I, enormemente extendidas en el sector.

Puedes consultar nuestra guía de preparación de la certificación PSM I, así como acceder aquí a nuestro simulador de examen de certificación para Scrum Master.

 

2.3. Scrum y Agile

Scrum es una de las corrientes dentro de Agile, quizás la principal o más conocida, pero ni mucho menos la única. Dicho de otra manera, Agile incluye a Scrum y a otras muchas técnicas y metodologías como Extreme Programming, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development y Pragmatic Programming. En 2001, 17 representantes de estas formas alternativas de hacer software se reunieron para acordar una serie de bases comunes en el Agile Manifesto o Manifiesto por el Desarrollo Ágil de Software. Con el término Agile estos líderes evitaban otros como “light” o “lightweight”, que habían sido empleados hasta entonces.

 

2.4. Scrum a escala

A medida que grandes organizaciones implantaban Scrum, han surgido diversos frameworks de escalado como Nexus, SAFe o LeSS. Por ejemplo, un Nexus (“nodo”) comprende entre tres y nueve equipos Scrum, contempla un nuevo rol, el Equipo de Integración Nexus, e instaura el refinamiento como ceremonia obligatoria.

 

3. Los valores Scrum

Para implementar Scrum, es necesario “vivirlo”, dotarse del espíritu que Scrum requiere. Este suele ser uno de los principales obstáculos a la hora de implantar Scrum con éxito en las organizaciones.

Scrum propone cinco valores: compromiso, foco, sinceridad o apertura, respeto y coraje.

Puedes leer más sobre los valores Scrum aquí.

 

4. El Equipo Scrum

La actualización 2020 de la Guía Scrum ha eliminado la palabra “roles”, que se reemplaza con “responsabilidades” (del inglés “accountabilities”, que tiene mala traducción al español). Así, los tres roles tradicionales pasan a ser tres conjuntos de responsabilidades, que definen el papel del Scrum Master, del Product Owner y de los Desarrolladores.

Además de este cambio nominal, se definen más claramente cuáles son esas responsabilidades. En la versión de la Guía de 2017 era necesario repasar y destilar estas de su lectura; ahora, en cambio, se recogen de manera más concisa y difícil de obviar.

Antes de entrar a comentar las tres responsabilidades, convine resaltar que la Guía también asigna responsabilidades al Equipo Scrum como tal, a todos sus miembros:

• El Equipo Scrum es responsable de todas las actividades relacionadas con el producto: I+D, mantenimiento, experimentos, testing, colaboración con stakeholders, etc.

•  El Equipo Scrum es responsable de crear un Incremento de Producto valioso y útil en cada Sprint.

• El Equipo Scrum se responsabiliza de crear una Definición de Hecho acorde al producto en cuestión, cuando esta no forme parte de los estándares de la organización.

• El Equipo Scrum predica los valores de compromiso, foco, sinceridad, respeto y coraje.

Veamos a continuación cada una de las responsabilidades definidas en la Guía.

 

4.1. El Scrum Master

Le corresponde implantar Scrum tal y como se define en la Guía Scrum. Es responsable de:

• La efectivad del Equipo Scrum. Para aumentar la efectividad del Equipo, el Scrum Master crea las condiciones en las que aquel pueda mejorar las practicas que utiliza, dentro de Scrum como framework.

• Dar servicio al Equipo Scrum: entrenando al Equipo en autogestión y multifuncionalidad; ayudando a que el Equipo permanezca focalizado en torno a la creación de un Incremento de alto valor y que cumple con la Definición de Hecho; gestionando la eliminación de impedimentos; asegurándose de que los eventos son productivos y respetan el timebox.

• Dar servicio al Product Owner: ayudando a encontrar técnicas para la definición del Product Goal y efectiva gestión del Product Backlog; ayudando al Equipo a entender la necesidad de formular los elementos del Product Backlog con claridad; ayudando a establecer un proceso empírico de planificación de producto; facilitando colaboración con stakeholders según sea necesario.

• Dar servicio a la organización: liderando y formando a la organización en Scrum; planificando la implantación de Scrum; ayudando a trabajadores y stakeholders a entender y utilizar Scrum; eliminando barreras entre stakeholders y los Equipos Scrum.

Puedes leer todo sobre el Scrum Master en este artículo.

 

4.2. El Product Owner o Propietario del Producto

Es el encargado de maximizar el valor del producto en el que trabaja el Equipo Scrum y de gestionar el Product Backlog. Asimismo, se responsabiliza de:

• Definir y comunicar el Product Goal u Objetivo de Producto.

• Crear y comunicar los elementos del Product Backlog.

• Ordenar los elementos del Product Backlog.

• Asegurarse de que el Product Backlog es transparente y entendido por el resto del Equipo Scrum o stakeholders.

• Asegurarse de que los asistentes a la Sprint Planning están preparados para hablar de los elementos del Product Backlog más importantes, en relación con el Product Goal. El Product Owner propone la funcionalidad que puede aumentar el valor del producto en el presente Sprint.

El Product Owner puede delegar estas actividades en otros, pero sigue siendo responsable.

Puedes leer todo sobre el Product Owner en este artículo.

 

4.3. Los Desarrolladores

Son quienes realizan el trabajo del Sprint y se compromete a crear el Incremento. Se responsabilizan de:

• Crear el Sprint Backlog.

• Seguir la Definición de Hecho.

• Adaptar el Sprint Backlog a diario, valorando el progreso hacia la consecución del Sprint Goal.

• Considerar a cada miembro del Equipo como profesionales autónomos y responsables.

 

5. Los eventos Scrum

Scrum contempla cinco eventos: el Sprint y cuatro reuniones o ceremonias que han de celebrarse en cada Sprint. Se dice, por tanto, que el Sprint contiene a los otros cuatro eventos, que son la Sprint Planning, el Scrum Diario, la Sprint Review y la Retrospectiva del Sprint.

• Todos los eventos tienen un time-box, es decir, una duración máxima predeterminada. En todo caso, las ceremonias concluyen una vez que su objetivo se haya cumplido, sin necesidad de agotar ese time-box.

• Las ceremonias son oportunidades para inspeccionar y adaptar los artefactos, favoreciendo la transparencia en torno a estos.

• Los eventos sirven también para crear regularidad y minimizar la necesidad de reuniones no contempladas por el framework. Lo normal será que los eventos siempre tengan lugar a la misma hora, con objeto de reducir la complejidad.

 

5.1. El Sprint

Es un ciclo corto de desarrollo encaminado a la obtención de un Incremento de producto, y cuya duración no debe exceder de un mes.

Puedes leer todo sobre el Sprint en Scrum aquí.

 

5.2. Sprint Planning

Es la ceremonia que da comienzo al Sprint, en la que se crea el Sprint Goal y se selecciona y planea el trabajo a realizar durante aquel.

Puedes leer todo sobre la Sprint Planning aquí.

 

5.3. Daily Scrum

Reunión por y para los Desarrolladores, en la que inspeccionan el progreso hacia la consecución del Objetivo del Sprint y adaptan o actualizan el Sprint Backlog.

Puedes leer todo sobre la Daily aquí.

 

5.4. Sprint Review

Ceremonia en la que el Equipo Scrum y los stakeholders colaboran respecto al resultado del Sprint, inspeccionando el Incremento y determinando futuras adaptaciones.

Puedes leer todo sobre la Sprint Review aquí.

 

5.5. Sprint Retrospective

Evento con el que concluye el Sprint. La Retrospectiva constituye una oportunidad para que el Equipo Scrum se inspeccione a sí mismo en lo relativo a procesos, interacciones y herramientas.

Puedes leer todo sobre la Sprint Retrospective aquí.

 

6. Los artefactos Scrum

Los artefactos Scrum representan trabajo o valor y contribuyen a generar transparencia, dado que pueden ser inspeccionados y adaptados.

Los artefactos son tres: el Product Backlog o Pila de Producto, el Sprint Backlog y el Incremento de producto. Cada uno de los artefactos tiene un compromiso asociado, como veremos en el apartado 7.

 

6.1. El Product Backlog

Es una lista ordenada de todo aquello conocido que el producto puede necesitar. Es gestionado por el Product Owner.

Puedes leer todo sobre el Product Backlog aquí.

 

6.2. El Sprint Backlog

Es el plan de trabajo de los Desarrolladores para el Sprint, que incluye: el Sprint Goal u Objetivo del Sprint, los elementos del Product Backlog seleccionados para el Sprint, así como el plan de ejecución para crear el Incremento. Visualmente, suele recogerse en un tablero Scrum o Scrum board.

Puedes leer todo sobre el Sprint Backlog aquí.

 

6.3. El Incremento

Es la iteración de producto que ha de obtenerse en cada Sprint, que incluye tanto la funcionalidad añadida durante el Sprint como la ya creada en los Sprints anteriores.

Puedes leer todo sobre el Incremento de producto aquí.

 

7. Los compromisos en Scrum

La Guía Scrum 2020 lleva el valor compromiso a su máxima expresión (para un repaso de los valores Scrum, puedes leer este artículo) y recalca que dicho compromiso no es con tareas, sino con objetivos. En Scrum, compromiso significa dar lo mejor de nosotros mismos y como equipo para conseguir el Sprint Goal (a corto plazo) y el Product Goal (a largo plazo), respetando la Definición de Hecho.  La palabra compromiso (commitment o commit) aparece en la Guía 2020 en nueve ocasiones, frente a dos menciones en la de 2017.

A fin de dotar al framework de una estructura que lo haga más inteligible, la Guía asocia un compromiso a cada uno de los artefactos.

• Para el Product Backlog o Pila de Producto, el compromiso es el Product Goal u Objetivo de Producto. El Product Goal es una meta a largo plazo para el Equipo Scrum, contenida en el Product Backlog, y que guía a este, dándole propósito. Su formulación compete al Product Owner. El Equipo solo debe abordar un Product Goal en cada momento, y conseguirlo o abandonarlo antes de pasar al siguiente. Puedes leer más sobre el Product Goal u Objetivo del Producto y sus implicaciones en este artículo.

• Para el Sprint Backlog, el compromiso es el Sprint Goal u Objetivo del Sprint. El Sprint Goal es una meta específica para el Sprint, al que da sentido y coherencia, toda vez que proporciona flexibilidad respecto al alcance o funcionalidades previstas. Se crea durante la Sprint Planning -en la que, como explicita la Guía Scrum 2020, es el primer tema que debe comentarse- por parte de todo el Equipo Scrum, añadiéndose al Sprint Backlog. El Sprint Goal es un compromiso por parte de los desarrolladores. Puedes leer más sobre el Sprint Goal en este post.

• Para el Incremento, el compromiso es la Definición de Hecho. La Definición de Done describe el estado del Incremento de Producto cuando este cumple con los estándares de calidad requeridos para tal producto. Si la Definición de Hecho no es definida por la organización, el Equipo Scrum debe dotarse de una (este es un cambio introducido por la Guía 2020, puesto que, hasta entonces, el Equipo de Desarrollo era el que debía crearla). Los desarrolladores deben adherirse a ella cuando trabajan en el Incremento durante el Sprint. Puedes leer más sobre la Definición de Hecho en este post.

En la siguiente tabla resumimos a quien compete la creación y adhesión a cada uno de los compromisos:

 

Compromiso	¿Quién lo crea?	¿Quién se adhiere?
Product Goal, asociado al Product Backlog	El Product Owner	El Equipo Scrum
Sprint Goal, asociado al Sprint Backlog	El Equipo Scrum	Los desarrolladores
Definición de Hecho, asociada al Incremento	El Equipo Scrum (si no disponible en la organización)	Los desarrolladores

 

Este esquema hace que los elementos del framework encajen mejor. Hasta la actualización 2020 de la Guía, el Objetivo del Sprint y la Definición de Terminado se quedaban “colgando”, en tierra de nadie, de manera que muchos equipos ni si quiera los aplicaban. Ahora se formulan de forma nítida, y se añade el Produt Goal para armar este modelo de tres artefactos y tres compromisos vinculados.

Estos compromisos contribuyen a aumentar la transparencia de los artefactos y el foco en torno a su estado y progreso. Refuerzan el empirismo y los valores Scrum, tanto para el Equipo Scrum como para los stakeholders.  

 

8. «Mitos y leyendas» sobre Scrum

En este apartado queremos «desmontar» algunos mitos y leyendas urbanas sobre Scrum.

👉 Mito 1: “El Product Owner se dedica a tomar requerimientos de los stakeholders y a escribir tickets de JIRA”. NO. El Product Owner es un Product Manager en sentido amplio:
–  estrategia de producto
–  discovery
–  delivery
–  validación con datos
–  …

👉 Mito 2: «Scrum solo sirve para hacer delivery de features». El Sprint Goal y sobre todo el Product Goal ponen el énfasis en outcomes para el cliente/organización. No en output/features. Es más, Scrum funciona perfectamente y debe ser complementado con:
– técnicas de discovery y experimentación
– métricas de valor
– herramientas para fijar objetivos (como OKRs, Product Goal canvas, etc.).
– …

👉 Mito 3: «Hay que esperar al final del Sprint (a la Sprint Review) para poner cosas en producción». Tal y como un elemento del Product Backlog esté terminado, podemos ponerlo en producción. No hay que esperar. Lo importante será tener la infraestructura para poder hacer, si es posible, continuous deployment.

👉 Mito 4: «Scrum es muy rígido y no permite alterar el alcance del Sprint». El alcance del Sprint puede y debe alterarse. Es una negociación/conversación entre Product Owner y Desarrolladores. Lo que no queremos hacer es poner en peligro el Sprint Goal. Pero podemos acordar “meter” y “sacar” funcionalidad. Claro.

👉 Mito 5: «En Scrum/Agile no se planifica». Por supuesto que se planifica. Pero la planificación no la entendemos como un documento (p. ej., Gantt chart). Planificar es una actividad, que empieza con la Sprint Planning (plan para el Sprint), sigue en la Daily (plan para el día), se revisa en la Sprint Review, etc. Las fechas de entrega se pueden proyectar. Y ajustar a medida que avanzamos.

 

9. La actualización 2020 de la Guía Scrum: diferencias con la versión de 2017

La nueva Guía Scrum, que reemplaza a la de 2017, es más breve e intenta ser más concisa y menos prescriptiva (puedes leer también nuestro análisis sobre la nueva Guía Scrum). Entre los principales cambios:

• Ya no se habla de Equipo de Desarrollo, sino de “desarrolladores”. Se pone énfasis en el Equipo Scrum, que es uno solo.

• Se eliminan los roles, que pasan a ser tres “responsabilidades” específicas dentro del Equipo Scrum: los desarrolladores, el Product Owner y el Scrum Master.

• Cada artefacto tiene ahora un “compromiso” asociado: el Objetivo del Producto para el Product Backlog; el Objetivo del Sprint para el Sprint Backlog; y la Definición de Hecho para el Incremento.

• Se introduce el Produt Goal (Objetivo del Producto) como objetivo a largo plazo que da dirección al Equipo Scrum.

• El Scrum Master pasa a definirse como “verdadero líder que sirve”, y no como servant leader. Además, se subraya en el papel del Scrum Master como coach de la organización.

• Se introduce un tercer tema para la Sprint Planning: ¿Por qué este Sprint es valioso?

• Las tres preguntas ejemplificativas para la Daily se eliminan.

• Se elimina la sugerencia de que el refinamiento no supere el 10% de la capacidad del Sprint.

• Se eliminan las especificaciones sobre la Sprint Review.

• Ya no es obligatorio que al menos una mejora identificada en la Retro pase al Sprint Backlog.

• El término autoorganizado se sustituye por autogestionado.

• Se elimina mención a que el Equipo de Desarrollo se componga por 3-9 miembros. Ahora indica que, habitualmente, el Equipo Scrum se compone por 10 miembros o menos.

 

10. El futuro de Scrum

En este aparatado me aventuro a hacer algunas breves predicciones sobre el futuro de Scrum.

• La Guía Scrum 2020 pretende impulsar Scrum más allá de la industria del software. Quiere hacerlo universal y más accesible. Scrum terminará por hacerse main stream y será el framework de referencia no solo dentro de Agile, sino para crear cualquier tipo de software y casi cualquier tipo producto complejo en cualquier sector.

• Al mismo tiempo, las limitaciones de Scrum como marco de trabajo base serán cada vez más obvias. Scrum solo nos da unas reglas de mínimos, dentro de cuyos límites los equipos tienen una amplia flexibilidad para adoptar las practicas que mejor se adecuen a su contexto. Los equipos tienen la necesidad de profundizar y utilizar otras muchas técnicas, en dos frentes: 1/ la creación de productos de alto valor al menor coste posible y 2/ la gestión de equipos autónomos altamente capacitados.

• La crisis del covid-19 ha acelerado transformación digital, de modo que más y más empresas harán de la tecnología su core y necesitarán de equipos de producto que utilicen Scrum y Agile. A su vez, frente al tradicional entorno de trabajo físico y colaborativo, cuyo símbolo ha sido la “pizarra de post-its” o tablero Scrum o Kanban, se impone la necesidad de fomentar el trabajo en remoto y de fomentar la creatividad en entornos de trabajo “virtuales”.

• Actualmente, la agilidad está evolucionando más y más hacia el foco en resultados (outcomes), dejando atrás el anti-patrón de “entregar más features a más velocidad”. El modelo operativo de producto o modelo de producto subraya la importancia de la intersección entre Scrum y Product Management: el product discovery y la visión y estrategia de producto, así como la responsabilidad del Product Owner (Product Manager), pasan definitivamente a un primer plano.

 

Todas las secciones de la Guía Scrum Extendida

Responsabilidades:

• Scrum Master
• Product Owner

Eventos:

• Sprint
• Sprint Planning
• Daily Scrum
• Sprint Review
• Sprint Retrospective

Artefactos:

• Product Backlog
• Sprint Backlog
• Incremento

Compromisos:

• Product Goal
• Sprint Goal
• Definición de hecho