Terminología Agile

Burndown Chart

Es un gráfico que trackea la cantidad de trabajo que queda de una Release a lo largo del tiempo, donde el tiempo se mide en Sprints. Tambien hay equipos que utilizan este mismo grafico para tracakear la cantidad de trabajo en un Sprint para alcanzar su Sprint goal

Daily Scrum

El Daily Scrum es un evento de 15 minutos maximo para que el equipo de desarrollo sincronice las actividades y cree un plan para las próximas 24 horas. Esto se hace inspeccionando el trabajo desde el último Daily Scrum ademas de preveer el trabajo que podría hacerse antes del siguiente. El Daily Scrum se realiza a la misma hora y en el mismo lugar cada día para reducir la complejidad. El propio equipo es quien decide el formato de este evento.

Desarrolladores (antiguo Development Team)

Los desarrolladores está formado por profesionales que hacen el trabajo de entregar un incremento potencialmente liberable de producto «Hecho» al final de cada Sprint. Sólo los miembros del Equipo de Desarrollo crean los incrementos.

Empírico

Indica la información obtenida por medio de la observación o la experimentación.

Forecast o previsión

Una predicción basada en la experiencia de cuánto esfuerzo de los PBIs ( Product Backlog Items ) en el Product Backlog pueden ser transformados en un incremento. Esto no es una garantía, sino una previsión.

Punto historia o Function Point

Unidad de medida para expresar la cantidad de funcionalidad de negocio que un sistema de información proporciona a un usuario. Personalmente no recomiendo su uso, ya que existen otras metricas de negocio más potentes como es el caso de Evidence Based Management

Increment o incremento

El incremento es la suma de todos los PBIs completados durante un Sprint y todos los Sprints anteriores. Al final de un Sprint, el nuevo incremento debe estar TERMINADO, lo que significa que debe estar en condiciones de ser usado por unos usuarios y cumplir con la definición de HECHO del Scrum Team. Debe estar en condiciones de ser utilizado independientemente de si el Product Owner decide realizar una release o no.

Iteration o iteración

Una iteración es el acto de repetir una serie de pasos o procesos, generalmente con el fin de alcanzar un objetivo o resultado deseado. Cada repetición del proceso también se denomina iteración, y los resultados de una iteración se utilizan como punto de partida para la siguiente.

Proceso iterativo e incremental

Una manera de desarrollar un sistema o producto mediante una serie de iteraciones, cada una de las cuales genera un incremento completo que se basa en todos los incrementos anteriores. Las iteraciones continúan hasta que se alcanza un objetivo o se optimiza el valor.

Product Backlog

El Product Backlog es una lista ordenada de todo lo que se puede necesitar en el producto y es la única fuente de requisitos para cualquier cambio que se haga en el producto. El Product Owner es el responsable del Product Backlog, incluyendo su contenido, disponibilidad y orden.

Product Backlog Item

Un Product Backlog Item (PBI) es un elemento de trabajo que existe en el Product Backlog. Los PBIs pueden incluir historias de usuario, epicas, especificaciones, bugs o requisitos de cambio. El Product Owner de un equipo ágil recopila y ordena el backlog del producto, situando o ordenando los PBIs teniendo en cuenta los siguientes criterios:

Product Owner

El Product Owner es el responsable de maximizar el valor del producto y el trabajo del equipo de desarrollo. La forma en que esto se hace puede variar ampliamente entre las organizaciones, los equipos de Scrum y los individuos.

Scrum

Un proceso iterativo e incremental que emplea el control de procesos empíricos. Scrum es uno de varios marcos de trabajo ágiles.

Scrum Master

El Scrum Master es responsable de asegurar que Scrum sea entendido y promulgado. El Scrum Master hace esto asegurándose de que el Scrum Team se adhiere a la teoría, prácticas y reglas de Scrum. El Scrum Master es un Servant Leader del Scrum Team.

Scrum Team

El Scrum Team está formado por el Product Owner, el Development Team y el Scrum Master. Los Scrum Teams son autoorganizado y multifuncionales.

Autoorganización

Es el proceso en el que una estructura o patrón aparece en un sistema sin que una autoridad central o un elemento externo lo imponga a través de la planificación.

Sprint

El corazón de Scrum es el Sprint, con un Timebox de un mes o menos durante el cual se crea un incremento de producto Terminado, utilizable y potencialmente entregable. Los Sprints tienen duraciones regulares a lo largo del desarrollo del producto. Un nuevo Sprint comienza inmediatamente después de la finalización del Sprint anterior.

Sprint Backlog

El Sprint Backlog es el conjunto de PBIs seleccionados para el Sprint, además de un plan para entregar el Incremento y alcanzar el Sprint Goal. El Sprint Backlog es una previsión del equipo de desarrollo, que determina qué funcionalidad será entragada en el próximo incremento y el trabajo necesario para entregar esa funcionalidad. El Sprint Backlog define el trabajo que el equipo de desarrollo realizará para convertir los PBIs en un incremento de terminado. El Sprint Backlog hace transparente todo el trabajo que el equipo de desarrollo identificado como necesario para alcanzar el Objetivo de Sprint.

Sprint Goal

El Sprint Goal da al equipo de desarrollo cierta flexibilidad en cuanto a la funcionalidad implementado en el Sprint. A medida que el equipo de desarrollo trabaja, tiene este objetivo en mente. Para satisfacer el Sprint Goal, implementa la funcionalidad con la tecnología tecnología que el equipo considera. Si el trabajo resulta ser diferente a lo que el equipo de desarrollo esperaba o han descubierto elementos que no esperaban, entonces colaboran con el Product Owner para negociar el alcance del Sprint Backlog dentro del Sprint.

Sprint Planning

El trabajo a realizar en el Sprint se planifica en la Sprint Planning. Este plan es creado por el trabajo colaborativo de todo el equipo de Scrum. La Sprint Planning tiene un timebox a ocho horas para un Sprint de un mes. Para Sprints más cortos, el evento es proporcionalmente más corto. La Sprint Planning consiste en dos partes, ambas partes de la Sprint Planning responden a las siguientes preguntas, respectivamente:

Sprint Retrospective

El Sprint Retrospective es una oportunidad para que el Scrum Team se inspeccione a sí mismo y cree un plan de mejoras para ser impulsado durante el próximo Sprint. El Sprint Retrospective se produce después de la Sprint Review y antes de la próxima Sprint Planning. Este evento es de tres horas como maximo para los Sprints de un mes. Para Sprint más cortos este evento es proporcialmente más corto.

Sprint Review

La Sprint Review se realiza al final del mismo para inspeccionar el incremento y adaptar el Product Backlog si es necesario. Durante la Sprint Review, el Scrum Team y los Stakeholders colaboran sobre lo que se hizo en el Sprint. En base a eso y a cualquier cambio en el Product Backlog durante el Sprint, los asistentes colaboran en los siguientes elementos que se podrían hacer. Esta es una reunión informal, y la presentación del incremento tiene como objetivo obtener feedback y fomentar la colaboración. Este evento tiene una duración cuatro horas para los Sprints de un mes. Proporcionalmente se asigna menos tiempo para los Sprints más cortos.

Velocity

Es una medida que indica, cuánta funcionalidad de negocio se crea durante un período de tiempo, muchos equipos suelen otorgar puntos historia para poder cuantificar está métrica. Esta metrica no está pensada para comparar equipos, ni para evaluzar el rendimiento individual. Sino es una herramienta al servicio del equipo para poder inspeccionar y adaptar.