La Guía de Scrum contiene la definición de Scrum. Cada elemento del marco de trabajo tiene un propósito específico que es esencial para el valor general y los resultados obtenidos con Scrum. Cambiar el diseño o las ideas esenciales de Scrum, omitir elementos o no seguir las reglas de Scrum, oculta los problemas y limita los beneficios de Scrum, e incluso potencialmente lo vuelve inútil.
En el anterior artículo, hablamos de los cambios que había sufrido la guía a lo largo de los años, pero no detallamos esta última versión que continua con los cambios orientados a hacer Scrum agnóstico y a reconocer que se usa en muchas industrias más allá del desarrollo de Software. A continuación se presentan los 10 cambios más relevantes.
1.- Nueva definición de Scrum. Scrum se basa en el empirismo y el pensamiento Lean. El empirismo afirma que el conocimiento proviene de la experiencia y de la toma de decisiones con base en lo observado. El pensamiento Lean reduce el desperdicio y se enfoca en lo esencial. Introduciendo el concepto Lean Thinking que no estaba previamente.
2.- Definición de un nuevo objetivo. Product Goal relativo al Product Backlog siendo el objetivo del producto y describiendo el estado futuro del producto. La meta del Product Goal es servir de guía para entender cómo los esfuerzos de cada Sprint van dirigidos a un objetivo de negocio concreto. Habitualmente consistirá en un gran objetivo de negocio a ser conseguido a lo largo de uno o múltiples Sprint. Para situarnos en el lugar correcto, pensemos en el Product Goal como releases de nueva funcionalidad. Los equipos de desarrollo trabajan consiguiendo alcanzar Sprint Goals y una vez que se cumple el Product Goal, se pasa al siguiente.
De hecho, es tan importante que se ha ligado la propia existencia del Product Backlog a la existencia del Product Goal. Ahora, en el Sprint Planning, el equipo Scrum tiene que desarrollar un Sprint Goal que sirva de paraguas para el trabajo desarrollado durante el Sprint y que además esté asociado al Product Goal. El Product Goal es, además, una medida de progreso que la organización puede valorar a la hora de medir el valor generado.
3.- El Development Team deja de llamarse así para llamarlo Developers. Con esta actualización se quiere poner el énfasis en el equipo Scrum en su totalidad, evitando la posible tensión y división entre Product Owner y el equipo de Desarrollo, con el Scrum Master en medio, mediando entre unos y otros.
Los developers son autogestionados y deja de usarse el término auto-organizados en su definición. Se especifican las responsabilidades de los desarrolladores: crear el Sprint Backlog, cumplir con la definición de hecho y ver el progreso diario hacia la consecución del objetivo del Sprint.
4.- El término roles desaparece y pasa a usarse “accountable”. Se define un conjunto de elementos del que se es responsable y se dice que Scrum está conformado por responsabilidades, eventos y artefactos.
5.- La definición del Scrum Master como “Servant-Leader” pasa a ser “True Leader” quien ayuda/sirve al equipo y a toda la organización.
6.- El Sprint Planning pasa a tener 3 tópicos. Se añade el primer paso:
- ¿Por qué este sprint es valioso?
Y se mantienen:
- ¿Qué se puede hacer en el sprint?
- ¿Cómo realizaremos el trabajo seleccionado?
Se indica que el Product Owner debe asegurarse de que los asistentes a la reunión estén “preparados” para hablar de los elementos más importantes del Product Backlog. Mención expresa a que el Scrum Team puede invitar a otras personas a la reunión, para que aporten consejo. Antes solo el equipo de desarrollo invitaba a terceros.
7.- Se clarifica que en un sprint se puede entregar más de un incremento al cliente y que se pueden hacer entregas antes de la Sprint Review. La revisión del Sprint no debe considerarse el punto clave para entregar un incremento al cliente y la suma de los incrementos se presenta en la revisión del Sprint para apoyar el empirismo.
8.- Cada artefacto contiene un compromiso para garantizar que proporciona información que mejora la transparencia y el enfoque frente al cual se pueda medir el progreso.
9.- Desaparece terminología específica de software, para que sea más sencillo utilizarla en otros ámbitos.
10.- Se deja de lado el término estimación y se introduce el término dimensionamiento.
Add new comment