Assesment Scrum
Assesment Scrum
Scrum Aristas
Scrum Team
Scrum Team
Scrum Team
Product Owner
Product Owner
Product Owner
Product Owner
Product Owner
Product Owner
Developers
Roles Developers
Developers
Developers
Developers
Developers
Scrum Master
Scrum Master
Scrum Master
Scrum Master
Scrum Master
Scrum Master
Sprint
Sprint
Sprint
Sprint
Sprint Planning
Sprint Planning
Sprint Planning
Sprint Planning
Sprint Planning
Sprint Planning
Sprint Planning
Daily Scrum
Daily Scrum
Daily Scrum
Daily Scrum
Daily Scrum
Sprint Review
Sprint Review
Sprint Review
Sprint Review
Sprint Retrospective
Sprint Retrospective
Sprint Retrospective
Sprint Retrospective
Sprint Retrospective
Sprint Retrospective
Sprint Retrospective
Sprint Retrospective
Product Backlog
Product Backlog
Product Backlog
Sprint Backlog
Sprint Backlog
Incremento
Incremento
Artefactos
Incremento
Incremento
Incremento
Incremento
Sprint Goal
Sprint Goal
ADHERENCIA MARCO
Prácticas
El equipo es auto organizados (Ellos mismos toman sus decisiones y no son dirigidos por personas externas)
El equipo tiene todas las competencias necesarias para llevar a cabo el trabajo sin depender de otras personas que no s
equipo (multifuncionales)
El equipo entrega productos de forma iterativa e incremental, cada Sprint (No Cascada).
El Product Owner ordena (prioriza) los elementos del Product Backlog, para alcanzar los objetivos de la mejor maner
El Product Owner se asegura que el Product Backog es visible, transparente y claro para todos, y que muestra aquello
equipo posiblemente trabajará a continuación.
El Product Owner se asegura que el Equipo de Desarrollo entiende los elementos del Product Backlog al nivel necesa
El Product Owner es una única persona, no un comité.
La Organización respeta las decisiones del Product Owner, en relación al contenido y priorización de la Lista del Prod
El Product Owner, es el único que define los elementos del Product Backlog.
Solo los miembros del Equipo de Desarrollo participan en la creación del Incremento.
Son autoorganizados. Nadie (ni siquiera el Scrum Master) indica al Equipo de Desarrollo cómo convertir elementos d
Backlog en Incrementos de producto potencialmente desplegables
No se reconocen títulos para los miembros de un Equipo de Desarrollo, todos son Desarrolladores, independientemen
realice cada persona.
No se reconocen subequipos en el Equipo de Desarrollo, no importan los dominios particulares que requieran tenerse
Los Miembros individuales del Equipo de Desarrollo pueden tener habilidades especializadas y áreas en las que estén
pero la responsabilidad del incremento del producto, recae en el Equipo de Desarrollo como un todo
El Tamaño del Equipo de Desarrollo está entre 3 a 9 personas (No se considera al Product Owner y Scrum Master).
El Scrum Master ayuda a encontrar técnicas para gestionar el Product Backlog de manera efectiva
El Scrum Master facilita los eventos/ceremonias/reuniones de Scrum según se requiera o necesite
El Scrum Master guia al Equipo de Desarrollo en ser autoorganizado y multifuncional
El Scrum Master gestiona/remueve impedimentos (o Escala los impedimentos) para el progreso del Equipo de Desarr
El Scrum Master lidera y guia a la organización en la adopción de Scrum.
El Scrum Master se asegura que el Product Owner conozca cómo ordenar el Product Backlog para maximizar el valo
El tiempo del Sprint no es menor a una semana y no es mayor a un mes
La duración de los Sprints es consistente a lo largo del esfuerzo de desarrollo.
Luego de iniciado un Sprint, no se realizan cambios que puedan afectar al Objetivo de este (Sprint Goal).
Se crea un incremento de producto “Terminado” utilizable y potencialmente desplegable.
La planificación tiene un máximo de 8 horas para un Sprint de un mes, para sprints más cortos es proporcionalmente
Todos los miembros del Scrum Team comparten el mismo entendimeinto de lo que significa que el incremento está te
Se cumple con el objetivo al finalizar el Sprint
El Equipo Scrum elabora y homologa un Objetivo para el Sprint que comienza (Sprint Goal)
CRUM
Assessment Valor Comentarios Anterior Variación
Nunca 0 0 0
Siempre 4 0 1
Nunca 0 0 0
Siempre 4 0 1
Nunca 0 0 0
Nunca 0 0 0
Nunca 0 0 0
Nunca 0 0 0
Nunca 0 0 0
Nunca 0 0 0
Frecuentemente 3 0 1
Nunca 0 0 0
Frecuentemente 3 0 1
Nunca 0 0 0
Nunca 0 0 0
Nunca 0 0 0
Frecuentemente 3 0 1
Siempre 4 0 1
Frecuentemente 3 0 1
Nunca 0 0 0
Frecuentemente 3 0 1
Nunca 0 0 0
Frecuentemente 3 0 1
Nunca 0 0 0
Frecuentemente 3 0 1
Nunca 0 0 0
Frecuentemente 3 0 1
Nunca 0 0 0
Frecuentemente 3 0 1
Nunca 0 0 0
Frecuentemente 3 0 1
Nunca 0 0 0
Frecuentemente 3 0 1
Nunca 0 0 0
Frecuentemente 3 0 1
Nunca 0 0 0
Frecuentemente 3 0 1
Frecuentemente 3 0 1
Nunca 0 0 0
Nunca 0 0 0
Nunca 0 0 0
Nunca 0 0 0
Nunca 0 0 0
Nunca 0 0 0
Nunca 0 0 0
Nunca 0 0 0
Nunca 0 0 0
Nunca 0 0 0
Nunca 0 0 0
Nunca 0 0 0
Nunca 0 0 0
Nunca 0 0 0
Nunca 0 0 0
Nunca 0 0 0
Nunca 0 0 0
Nunca 0 0 0
Nunca 0 0 0
Nunca 0 0 0
Nunca 0 0 0
Nunca 0 0 0
Nunca 0 0 0
Nunca 0 0 0
Nunca 0 0 0
Nunca 0 0 0
Nunca 0 0 0
Nunca 0
A veces 2
Frecuente
3
mente
Siempre 4
ADHERE
Scrum Aristas
Scrum Team
Scrum Team
Scrum Team
Product Owner
Product Owner
Product Owner
Product Owner
Product Owner
Product Owner
Developers
Roles
Developers
Developers
Developers
Developers
Developers
Scrum Master
Scrum Master
Scrum Master
Scrum Master
Scrum Master
Scrum Master
Sprint
Sprint
Sprint
Sprint
Sprint Planning
Sprint Planning
Sprint Planning
Sprint Planning
Sprint Planning
Sprint Planning
Sprint Planning
Daily Scrum
Daily Scrum
Daily Scrum
Daily Scrum
Daily Scrum
Sprint Review
Sprint Review
Sprint Review
Sprint Review
Sprint Retrospective
Sprint Retrospective
Sprint Retrospective
Sprint Retrospective
Sprint Retrospective
Sprint Retrospective
Sprint Retrospective
Sprint Retrospective
Product Backlog
Product Backlog
Product Backlog
Sprint Backlog
Sprint Backlog
Sprint Backlog
Incremento
Artefactos
Incremento
Incremento
Incremento
Incremento
Sprint Goal
Sprint Goal
ADHERENCIA MARC
Prácticas
El equipo es auto organizados (Ellos mismos toman sus decisiones y no son dirigidos por personas externas)
El equipo tiene todas las competencias necesarias para llevar a cabo el trabajo sin depender de otras personas que no s
equipo (multifuncionales)
El equipo entrega productos de forma iterativa e incremental, cada Sprint (No Cascada).
El Product Owner ordena (prioriza) los elementos del Product Backlog, para alcanzar los objetivos de la mejor maner
El Product Owner se asegura que el Product Backog es visible, transparente y claro para todos, y que muestra aquello
equipo posiblemente trabajará a continuación.
El Product Owner se asegura que el Equipo de Desarrollo entiende los elementos del Product Backlog al nivel necesa
El Product Owner es una única persona, no un comité.
La Organización respeta las decisiones del Product Owner, en relación al contenido y priorización de la Lista del Prod
El Product Owner, es el único que define los elementos del Product Backlog.
Solo los miembros del Equipo de Desarrollo participan en la creación del Incremento.
Son autoorganizados. Nadie (ni siquiera el Scrum Master) indica al Equipo de Desarrollo cómo convertir elementos d
Backlog en Incrementos de producto potencialmente desplegables
No se reconocen títulos para los miembros de un Equipo de Desarrollo, todos son Desarrolladores, independientemen
realice cada persona.
No se reconocen subequipos en el Equipo de Desarrollo, no importan los dominios particulares que requieran tenerse
Los Miembros individuales del Equipo de Desarrollo pueden tener habilidades especializadas y áreas en las que estén
pero la responsabilidad del incremento del producto, recae en el Equipo de Desarrollo como un todo
El Tamaño del Equipo de Desarrollo está entre 3 a 9 personas (No se considera al Product Owner y Scrum Master).
El Scrum Master ayuda a encontrar técnicas para gestionar el Product Backlog de manera efectiva
El Scrum Master facilita los eventos/ceremonias/reuniones de Scrum según se requiera o necesite
El Scrum Master guia al Equipo de Desarrollo en ser autoorganizado y multifuncional
El Scrum Master gestiona/remueve impedimentos (o Escala los impedimentos) para el progreso del Equipo de Desarr
El Scrum Master lidera y guia a la organización en la adopción de Scrum.
El Scrum Master se asegura que el Product Owner conozca cómo ordenar el Product Backlog para maximizar el valo
El tiempo del Sprint no es menor a una semana y no es mayor a un mes
La duración de los Sprints es consistente a lo largo del esfuerzo de desarrollo.
Luego de iniciado un Sprint, no se realizan cambios que puedan afectar al Objetivo de este (Sprint Goal).
Se crea un incremento de producto “Terminado” utilizable y potencialmente desplegable.
La planificación tiene un máximo de 8 horas para un Sprint de un mes, para sprints más cortos es proporcionalmente
Todo el Equipo de Scrum participa.
Se proyecta la capacidad del Equipo de Desarrollo para el Sprint que inicia, y se usa como referencia la capacidad del
(Velocidad, capacidad, cumplimiento de Sprints pasados)
El número de elementos del Product Backlog seleccionados para el Sprint depende únicamente del Equipo de Desarro
Equipo de Desarrollo decide cuál será su compromiso para el Sprint que comienza.
El Equipo de Desarrollo, define un plan de cómo materializar el objetivo para el Sprint (Ej: Define estrategía de traba
El Equipo de Desarrollo descompone las Historias de Usuario en unidades (tareas) de un día o menos
Para reducir la incertidumbre de los requerimientos (Historias de usuario), sólo se comprometen dentro del Sprint Go
cumplen con el Definition of Ready
El Daily Scrum se da con la regularidad necesaria, con un tiempo máximo de duración de 15 minutos.
Todo los miembros del Equipo de Desarrollo participan de manera activa en el Daily Scrum
El Equipo de Desarrollo sincroniza sus actividades y crea un plan para las siguientes 24 horas
El Daily Scrum se realiza a la misma hora y en el mismo lugar todos los días para reducir la complejidad y crear regu
El Equipo de Desarrollo dirige y se apropia de la reunión, no el Scrum Master
Se remueven, gestionan o escalan los impedimentos que surgen en el Daily Scrum por parte de los miembros del Equ
Cada miembro del Equipo de Desarrollo sabe lo que están haciendo los demás integrantes del equipo
Al final del Sprint se lleva a cabo una Revisión del Sprint donde participan de manera activa todos los integrantes de
para cumplir con el objetivo de esta sesión
El tiempo máximo de duración es de 4 horas para Sprints con duración de un mes, para sprints más cortos, el tiempo d
proporcionalmente menor
Los asistentes son todos los miembros del Scrum Team y los interesados clave invitados por el Product Owner
El Product Owner explica qué elementos del Product Backlog se han "Terminado" y cuáles no a los invitados clave
El Equipo de Desarrollo hace una demostración (demo) del trabajo que ha "Terminado", integrado con los incremento
sprints anteriores y responde preguntas acerca del Incremento
La Retrospectiva del Sprint tiene lugar después de la Revisión del Sprint y antes de la siguiente Planificación del Spri
El tiempo máximo de duración es de 3 horas para Sprints con duración de un mes, para sprinta más cortos, el tiempo
proporcionalmente menor.
El Scrum Master participa en la reunión como un miembro del Scrum Team.
Se inspecciona cómo fue el último Sprint en cuanto a personas, relaciones, procesos y herramientas, tomando en cuen
la revisión
Se identifican y ordenan (priorizan) los elementos (accionables) más importantes producto de la Retrospectiva.
Se crea un plan por parte de todos los miembros del Scrum Team para implementar las mejoras priorizadas, se regist
del plan en un lugar visible para el Scrum Team, y se incluye por lo menos una acción de mejora en el Sprint Backlo
Sprint
Durante cada Retrospectiva, el Scrum Team planifica formas de aumentar la calidad del incremento de producto, med
de la Definición de “Terminado” (Definition of “Done”)
Todos los miembros del Scrum Team participan de manera activa en la Retrospectiva
El Product Backlog se encuentra siempre ordenado (priorizado) garantizando la generación de valor
El Equipo de Desarrollo es el único responsable de proporcionar todas las estimaciones
Los elementos del Product Backlog tienen como atributos la descripción, el orden y el valor de negocio
El Sprint Backlog siempre está visible
Solo el Equipo de Desarro puede gestionar o modificar el Sprint Backlog durante un Sprint, siempre y cuando esto no
Sprint Goal
Sólo se debe de considerar el trabajo "terminado" si se cumple con la definición de "Done"
El incremento debe estar en condiciones de utilizarse sin importar si el Product Owner decide liberarlo o no.
El Equipo de Desarrollo hace seguimiento del trabajo restante total al menos en cada Daily Scrum, gestionando así su
de Kanban o Burndown Chart).
Todos los miembros del Scrum Team definen y acuerdan en conjunto la definición de "Terminado"
La definición de "Terminado" evoluciona conforme la madurez del equipo, para incluir criterios más rigurosos para u
Todos los miembros del Scrum Team comparten el mismo entendimeinto de lo que significa que el incremento está te
Se cumple con el objetivo al finalizar el Sprint
El Equipo Scrum elabora y homologa un Objetivo para el Sprint que comienza (Sprint Goal)
SCRUM
Assessment Valor Comentarios Anterior
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Variación
0 Nunca 0
0 A veces 2
Frecuente
0 3
mente
0 Siempre 4
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
ADHERE
Scrum Aristas
Scrum Team
Scrum Team
Scrum Team
Product Owner
Product Owner
Product Owner
Product Owner
Product Owner
Product Owner
Developers
Roles
Developers
Developers
Developers
Developers
Developers
Scrum Master
Scrum Master
Scrum Master
Scrum Master
Scrum Master
Scrum Master
Sprint
Sprint
Sprint
Sprint
Sprint Planning
Sprint Planning
Sprint Planning
Sprint Planning
Sprint Planning
Sprint Planning
Sprint Planning
Sprint Planning
Daily Scrum
Daily Scrum
Daily Scrum
Daily Scrum
Daily Scrum
Eventos Daily Scrum
Daily Scrum
Sprint Review
Sprint Review
Sprint Review
Sprint Review
Sprint Review
Sprint Retrospective
Sprint Retrospective
Sprint Retrospective
Sprint Retrospective
Sprint Retrospective
Sprint Retrospective
Sprint Retrospective
Sprint Retrospective
Product Backlog
Product Backlog
Product Backlog
Sprint Backlog
Sprint Backlog
Incremento
Artefactos Incremento
Incremento
Incremento
Incremento
Incremento
Sprint Goal
ADHERENCIA MARC
Prácticas
El equipo es auto organizados (Ellos mismos toman sus decisiones y no son dirigidos por personas externas)
El equipo tiene todas las competencias necesarias para llevar a cabo el trabajo sin depender de otras personas que no s
equipo (multifuncionales)
El equipo entrega productos de forma iterativa e incremental, cada Sprint (No Cascada).
El Product Owner ordena (prioriza) los elementos del Product Backlog, para alcanzar los objetivos de la mejor maner
El Product Owner se asegura que el Product Backog es visible, transparente y claro para todos, y que muestra aquello
equipo posiblemente trabajará a continuación.
El Product Owner se asegura que el Equipo de Desarrollo entiende los elementos del Product Backlog al nivel necesa
El Product Owner es una única persona, no un comité.
La Organización respeta las decisiones del Product Owner, en relación al contenido y priorización de la Lista del Prod
El Product Owner, es el único que define los elementos del Product Backlog.
Solo los miembros del Equipo de Desarrollo participan en la creación del Incremento.
Son autoorganizados. Nadie (ni siquiera el Scrum Master) indica al Equipo de Desarrollo cómo convertir elementos d
Backlog en Incrementos de producto potencialmente desplegables
No se reconocen títulos para los miembros de un Equipo de Desarrollo, todos son Desarrolladores, independientemen
realice cada persona.
No se reconocen subequipos en el Equipo de Desarrollo, no importan los dominios particulares que requieran tenerse
Los Miembros individuales del Equipo de Desarrollo pueden tener habilidades especializadas y áreas en las que estén
pero la responsabilidad del incremento del producto, recae en el Equipo de Desarrollo como un todo
El Tamaño del Equipo de Desarrollo está entre 3 a 9 personas (No se considera al Product Owner y Scrum Master).
El Scrum Master ayuda a encontrar técnicas para gestionar el Product Backlog de manera efectiva
El Scrum Master facilita los eventos/ceremonias/reuniones de Scrum según se requiera o necesite
El Scrum Master guia al Equipo de Desarrollo en ser autoorganizado y multifuncional
El Scrum Master gestiona/remueve impedimentos (o Escala los impedimentos) para el progreso del Equipo de Desarr
El Scrum Master lidera y guia a la organización en la adopción de Scrum.
El Scrum Master se asegura que el Product Owner conozca cómo ordenar el Product Backlog para maximizar el valo
El tiempo del Sprint no es menor a una semana y no es mayor a un mes
La duración de los Sprints es consistente a lo largo del esfuerzo de desarrollo.
Luego de iniciado un Sprint, no se realizan cambios que puedan afectar al Objetivo de este (Sprint Goal).
Se crea un incremento de producto “Terminado” utilizable y potencialmente desplegable.
La planificación tiene un máximo de 8 horas para un Sprint de un mes, para sprints más cortos es proporcionalmente
Todo el Equipo de Scrum participa.
El Equipo Scrum elabora y homologa un Objetivo para el Sprint que comienza (Sprint Goal)
Se proyecta la capacidad del Equipo de Desarrollo para el Sprint que inicia, y se usa como referencia la capacidad del
(Velocidad, capacidad, cumplimiento de Sprints pasados)
El número de elementos del Product Backlog seleccionados para el Sprint depende únicamente del Equipo de Desarro
Equipo de Desarrollo decide cuál será su compromiso para el Sprint que comienza.
El Equipo de Desarrollo, define un plan de cómo materializar el objetivo para el Sprint (Ej: Define estrategía de traba
El Equipo de Desarrollo descompone las Historias de Usuario en unidades (tareas) de un día o menos
Para reducir la incertidumbre de los requerimientos (Historias de usuario), sólo se comprometen dentro del Sprint Go
cumplen con el Definition of Ready
El Daily Scrum se da con la regularidad necesaria, con un tiempo máximo de duración de 15 minutos.
Todo los miembros del Equipo de Desarrollo participan de manera activa en el Daily Scrum
El Equipo de Desarrollo sincroniza sus actividades y crea un plan para las siguientes 24 horas
El Daily Scrum se realiza a la misma hora y en el mismo lugar todos los días para reducir la complejidad y crear regu
El Equipo de Desarrollo dirige y se apropia de la reunión, no el Scrum Master
Se remueven, gestionan o escalan los impedimentos que surgen en el Daily Scrum por parte de los miembros del Equ
Cada miembro del Equipo de Desarrollo sabe lo que están haciendo los demás integrantes del equipo
Al final del Sprint se lleva a cabo una Revisión del Sprint donde participan de manera activa todos los integrantes de
para cumplir con el objetivo de esta sesión
El tiempo máximo de duración es de 4 horas para Sprints con duración de un mes, para sprints más cortos, el tiempo d
proporcionalmente menor
Los asistentes son todos los miembros del Scrum Team y los interesados clave invitados por el Product Owner
El Product Owner explica qué elementos del Product Backlog se han "Terminado" y cuáles no a los invitados clave
El Equipo de Desarrollo hace una demostración (demo) del trabajo que ha "Terminado", integrado con los incremento
sprints anteriores y responde preguntas acerca del Incremento
La Retrospectiva del Sprint tiene lugar después de la Revisión del Sprint y antes de la siguiente Planificación del Spri
El tiempo máximo de duración es de 3 horas para Sprints con duración de un mes, para sprinta más cortos, el tiempo
proporcionalmente menor.
El Scrum Master participa en la reunión como un miembro del Scrum Team.
Se inspecciona cómo fue el último Sprint en cuanto a personas, relaciones, procesos y herramientas, tomando en cuen
la revisión
Se identifican y ordenan (priorizan) los elementos (accionables) más importantes producto de la Retrospectiva.
Se crea un plan por parte de todos los miembros del Scrum Team para implementar las mejoras priorizadas, se regist
del plan en un lugar visible para el Scrum Team, y se incluye por lo menos una acción de mejora en el Sprint Backlo
Sprint
Durante cada Retrospectiva, el Scrum Team planifica formas de aumentar la calidad del incremento de producto, med
de la Definición de “Terminado” (Definition of “Done”)
Todos los miembros del Scrum Team participan de manera activa en la Retrospectiva
El Product Backlog se encuentra siempre ordenado (priorizado) garantizando la generación de valor
El Equipo de Desarrollo es el único responsable de proporcionar todas las estimaciones
Los elementos del Product Backlog tienen como atributos la descripción, el orden y el valor de negocio
El Sprint Backlog siempre está visible
Solo el Equipo de Desarro puede gestionar o modificar el Sprint Backlog durante un Sprint, siempre y cuando esto no
Sprint Goal
Sólo se debe de considerar el trabajo "terminado" si se cumple con la definición de "Done"
El incremento debe estar en condiciones de utilizarse sin importar si el Product Owner decide liberarlo o no.
El Equipo de Desarrollo hace seguimiento del trabajo restante total al menos en cada Daily Scrum, gestionando así su
de Kanban o Burndown Chart).
Todos los miembros del Scrum Team definen y acuerdan en conjunto la definición de "Terminado"
La definición de "Terminado" evoluciona conforme la madurez del equipo, para incluir criterios más rigurosos para u
Todos los miembros del Scrum Team comparten el mismo entendimeinto de lo que significa que el incremento está te
Se cumple con el objetivo al finalizar el Sprint
SCRUM
Assessment Valor Comentarios Anterior
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Variación
0 Nunca 0
0 A veces 2
Frecuente
0 3
mente
0 Siempre 4
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
ADHERE
Scrum Aristas
Scrum Team
Scrum Team
Scrum Team
Product Owner
Product Owner
Product Owner
Product Owner
Product Owner
Product Owner
Developers
Roles
Developers
Developers
Developers
Developers
Developers
Scrum Master
Scrum Master
Scrum Master
Scrum Master
Scrum Master
Scrum Master
Sprint
Sprint
Sprint
Sprint
Sprint Planning
Sprint Planning
Sprint Planning
Sprint Planning
Sprint Planning
Sprint Planning
Sprint Planning
Daily Scrum
Daily Scrum
Daily Scrum
Daily Scrum
Daily Scrum
Sprint Review
Sprint Review
Sprint Review
Sprint Review
Sprint Retrospective
Sprint Retrospective
Sprint Retrospective
Sprint Retrospective
Sprint Retrospective
Sprint Retrospective
Sprint Retrospective
Sprint Retrospective
Product Backlog
Product Backlog
Product Backlog
Sprint Backlog
Sprint Backlog
Incremento
Incremento
Artefactos
Incremento
Incremento
Incremento
Incremento
Sprint Goal
Sprint Goal
ADHERENCIA MARC
Prácticas
El equipo es auto organizados (Ellos mismos toman sus decisiones y no son dirigidos por personas externas)
El equipo tiene todas las competencias necesarias para llevar a cabo el trabajo sin depender de otras personas que no s
equipo (multifuncionales)
El equipo entrega productos de forma iterativa e incremental, cada Sprint (No Cascada).
El Product Owner ordena (prioriza) los elementos del Product Backlog, para alcanzar los objetivos de la mejor maner
El Product Owner se asegura que el Product Backog es visible, transparente y claro para todos, y que muestra aquello
equipo posiblemente trabajará a continuación.
El Product Owner se asegura que el Equipo de Desarrollo entiende los elementos del Product Backlog al nivel necesa
El Product Owner es una única persona, no un comité.
La Organización respeta las decisiones del Product Owner, en relación al contenido y priorización de la Lista del Prod
El Product Owner, es el único que define los elementos del Product Backlog.
Solo los miembros del Equipo de Desarrollo participan en la creación del Incremento.
Son autoorganizados. Nadie (ni siquiera el Scrum Master) indica al Equipo de Desarrollo cómo convertir elementos d
Backlog en Incrementos de producto potencialmente desplegables
No se reconocen títulos para los miembros de un Equipo de Desarrollo, todos son Desarrolladores, independientemen
realice cada persona.
No se reconocen subequipos en el Equipo de Desarrollo, no importan los dominios particulares que requieran tenerse
Los Miembros individuales del Equipo de Desarrollo pueden tener habilidades especializadas y áreas en las que estén
pero la responsabilidad del incremento del producto, recae en el Equipo de Desarrollo como un todo
El Tamaño del Equipo de Desarrollo está entre 3 a 9 personas (No se considera al Product Owner y Scrum Master).
El Scrum Master ayuda a encontrar técnicas para gestionar el Product Backlog de manera efectiva
El Scrum Master facilita los eventos/ceremonias/reuniones de Scrum según se requiera o necesite
El Scrum Master guia al Equipo de Desarrollo en ser autoorganizado y multifuncional
El Scrum Master gestiona/remueve impedimentos (o Escala los impedimentos) para el progreso del Equipo de Desarr
El Scrum Master lidera y guia a la organización en la adopción de Scrum.
El Scrum Master se asegura que el Product Owner conozca cómo ordenar el Product Backlog para maximizar el valo
El tiempo del Sprint no es menor a una semana y no es mayor a un mes
La duración de los Sprints es consistente a lo largo del esfuerzo de desarrollo.
Luego de iniciado un Sprint, no se realizan cambios que puedan afectar al Objetivo de este (Sprint Goal).
Se crea un incremento de producto “Terminado” utilizable y potencialmente desplegable.
La planificación tiene un máximo de 8 horas para un Sprint de un mes, para sprints más cortos es proporcionalmente
Todo el Equipo de Scrum participa.
Se proyecta la capacidad del Equipo de Desarrollo para el Sprint que inicia, y se usa como referencia la capacidad del
(Velocidad, capacidad, cumplimiento de Sprints pasados)
El número de elementos del Product Backlog seleccionados para el Sprint depende únicamente del Equipo de Desarro
Equipo de Desarrollo decide cuál será su compromiso para el Sprint que comienza.
El Equipo de Desarrollo, define un plan de cómo materializar el objetivo para el Sprint (Ej: Define estrategía de traba
El Equipo de Desarrollo descompone las Historias de Usuario en unidades (tareas) de un día o menos
Para reducir la incertidumbre de los requerimientos (Historias de usuario), sólo se comprometen dentro del Sprint Go
cumplen con el Definition of Ready
El Daily Scrum se da con la regularidad necesaria, con un tiempo máximo de duración de 15 minutos.
Todo los miembros del Equipo de Desarrollo participan de manera activa en el Daily Scrum
El Equipo de Desarrollo sincroniza sus actividades y crea un plan para las siguientes 24 horas
El Daily Scrum se realiza a la misma hora y en el mismo lugar todos los días para reducir la complejidad y crear regu
El Equipo de Desarrollo dirige y se apropia de la reunión, no el Scrum Master
Se remueven, gestionan o escalan los impedimentos que surgen en el Daily Scrum por parte de los miembros del Equ
Cada miembro del Equipo de Desarrollo sabe lo que están haciendo los demás integrantes del equipo
Al final del Sprint se lleva a cabo una Revisión del Sprint donde participan de manera activa todos los integrantes de
para cumplir con el objetivo de esta sesión
El tiempo máximo de duración es de 4 horas para Sprints con duración de un mes, para sprints más cortos, el tiempo d
proporcionalmente menor
Los asistentes son todos los miembros del Scrum Team y los interesados clave invitados por el Product Owner
El Product Owner explica qué elementos del Product Backlog se han "Terminado" y cuáles no a los invitados clave
El Equipo de Desarrollo hace una demostración (demo) del trabajo que ha "Terminado", integrado con los incremento
sprints anteriores y responde preguntas acerca del Incremento
La Retrospectiva del Sprint tiene lugar después de la Revisión del Sprint y antes de la siguiente Planificación del Spri
El tiempo máximo de duración es de 3 horas para Sprints con duración de un mes, para sprinta más cortos, el tiempo
proporcionalmente menor.
El Scrum Master participa en la reunión como un miembro del Scrum Team.
Se inspecciona cómo fue el último Sprint en cuanto a personas, relaciones, procesos y herramientas, tomando en cuen
la revisión
Se identifican y ordenan (priorizan) los elementos (accionables) más importantes producto de la Retrospectiva.
Se crea un plan por parte de todos los miembros del Scrum Team para implementar las mejoras priorizadas, se regist
del plan en un lugar visible para el Scrum Team, y se incluye por lo menos una acción de mejora en el Sprint Backlo
Sprint
Durante cada Retrospectiva, el Scrum Team planifica formas de aumentar la calidad del incremento de producto, med
de la Definición de “Terminado” (Definition of “Done”)
Todos los miembros del Scrum Team participan de manera activa en la Retrospectiva
El Product Backlog se encuentra siempre ordenado (priorizado) garantizando la generación de valor
El Equipo de Desarrollo es el único responsable de proporcionar todas las estimaciones
Los elementos del Product Backlog tienen como atributos la descripción, el orden y el valor de negocio
El Sprint Backlog siempre está visible
Solo el Equipo de Desarro puede gestionar o modificar el Sprint Backlog durante un Sprint, siempre y cuando esto no
Sprint Goal
Sólo se debe de considerar el trabajo "terminado" si se cumple con la definición de "Done"
El incremento debe estar en condiciones de utilizarse sin importar si el Product Owner decide liberarlo o no.
El Equipo de Desarrollo hace seguimiento del trabajo restante total al menos en cada Daily Scrum, gestionando así su
de Kanban o Burndown Chart).
Todos los miembros del Scrum Team definen y acuerdan en conjunto la definición de "Terminado"
La definición de "Terminado" evoluciona conforme la madurez del equipo, para incluir criterios más rigurosos para u
Todos los miembros del Scrum Team comparten el mismo entendimeinto de lo que significa que el incremento está te
Se cumple con el objetivo al finalizar el Sprint
El Equipo Scrum elabora y homologa un Objetivo para el Sprint que comienza (Sprint Goal)
SCRUM
Assessment Valor Comentarios Anterior
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Variación
0 Nunca 0
0 A veces 2
Frecuente
0 3
mente
0 Siempre 4
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
ADHERE
Scrum Aristas
Scrum Team
Scrum Team
Scrum Team
Product Owner
Product Owner
Product Owner
Product Owner
Product Owner
Product Owner
Developers
Roles
Developers
Developers
Developers
Developers
Developers
Scrum Master
Scrum Master
Scrum Master
Scrum Master
Scrum Master
Scrum Master
Sprint
Sprint
Sprint
Sprint
Sprint Planning
Sprint Planning
Sprint Planning
Sprint Planning
Sprint Planning
Sprint Planning
Sprint Planning
Daily Scrum
Daily Scrum
Daily Scrum
Daily Scrum
Daily Scrum
Sprint Review
Sprint Review
Sprint Review
Sprint Review
Sprint Retrospective
Sprint Retrospective
Sprint Retrospective
Sprint Retrospective
Sprint Retrospective
Sprint Retrospective
Sprint Retrospective
Sprint Retrospective
Product Backlog
Product Backlog
Product Backlog
Sprint Backlog
Sprint Backlog
Incremento
Incremento
Artefactos
Incremento
Incremento
Incremento
Incremento
Sprint Goal
Sprint Goal
ADHERENCIA MARC
Prácticas
El equipo es auto organizados (Ellos mismos toman sus decisiones y no son dirigidos por personas externas)
El equipo tiene todas las competencias necesarias para llevar a cabo el trabajo sin depender de otras personas que no s
equipo (multifuncionales)
El equipo entrega productos de forma iterativa e incremental, cada Sprint (No Cascada).
El Product Owner ordena (prioriza) los elementos del Product Backlog, para alcanzar los objetivos de la mejor maner
El Product Owner se asegura que el Product Backog es visible, transparente y claro para todos, y que muestra aquello
equipo posiblemente trabajará a continuación.
El Product Owner se asegura que el Equipo de Desarrollo entiende los elementos del Product Backlog al nivel necesa
El Product Owner es una única persona, no un comité.
La Organización respeta las decisiones del Product Owner, en relación al contenido y priorización de la Lista del Prod
El Product Owner, es el único que define los elementos del Product Backlog.
Solo los miembros del Equipo de Desarrollo participan en la creación del Incremento.
Son autoorganizados. Nadie (ni siquiera el Scrum Master) indica al Equipo de Desarrollo cómo convertir elementos d
Backlog en Incrementos de producto potencialmente desplegables
No se reconocen títulos para los miembros de un Equipo de Desarrollo, todos son Desarrolladores, independientemen
realice cada persona.
No se reconocen subequipos en el Equipo de Desarrollo, no importan los dominios particulares que requieran tenerse
Los Miembros individuales del Equipo de Desarrollo pueden tener habilidades especializadas y áreas en las que estén
pero la responsabilidad del incremento del producto, recae en el Equipo de Desarrollo como un todo
El Tamaño del Equipo de Desarrollo está entre 3 a 9 personas (No se considera al Product Owner y Scrum Master).
El Scrum Master ayuda a encontrar técnicas para gestionar el Product Backlog de manera efectiva
El Scrum Master facilita los eventos/ceremonias/reuniones de Scrum según se requiera o necesite
El Scrum Master guia al Equipo de Desarrollo en ser autoorganizado y multifuncional
El Scrum Master gestiona/remueve impedimentos (o Escala los impedimentos) para el progreso del Equipo de Desarr
El Scrum Master lidera y guia a la organización en la adopción de Scrum.
El Scrum Master se asegura que el Product Owner conozca cómo ordenar el Product Backlog para maximizar el valo
El tiempo del Sprint no es menor a una semana y no es mayor a un mes
La duración de los Sprints es consistente a lo largo del esfuerzo de desarrollo.
Luego de iniciado un Sprint, no se realizan cambios que puedan afectar al Objetivo de este (Sprint Goal).
Se crea un incremento de producto “Terminado” utilizable y potencialmente desplegable.
La planificación tiene un máximo de 8 horas para un Sprint de un mes, para sprints más cortos es proporcionalmente
Todo el Equipo de Scrum participa.
Se proyecta la capacidad del Equipo de Desarrollo para el Sprint que inicia, y se usa como referencia la capacidad del
(Velocidad, capacidad, cumplimiento de Sprints pasados)
El número de elementos del Product Backlog seleccionados para el Sprint depende únicamente del Equipo de Desarro
Equipo de Desarrollo decide cuál será su compromiso para el Sprint que comienza.
El Equipo de Desarrollo, define un plan de cómo materializar el objetivo para el Sprint (Ej: Define estrategía de traba
El Equipo de Desarrollo descompone las Historias de Usuario en unidades (tareas) de un día o menos
Para reducir la incertidumbre de los requerimientos (Historias de usuario), sólo se comprometen dentro del Sprint Go
cumplen con el Definition of Ready
El Daily Scrum se da con la regularidad necesaria, con un tiempo máximo de duración de 15 minutos.
Todo los miembros del Equipo de Desarrollo participan de manera activa en el Daily Scrum
El Equipo de Desarrollo sincroniza sus actividades y crea un plan para las siguientes 24 horas
El Daily Scrum se realiza a la misma hora y en el mismo lugar todos los días para reducir la complejidad y crear regu
El Equipo de Desarrollo dirige y se apropia de la reunión, no el Scrum Master
Se remueven, gestionan o escalan los impedimentos que surgen en el Daily Scrum por parte de los miembros del Equ
Cada miembro del Equipo de Desarrollo sabe lo que están haciendo los demás integrantes del equipo
Al final del Sprint se lleva a cabo una Revisión del Sprint donde participan de manera activa todos los integrantes de
para cumplir con el objetivo de esta sesión
El tiempo máximo de duración es de 4 horas para Sprints con duración de un mes, para sprints más cortos, el tiempo d
proporcionalmente menor
Los asistentes son todos los miembros del Scrum Team y los interesados clave invitados por el Product Owner
El Product Owner explica qué elementos del Product Backlog se han "Terminado" y cuáles no a los invitados clave
El Equipo de Desarrollo hace una demostración (demo) del trabajo que ha "Terminado", integrado con los incremento
sprints anteriores y responde preguntas acerca del Incremento
La Retrospectiva del Sprint tiene lugar después de la Revisión del Sprint y antes de la siguiente Planificación del Spri
El tiempo máximo de duración es de 3 horas para Sprints con duración de un mes, para sprinta más cortos, el tiempo
proporcionalmente menor.
El Scrum Master participa en la reunión como un miembro del Scrum Team.
Se inspecciona cómo fue el último Sprint en cuanto a personas, relaciones, procesos y herramientas, tomando en cuen
la revisión
Se identifican y ordenan (priorizan) los elementos (accionables) más importantes producto de la Retrospectiva.
Se crea un plan por parte de todos los miembros del Scrum Team para implementar las mejoras priorizadas, se regist
del plan en un lugar visible para el Scrum Team, y se incluye por lo menos una acción de mejora en el Sprint Backlo
Sprint
Durante cada Retrospectiva, el Scrum Team planifica formas de aumentar la calidad del incremento de producto, med
de la Definición de “Terminado” (Definition of “Done”)
Todos los miembros del Scrum Team participan de manera activa en la Retrospectiva
El Product Backlog se encuentra siempre ordenado (priorizado) garantizando la generación de valor
El Equipo de Desarrollo es el único responsable de proporcionar todas las estimaciones
Los elementos del Product Backlog tienen como atributos la descripción, el orden y el valor de negocio
El Sprint Backlog siempre está visible
Solo el Equipo de Desarro puede gestionar o modificar el Sprint Backlog durante un Sprint, siempre y cuando esto no
Sprint Goal
Sólo se debe de considerar el trabajo "terminado" si se cumple con la definición de "Done"
El incremento debe estar en condiciones de utilizarse sin importar si el Product Owner decide liberarlo o no.
El Equipo de Desarrollo hace seguimiento del trabajo restante total al menos en cada Daily Scrum, gestionando así su
de Kanban o Burndown Chart).
Todos los miembros del Scrum Team definen y acuerdan en conjunto la definición de "Terminado"
La definición de "Terminado" evoluciona conforme la madurez del equipo, para incluir criterios más rigurosos para u
Todos los miembros del Scrum Team comparten el mismo entendimeinto de lo que significa que el incremento está te
Se cumple con el objetivo al finalizar el Sprint
El Equipo Scrum elabora y homologa un Objetivo para el Sprint que comienza (Sprint Goal)
SCRUM
Assessment Valor Comentarios Anterior
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Nunca 0 0
Variación
0 Nunca 0
0 A veces 2
Frecuente
0 3
mente
0 Siempre 4
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
Roles 30%; Eventos 50%; Artefactos 20%
A2 A3 A4 A5
0% 0% 0% 0%
0% 0% 0% 0%
0% 0% 0% 0%
Assessment 1
Roles Roles
Eventos Eventos
Artefactos Artefactos
Roles Roles
Eventos Eventos
Artefactos Artefactos
0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 10
Assessment 3 Assessment 4
Roles
Eventos
Artefactos
% 30% 40% 50% 60% 70% 80% 90% 100% 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%
4 Assessment 5
Roles
Eventos
Artefactos
0% 90% 100% 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%