Agile
Conjunto de valores y principios que crearon en el año 2001 veintiún expertos en desarrollo software. Es un mindset sobre cómo debemos desarrollar software con diferentes características. Hoy en día, Agile ha trascendido el software y se ha extendido a todas las áreas de las organizaciones. Para saber más sobre esos valores y principios, aquí disponéis de más información.
Accountability
En Inglés, disponemos de dos palabras para expresar responsabilidad: Responsible y Accountable. Esta segunda significa “el que rinde cuentas”. Es decir, un Product Owner tiene el Accountability de gestionar el Product Backlog, pero podrá delegar en otra persona el Responsible. Eso sí, en caso de fallo, el que rinde cuentas es el Product Owner.
Daily Scrum
Es uno de los eventos Scrum que se realiza diariamente. En este evento,los Developers de un Scrum Team inspeccionan y adaptan su Sprint Backlog para acometer el Sprint Goal que se han propuesto durante el Sprint.
Definition of Done (DOD)
Es una definición formal que describe el estado del incremento para cumplir con las medidas de calidad que hayamos definido para el producto. La DOD permite crear transparencia, ya que eliminamos trabajo oculto al garantizar que todo incremento la cumple.
Definition of Ready (DOR)
La Definition of Ready es un conjunto de condiciones que debe cumplir cada Item que introducimos en un Sprint. La DOR es peligrosa, ya que podría conducir a una micro-cascada en la que creamos fases de análisis y desarrollo con reglas. Sin embargo, puede ser usada para facilitar una conversación dentro del Scrum Team que permita averiguar r qué necesitan los items para poderse abordar con garantías y, así, reducir sorpresas durante el Sprint.
Developers
Los Developers son las personas que, perteneciendo a un Scrum Team, se encargan de la creación y mantenimiento del Producto. Además, estas personas se comprometen a crear cualquier aspecto que permita entregar un incremento usable cada Sprint.
Demo
Muchos equipos llaman, erróneamente, a la Sprint Review “la demo”, debido a una mala formación o a un mal entendimiento del evento. Una Sprint Review no es una demostración, su función es inspeccionar y adaptar, por lo que es una reunión de trabajo en la que nos “remangamos” para tomar decisiones y mejorar la entrega de valor.
Incremento
Cada vez que finalizamos parte del trabajo para alcanzar nuestro Product Owner, generamos un incremento. El incremento debe ser usable y cumplir con la Definition of Done. Cada vez que creamos un incremento, debemos integrarlo con el resto de incrementos que hayamos desarrollado hasta ese momento.
Historias de Usuario (User Stories)
Las Historias de Usuario son una técnica independiente respecto a Scrum. Scrum no prescribe su uso y, por tanto, son opcionales. Las Historias de Usuario constituyen una técnica que debe ayudar a definir los requisitos desde el punto de vista de la interacción del usuario con el producto o del desarrollo de su trabajo. Lo ideal es que sean escritas por los usuarios o personas muy cercanas a su realidad. Por encima de todo, las Historias de Usuario buscan habilitar una conversación entre las personas que tienen el problema (usuarios, customers…) y las personas que van a resolverlo (developers).
Marco de trabajo
Scrum se define como un marco de trabajo (framework en inglés), es decir, un conjunto de prácticas, métodos, herramientas, etc. que, unidas, componen Scrum. Además, se entiende Scrum como un marco incompleto y ligero: cada equipo debe completarlo con aquellas prácticas que le permitan generar el máximo de valor posible según su contexto o circunstancias.
Metodología
Scrum no es una metodología por dos motivos. Usamos mucho la palabra “metodología” para referirnos a manera de proceder. Realmente, la metodología es “el estudio de los métodos”. Un ejemplo: no decimos “metodología científica”, sino “método científico”.
Aún así, Scrum no es un método, su definición exacta sería: conjunto de prácticas, técnicas, reglas etc. que componen un marco de trabajo.
Product Backlog
El Producto Backlog es uno de los tres artefactos que componen Scrum. Su función es recoger todo aquello que queremos que tenga nuestro producto o que pueda llegar a tener. Está ordenado según el criterio del Product Owner que, además, es el encargado de gestionarlo. Debe ser transparente para el Scrum Team y cualquier Stakeholder. Si no refleja el trabajo real que queremos acometer, difícilmente podremos tomar decisiones correctas.
Product Backlog Item (PBI)
El Product Backlog está compuesto de elementos (PBIs). Un PBI es cualquier acción que hay que acometerer en nuestro producto. Existen muchos tipos de PBIs, en función del tipo de producto que se esté construyendo, algunos ejemplos son: historias de usuarios, casos de uso, mejoras técnicas, incidencias (bugs)…
Product Goal
Los productos construidos con Scrum cuentan con un objetivo a largo plazo llamado Product Goal. Este elemento fue incluído en la última revisión de la guía (2020). Cada Sprint trata de acercarnos a ese Product Goal. Solo debe existir uno aunque podremos cambiarlo por otro más adecuado si fuera necesario.
Product Owner / Dueño de Producto
Dentro de un Scrum Team, el/la Product Owner es la figura que se encarga de maximizar el valor del resto del equipo. Para ello, debe decidir qué se hace en cada momento, para lo que utiliza el Product Backlog. Debe estar pendiente de los interesados y del resultado que el producto provoca en ellos, para tomar futuras decisiones que permitan maximizar valor.
Refinement / Refinamiento
El refinamiento es un proceso en el que el Product Owner y los Developers trabajan el Product Backlog para mejorar en el futuro: ser más predecibles, adelantar impedimentos y resolverlos, hacer previsiones, etc. Cuando refinamos el Product Backlog, podemos crear nuevos PBIs, eliminar aquellos que no tengan sentido, dividir los que sean muy grandes o modificar los existentes. Hay muchas maneras de refinar cada equipo debe buscar la que mejor le funcione.
Scrum
Scrum es un marco de trabajo ligero que ayuda a las personas, equipos y organizaciones a generar valor mediante soluciones adaptativas a problemas complejos.
Scrum Master
El Scrum Master es el responsable de establecer Scrum tal y como se define en la ScrumGuide. Para ello, se apoya en la teoría y práctica junto con el Scrum Team y la organización a la que pertenece.
En resumen, un Scrum Master trabaja con el Product Owner (para que ejerza bien su papel, también lo hace con el Scrum Team) para que funcionen como una unidad autogestionada y multifuncional, asimismo trabaja con la organización para que se implante Scrum. Todo esto debe servir para mejorar la entrega de valor de los diferentes equipos Scrum.
Scrum Team
Un Scrum Team es la unidad fundamental de Scrum. Debe ser pequeño (se recomienda un máximo de 10 personas), autogestionado, multifuncional. El Scrum Team es responsable de todo el trabajo relativo al producto. Para ello, deben estar empoderados por la organización, a la que sirven mediante la generación de valor. Son responsables de crear incrementos usables en cada Sprint.
Sprint
Se define como el latido de Scrum ya que marca el ritmo del equipo. Un Sprint es un periodo de tiempo inferior a un mes y contiene al resto de eventos Scrum: Spritn Planning, Daily Scrum, Sprint Review y Sprint Retrospective. Cada Sprint dispone de un motivo, el Sprint Goal. El Sprint Goal debe acercarnos al objetivo de nuestro Producto (Product Goal).
Sprint Backlog
El Sprint Backlog está compuesto por varios elementos: Sprint Goal (¿Por qué?), el conjunto de elementos que preveemos hacer en este Sprint (¿Qué?) y el plan para acometerlo (¿Cómo?).
Este artefacto es propiedad de los Developers ya que lo usan para organizarse durante el Sprint. Se crea en el Sprint Planning y se actualiza a medida que se avanza en el trabajo terminado.
Sprint Goal
El Sprint Goal es uno de los compromisos que adquieren los Developers durante el Sprint. Debe ser amplio para permitir abordarlo de muchas maneras. No cambia durante el Sprint ya que, de hacerlo, provocaría que cancelemos el Sprint y arranquemos uno nuevo.
El Sprint Goal es un elemento clave ya que nos proporciona foco durante el Sprint a la hora de entender qué es realmente importante. Debe guiarnos para justificar el motivo de que hagamos el presente Sprint y cómo acercarnos al Product Goal.
Sprint Planning
La Sprint Planning es el primer evento que tiene lugar durante el Sprint. Su función es planificar el trabajo que acometeremos en los próximos días o hasta finalizar el Sprint. Durante el Sprint Planning inspeccionamos el Product Backlog y creamos el Sprint Backlog.
Durante la Sprint Planning debemos trabajar tres topics:
- ¿Por qué hacemos este Sprint? Cuya respuesta es el Sprint Goal.
- ¿Qué vamos a hacer? Cuya respuesta son los elementos seleccionados del Product Backlog.
- ¿Cómo haremos el trabajo seleccionado? Los developers crean un plan de trabajo que les permita organizarse y trabajar con la máxima transparencia.
Sprint Retrospective
La Retrospectiva, como es lógico, tiene lugar al finalizar el Sprint. Los equipos Scrum utilizan la Retrospectiva para inspeccionarse a sí mismos: comportamientos, trabajo, colaboración, comunicación… Con ello, crean un plan de tareas que les permita mejorar y ser capaces de entregar más valor en futuros Sprints.
Este evento es clave para la mejora contínua, todos los miembros del Scrum Team deben estar presentes y todos son responsables del éxito del mismo.
Sprint Review
En Scrum trabajamos frente los resultados que nuestro producto provoca. Para saber si estamos yendo en el camino adecuado tenemos la Sprint Review. Durante la misma, el Scrum Team se reúne con los interesados (customers, users, management, equipos…) para inspeccionar el resultado del Sprint y del producto, de cara a adaptarse en futuros Sprints.
Este evento es informal y no debe limitarse a una presentación. Debemos trabajar intensamente para, con la colaboración de todos, decidir el futuro del Producto.
Stakeholders / Interesados
Se entiende por stakeholders o interesados las personas que tienen algún tipo de interés en el producto o en el equipo. Los motivos pueden ser varios, por tanto se pueden calificar los diferentes interesados para gestionar sus expectativas. Los stakeholders pueden ser: usuarios finales, clientes, customers, gerencia, otros equipos, administraciones…
