• Sprint 0 (Toma de requisitos)
• Srpint Planning meeting o reunión de planificación del sprint
• Daily Meeting o Reuniones diarias
• Srpint review Meeting o DEMO
• Sprint Retrspective o retrospectiva

• Product Owner: Representa la voz del cliente y de los interesados no implicados en el proyecto. Se encarga de definir los objetivos del proyecto y garantizar que el equipo trabaja de modo adecuado par alcanzar los objetivos
• Scrum Master: Es el encargado de que el equipo de trabajo funcione cada vez mejor. Busca asegurar que se alcancen los objetivos de cada Sprint y, en el mejor de los casos, lograr más de lo que marcan los ojetivos.
  • Se encarga de que todo funcione para poder poner en marcha la agilidad
  • Time Boxing: El scrum master debe tener todas las partes de srcum limitadas por tiempo.
• Equipo de desarrollo (Scrum Team): Es el equipo encargado de desarrollar y entregar el producto. Es un grupo auto-organizado
• StakeHolders: Grupo que comprende aquellos perfiles interesados en el producto.

Lo que se busca con estos roles es que “El que más sabe de algo que sea el que lo haga”.

• Velocidad: entendida como la suma de los items que se terminan en un trozo de tiempo y que había pedido el product owner, se ve condicionada especialmente por lo que solemos llamar desperdicio
• Desperdiciós típicos: Interrupciones, cambios de contexto, baja calidad del software, casos de prueba y diagramas o documentación que nunca serán leidos
• Desperdicios en los tableros: Postit que se quedan estancados en el DOING, columnas de test con demasiadas tareas acumuladas.

Para evitar estos desperdicios son importantes las retrospectivas utilizando técnicas como la de la estrella de mar para localizar cosas que se deben hacer más o menos, además de las cosas que se están haciendo bien.

Se utilizan para calcular la velocidad del equipo de trabajo. Hay 2 principales tipos de estimación:

• Estimación general: Estimamos lo que podemos hacer basándonos en sprints anteriores
• Estimación por Planning poker: Se utilizan unas cartas con la sucesión de fibonacci (1, 2, 3, 5, 8, 13, 20, 40 y 100). Cuando se selecciona la tarea a realizar los participantes toman las cartas en base a la complejidad que creen que tienen una tarea. Tras eso cada miembro muestra la carta y se selecciona a los miembros que han tomado la carta más alta y más baja y se les pide que expliquen por que consideran que puede ser más fácil o más difícil la tarea en cuestión, lo que resulta en un debate que finaliza con una votación y un consenso entre los miembros del equipo.

• Ver el product backlog
• Tamaño unidad: complejidad en puntos historia (Algunos los traducen en horas)
• Tiempo ideal: puntos de historia por sprint (Velocidad)
• Tiempo Real

• Técnica de MoSCoW y Kano:
  • Se utiliza para clasificar y priorizar requisitos en función de los que satisfaán al usuario.
  • 4 tipos:
    • Requisitos obligatorios (Básicos)
    • Necesidades (Esperados)
    • No esperados (Inesperados pero que interesan)
    • Indiferentes (El cliente no está interesado en estos)