Principios Scrum :

1. Control del proceso empírico (Empirical Process Control) : El control del proceso
empírico se basa en las tres ideas principales de la transparencia, inspección y
adaptación.

2. Auto-organización (Self-organization) : Scrum sostiene que los empleados cuentan con

motivación propia y que buscan aceptar mayores responsabilidades. Por tanto,
ofrecen mucho más valor cuando se organizan por cuenta propia. El estilo de liderazgo
preferido en Scrum es el de “liderazgo servicial”, el cual enfatiza el logro de
resultados, centrándose en las necesidades del Equipo Scrum.

3. Colaboración (Collaboration) : La colaboración en Scrum se refiere a que el equipo

principal de Scrum trabaja e interactúa con los stakeholders para crear y validar los
resultados del proyecto a fin de cumplir con los objetivos que se plantean en la visión
del proyecto. Es importante tener en cuenta la diferencia entre cooperación y
colaboración. La cooperación se da cuando el trabajo que se produce consiste en la
suma de los esfuerzos del trabajo de varias personas en un equipo. La colaboración, en
cambio, se produce cuando un equipo trabaja en conjunto para contraponer los
aportes del otro a fin de producir algo más grande. Las dimensiones básicas de trabajo
en la colaboración son las siguientes: • Conocimiento—Las personas que trabajan
juntas deben estar al tanto del trabajo de los demás. • Articulación—Los
colaboradores deben distribuir el trabajo en unidades; dividir las unidades entre los
miembros del equipo y después reintegrarlo cuando el trabajo esté hecho. •
Apropiación—Adaptar la tecnología a la situación individual; la tecnología se puede
utilizar de forma completamente distinta a lo esperado por los diseñadores.
4. Priorización basada en valor (Value-based Prioritization) : La priorización se lleva a cabo por
el Product Owner cuando prioriza las historias de usuario en el Backlog Priorizado del
Producto.
5. Time-boxing : Scrum introduce un concepto de Time-boxing (o asignación de un bloque de
tiempo), que propone la fijación de una cierta cantidad de tiempo para cada proceso y
actividad en un proyecto Scrum

6. Desarrollo iterativo (Iterative Development)

Principios ágiles (12)

5 aspectos Scrum que se debe abordar en cualquier proyecto:

Organización,
Justificación del negocio ,
Calidad,
Cambio
Riesgo

5 fases de Scrum: Inicio, Planificación y estimación, Implementación, Revisión y retrospectiva,

Lanzamiento.

19 procesos de Scrum

Un sprint tiene una duración de 1 a 6 semanas.

Daily Standups breves y concretos

Hacia el final del sprint, se lleva a cabo una Reunión de Revisión del Sprint (Sprint Review
Meeting) en la cual se proporciona una demostración de los entregables al Product Owner y a
los stakeholders relevantes.

El Product Owner acepta los entregables sólo si cumplen con los criterios de aceptación
predefinidos. El ciclo del sprint termina con una Reunión de Retrospectiva del Sprint
(Retrospect Sprint Meeting), donde el equipo analiza las formas de mejorar los procesos y el
rendimiento a medida que avanzan al siguiente sprint.

Para ser eficaces, los equipos Scrum idealmente deben tener de seis a diez miembros.

El Backlog Priorizado del Producto nunca se completa sino hasta el cierre o conclusión del
proyecto.
Procesos por Fase:

Fase Inicio:

1. Crear la visión del proyecto

2. Identificar al Scrum Master y Stakeholder(s)
3. Formar Equipos Scrum
4. Desarrollar épica(s)
5. Crear el Backlog Priorizado del Producto
6. Realizar la planificación de lanzamiento

Fase Planificación y estimación:

7. Crear historias de usuario
8. Estimar historias de usuario
9. Comprometer historias de usuario
10. Identificar tareas
11. Estimar tareas
12. Crear el Sprint Backlog

Fase Implementación:
13. Crear entregables
14. Realizar Daily Standup
15. Refinar el Backlog Priorizado del Producto

Fase Revisión y Retrospectiva

16. Demostrar y validar el sprint
17. Retrospectiva del sprint

Fase Lanzamiento
18. Enviar entregables
19. Retrospectiva del proyecto

Inicio
1. Crear la visión del proyecto—En este proceso se revisa el caso de negocio del proyecto
(Project Business Case) a fin de crear una Declaración de la visión del proyecto, que
servirá de inspiración y proporcionará un enfoque para todo el proyecto. En este
proceso se identifica al Product Owner.

2. Identificar al Scrum Master y Stakeholder(s)—En este proceso se identifica al Scrum

Master y stakeholders utilizando criterios de selección específicos.

3. Formar Equipos Scrum—En este proceso se identifican a los miembros del Equipo
Scrum. Normalmente, el Product Owner es el responsable principal de la selección de
los miembros del equipo, pero con frecuencia lo hace en colaboración con el Scrum
Master.

4. Desarrollar épica(s)—En este proceso la Declaración de visión del proyecto sirve como
base para el desarrollo de épicas. Se pueden llevar a cabo reuniones de grupos de
usuarios para hablar sobre las épicas adecuadas.
 5. Crear el Backlog Priorizado del Producto—En este proceso se refinan y se crean las
épicas, y después se priorizan para crear un Backlog Priorizado del Producto para el
proyecto. A este punto también se establecen los criterios de terminado.

6. Realizar la planificación del lanzamiento—En este proceso el equipo principal de Scrum

revisa las historias de usuario en el Backlog Priorizado del Producto para desarrollar un
cronograma de planificación del lanzamiento, que es esencialmente un programa de
implementación por fases que se puede compartir con los stakeholders del proyecto.
En este proceso también se determina la duración del sprint.

Planificación y estimación

7. Crear historias de usuario—En este proceso se crean las historias de usuario y los
criterios de aceptación de las historias de usuario. Las historias de usuario
generalmente las escribe el Product Owner y están diseñadas para asegurar que los
requisitos del cliente estén claramente representados y puedan ser plenamente
comprendidos por todos los stakeholders. Se pueden llevar a cabo ejercicios de
redacción de historias de usuario, lo cual incluyan a los miembros del Equipo Scrum,
resultando en la creación de dichas historias. Estas se incorporan al Backlog Priorizado
del Producto.

8. Estimar historias de usuario—En este proceso, el Product Owner aclara las historias de
usuario para que el Scrum Master y el Equipo Scrum puedan estimar el esfuerzo
necesario para desarrollar la funcionalidad descrita en cada historia de usuario.

9. Comprometer historias de usuario—En este proceso, el Equipo Scrum se compromete

a entregar al Product Owner las historias de usuario aprobadas para un sprint. El
resultado de este proceso serían las historias de usuario comprometidas.

10. Identificar tareas—En este proceso, las historias de usuario comprometidas se

desglosan en tareas específicas y se compilan en una lista de tareas.

11. Estimar tareas—En este proceso, el equipo principal de Scrum estima el esfuerzo
necesario para cumplir con cada tarea en la lista de tareas. El resultado de este
proceso es una: Effort Estimated Task List.

12. Crear el Sprint Backlog—En este proceso, el equipo principal de Scrum elabora un
Sprint Backlog que contiene todas las tareas a ser completadas en un sprint como
parte de la Reunión de Planificación del Sprint.

Implementación

13. Crear entregables—En este proceso, el Equipo Scrum trabaja en las tareas en el Sprint
Backlog para crear los entregables del sprint. Generalmente se utiliza un Scrumboard
para dar seguimiento a las actividades que se llevan a cabo. Las asuntos o problemas
que enfrenta el equipo Scrum pudieran actualizar se en un Impediment Log (o registro
de impedimentos).

14. Realizar Daily Standup—En este proceso, se lleva a cabo diariamente una reunión
altamente focalizada con un time-box, conocida como Daily Standup. Es aquí donde los
 miembros del Equipo Scrum se actualizan el uno al otro referente a sus progresos y
sobre los impedimentos que pudieran enfrentar.

15. Refinamiento del Backlog Priorizado del Producto—En este proceso, el Backlog
Priorizado del Producto se actualiza y se refina continuamente. Se puede considerar
realizar una reunión de revisión del Backlog Priorizado del Producto, en la que se
analiza cualquier cambio o actualización al backlog y se incorpora a dicho backlog
según sea necesario.

Revisión y retrospectiva

16. Demostrar y validar el sprint—En este proceso, el Equipo Scrum muestra los
entregables del sprint al Product Owner y a los stakeholders relevantes en una
Reunión de Revisión del Sprint. El propósito de esta reunión es asegurar que se
obtenga la aprobación y aceptación del Product Owner respecto a los entregables
elaborados en el sprint.

17. Retrospectiva del sprint—En este proceso, el Scrum Master y el Equipo Scrum se
reúnen para analizar las lecciones aprendidas durante todo el Sprint. Esta información
se documenta en forma lecciones aprendidas que pueden aplicarse a futuros sprints.
Frecuentemente, como resultado de esta discusión, puede haber mejoras aceptadas
(Agreed Actionable Improvements) o recomendaciones actualizadas por parte del
Scrum Guidance Body.

Lanzamiento

18. Enviar entregables—En este proceso, los entregables aceptados se entregan o se

envían a los stakeholders relevantes. Un documento denominado Working
Deliverables Agreement (Acuerdo de entregables funcionales) documenta la
conclusión satisfactoria del sprint.
19. Retrospectiva del proyecto—En este proceso, mismo que concluye el proyecto, los
stakeholders y miembros del equipo principal de Scrum se reúnen para hacer una
retrospectiva del proyecto e identificar, documentar e internalizar las lecciones
aprendidas. A menudo, estas lecciones llevan a la documentación de Agreed
Actionable Improvements, que se implementarán en futuros proyectos.

Los riesgos del proyecto se identifican y evalúan en los procesos del Desarrollar épica(s), Crear
entregables y Realizar Daily. Una guía para el conocimiento de Scrum (Guía SBOK™) Standup
por parte de los miembros del equipo principal de Scrum.

Mientras se priorizan las historias de usuario en el Backlog Priorizado del Producto, se

consideran los siguientes tres factores: 1. Valor 2. Riesgo o incertidumbre 3. Dependencias
Sprint: 1 a 6 semanas
Daily Standup: timebox 15 minutos.
Reunión de planificación del sprint: Se asigna un timebox de 8 horas para un sprint de un mes.
2 horas por cada semana que dura el sprint.

• Reunión de planificación del sprint, 2 partes:

Definición del objetivo
Identificación y estimación de tareas
Reunión de revisión del sprint: 1 hora por cada semana que dura el sprint.
Reunión de retrospectiva del sprint: 1 hora por cada semana que dura el sprint.

En las etapas iniciales de redacción, la mayoría de las historias son las funcionalidades de alto
nivel. Estas historias de usuario se conocen como épica(s). Las épicas generalmente son muy
grandes como para que los equipos las completen en un sólo sprint, y por lo tanto se dividen
en pequeñas historias de usuario.

Roles de Scrum: ningún rol tiene autoridad sobre los otros.

Roles centrales: Los roles centrales son el Product Owner, el Scrum Master y el Equipo Scrum.
En conjunto se les conoce como el equipo principal de Scrum.
Roles no centrales:

Retorno sobre inversión

RSI = (Ingresos del proyecto – Costo del proyecto) / Costo del proyecto

Valor presente neto: VPN

¿Cuál de los siguientes dos proyectos es la mejor opción si se utiliza el VPN como criterio de
selección?

• El proyecto A tiene un VPN de $1,500 y se completará en 5 años. • El proyecto B tiene un

VPN de $1,000 y se completará en 1 año. Solución: El proyecto A, ya que su VPN es más
elevado. Aquí no se toma en cuenta el hecho de que el proyecto B tiene una duración más
corta que el proyecto A, pues el tiempo ya está representado en los cálculos del VPN (debido a
que es el valor actual y no el valor futuro que se considera en el cálculo).

TIR Tasa interna de retorno

Basado en el TIR, ¿cuál proyecto es más conveniente?

• Proyecto A, que tiene una TIR del 15 % y se completará en 5 años. • Proyecto B, que tiene
una TIR del 10 % y se completará en 1 año. Solución: El proyecto A, ya que su TIR es mayor.
Aquí no se toma en cuenta el hecho de que el proyecto B tiene una duración más corta que el
proyecto A, pues el tiempo ya está representado en los cálculos del TIR (tal como en el VPN, es
el valor actual y no el valor futuro el que se utiliza para determinar la TIR).

Calidad: En Scrum, la calidad se define como la capacidad con la que cuenta un producto
terminado o los entregables para cumplir con los criterios de aceptación y lograr el valor del
negocio que espera el cliente.