Conceptos Scrum / Agile

• Product Owner
• Product Backlog
• Scrum Master
• Definition of DONE
• Sprint
  • Sprint Planning
    • User Stories
  • Daily
  • Sprint Review
    • Burn-down chart
  • Retrospective

Product Backlog

• Este backlog es propiedad del Product Owner y contiene todos los posibles elementos de trabajo que podrían agregarse al producto en el futuro.
• Los elementos en el Product Backlog se clasifican en función de su valor para el cliente o usuario, y el Product Owner es responsable de la priorización.
• La priorización puede cambiar a medida que se obtiene más información o cambian las necesidades del cliente.

La gestión efectiva del backlog es fundamental para el éxito de los proyectos ágiles, ya que ayuda a garantizar que el equipo esté trabajando en las tareas más importantes y de mayor valor en cualquier momento dado.

• Cuando un User Story está "hecho"
• Depende del equipo y el proyecto decidir cuando algo está "hecho".
• Puede incluir, Unit Tests, Documentación, Revisiones de código, etc

Es importante que el equipo y las partes interesadas acuerden y comprendan la Definition of Done para cada elemento del trabajo antes de comprometerse a completarlo durante un Sprint.

Definition of DONE

• Es la parte más importante de todo el proceso
• Un buen proceso de planificación, garantiza entrega de valor al final del Sprint
• El Product Owner establece la prioridad de los User Stories a implementar
• Muy importante definir la Capacidad del equipo en Azure Devops
• Hay que intentar definir todas las tareas para cada User Story y estimar tiempo de las mismas
• Si una tarea lleva más de una jornada de trabajo, dividirla en 2

Puede participar todo el equipo en el sprint planning, o bien los desarrolladores seniors

Sprint Planning

• Puede dirigir las dailys una persona siempre, o podemos ir turnándonos
• No deben de durar más de 15 minutos
• Antes de las dailys hay que actualizar las tareas en las que estemos trabajando
• Si no hemos terminado una tarea debemos indicar el tiempo que hemos invertido en la misma, y el tiempo que creemos que aun queda para terminarla
• Cada miembro del equipo dice que ha hecho el día anterior y que va a hacer hoy, y si tiene algún bloqueo por parte de otro miembro del equipo
• Importante guardar las dailys para mostrar transparencia a los managers

No dejemos que la Daily nos lleve demasiado tiempo. Es únicamente un tiempo que nos tomamos para actualizar el estado del proyecto

Daily

• Depende de:
  • la capacidad del equipo
  • las tareas que vayamos cerrando
  • del ajuste de tiempo que hagamos en nuestras tareas
• Esta gráfica muestra como vamos avanzando en el Sprint
• Es un buen indicativo de ver como vamos el día a día
• También es bueno revisarla durante el Sprint Review

Burn-down chart

• Revisión de Sprint Burn-down chart
• Es importante que asista el equipo de Product Management
• Hay que revisar lo que se haya implementado con Demos a PM
• Es importante entregar valor siempre al final de cada Sprint
• Es importante implementar un proceso de continuous deployment para sacar a PROD los user stories que hayamos cerrado durante el Sprint

Sprint Review

En el Sprint Review hay que lucirse, es decir, es el momento de mostrar a los stake holders que entregamos valor y en consecuencia la valía del equipo

• Identificar que se ha hecho bien durante el sprint
• Identificar que se ha hecho mal durante el sprint
  • Aportar ideas y tomar medidas para mejorar en el siguiente sprint

Retrospectiva

Se trata de identificar entre todos posibles mejoras y aplicarlas entre un sprint y otro. Adaptarse a los cambios