¿What purpose does the Scrum Artifacts have?

Layer 08: #scrumartifacts¿What do they represents?

In the previous article we talked about the #scrumframework and what organizations needs to take into accout to be able to implement thr Professional #scrum. As we mentioned before, applying Scrum partially or if applied in a poor way, Scrum will become much of a burden instead of something profitable. We still have a lot to cover concerning the Scrum Framework and in this case, we are going to talk about the Scrum Artifacts. These Scrum Artifacts are: #productbacklog, #sprintbacklog and #increment.

These artifacts makes the plan for the product or service being developed visible to anyone, so there is #transparency in the work done. These artifacts represents work and value the team can deliver at the end of each Sprint, and its kind of a guide for #inspection and #adaptation that must be done as the team clearly knows where they stands at towards the #sprint and #productgoal. Each of these artifacts has its own commitments which helps the team to understand if they are making progress or if there is an impediment for the team to progress. 

¿What are the commitments of each artifacts?

* Commitment for the Product Backlog: The Product Goal

* Commitment for the Sprint Backlog: The Sprint Goal

* Commitment for the Increment: the Definition of Done

These commitments exists to reinforce #empiricism as the team operates in a complex environment where more is unknown than known. Here is when the #scrumvalues comes into play, which are: #commitment, #focus, #courage, #respect and #openness; because all the efforts of the team goes into delivering value and achieving the #productgoal, the #sprintgoal and #definitionofdone (#dod) with these Scrum Values and the customer in mind.

So, ¿How would we define these artifacts?

* Product Backlog: Is an emergent list of what is needed to improve the product or service. It is the only source of work that the #developerteam takes, as the items listed are already approved by the Product Owner. This does not means that the Product Backlog cannot be changed or updated in the future, is just that the Product Backlog is managed by the #productowner, sometimes with the help of the developers but he/she is the one who makes the final decision, if someone wants to modify the Product Backlog order or to add a new feature or service to be developed, that person needs to do it through the Product Owner. In addition, the Product Owner is accountable for ordering the Product Backlog with the highest delivering value in mind and the developers are accountable for the sizing of the #productbacklogitems (#pbi).

* Sprint Backlog: Is the Developers plan of the upcoming work to do. This artifact has to answer three question to be able to be effective: 1) The Why, 2) The What, 3) The how. The Sprint Backlog is a list of items composed of: The Sprint Goal (The Why), A set of Product Backlog Items selected for the Sprint (The What), A plan for delivering the Increment (The how). This plan is done by the developers and is also updated by the developer team as more is learned throughout the Sprint. As they inspect their progress towards the Sprint Goal during the #dailyscrum, although it is not mandatory to wait to this session to update their plan, they can update and adapt this plan as needed throughout the Sprint as by their findings but they need to take into consideration that the #sprintgoal remains unchanged.

* Increment: Is the delivered value at the end of each Sprint by the team. ¿How can the team consider if an item of the Product Backlog can become an increment? Well, when it meets the Definition of Done (DoD). In addition to adhering to the Definition of Done, it has to be complemented with all prior Increments delivered and throughly verified by ensuring every increment delivered keeps working including this one. Within a Sprint, multiple increments may be created and they can be shipped to production before or after the #sprintreview as this never should be considered as a gate for release. Even though an increment is displayed during the Sprint Review the team may consider to not ship it into Production Environment until it makes sense. That is to say, the team may consider shipping it to production when they deemed it reasonable.

These three Artifacts needs to be based on one of the Scrums foundations, which are these three pillars: Transparency, Inspection and Adaptation. Each of these artifacts contributes to the visibility of the product or service being worked on and the progress towards the Product and Sprint Goal. It also gives to the whole team and even the stakeholders a certainty of what have been accomplished and what not. Through the lens of transparency they can inspect the current situation and then they can adapt their plans, their processes, their environment, their organizational practices and of the sorts for them to align to the objective of the organization. Subjects like these can be addressed at the #scrumretrospective.

So far, ¿have you found something that is not crucial for the effective implementation of the Scrum Framework?, ¿Does the framework goes beyond from what the organization expected? We still have a lot to cover because we have not finished the theoretical concepts yet and we have got to talk about the practical implementation of the framework within your organization. Please, join me in this journey until we get there and discover the benefits of implementing Scrum and becoming Agile. I'd love hearing from you.

Please, feel free to leave a comment below with suggestions, inqueries and experiences.

Artículo 08: Artefactos de Scrum ¿Qué representan?

En el artículo anterior, conversamos sobre el marco de Scrum y qué deben tomar en consideración las organizaciones para poder implementar Scrum profesional. Tal como mencionamos anteriormente, aplicar partes específicas de Scrum en lugar de aplicar el marco completo o si se aplica el marco completo pero de una manera incorrecta, esto convertirá a Scrum en una carga mas bien que en algo rentable o beneficioso. Todavía tenemos mucho de qué hablar sobre el Marco de Scrum y en esta ocasión, hablaremos de los Artefactos de Scrum. Estos Artefactos son: Product Backlog, Sprint Backlog y el Incremento.

Estos artefactos permiten que el plan utilizado por el equipo para desarrollar el producto o el servicio sea visible para todos, así de esta forma, habrá transparencia en el trabajo realizado. Estos artefactos representan el trabajo y el valor que el equipo puede entregar al final de cada Sprint y también es una especie de guía para la inspección y adaptación que se debe hacer, ya que el equipo puede detectar claramente en el punto en que se encuentra con respecto a la meta del Producto y del Sprint. Cada uno de estos artefactos tiene sus propios compromisos que en primera instancia ayudan a los equipos a comprender si están progresando o si tienen algún impedimento para progresar en el trabajo.

¿Cuáles son los compromisos para cada artefacto?

* Compromiso para el Product Backlog: La meta del Producto

* Compromiso para el Sprint Backlog: La meta del Sprint

* Compromiso para el Incremento: La deficinión de Terminado (Definition of Done)

Estos compromisos existen para reforzar el Empirismo ya que el equipo se desenvuelve en un entorno complejo donde es más lo desconocido que lo que se conoce. Aquí es donde entran en juego los Valores de Scrum, que son: Compromiso, foco, coraje, respeto y apertura; porque todos los esfuerzos del equipo están dirigidos a entregar valor y a cumplir con el objetivo del producto, el objetivo del Sprint y a la definición de terminado teniendo en mente estos valores y el cliente.

Así que, ¿Cómo definiríamos estos artefactos?

* Product Backlog: Es una listado de pendientes para desarrollar o mejorar un producto o servicio. Esta es la única fuente de trabajo para los desarrolladores, ya que los elementos que están listados aquí son previamente aprovados por el Product Owner. Esto no significa que el Product Backlog no pueda ser actualizado en el futuro, es solo que el Product Backlog es administrado por el Product Owner, a veces con la ayuda de los desarrolladores, pero él/ella es quien toma la decisión al final. Si hay alguien que quiera modificar este listado o añadir alguna funcionalidad o servicio, esta persona debe convencer al Product Owner de hacer este cambio. Adicionalmente, el Product Onwer es responsable de ordenar esta lista tomando en cuenta el mayor valor que aporta cada uno de estos entregables y los desarrolladores son responsables de asignar el grado de complejidad de cada uno de sus elementos.

* Sprint Backlog: es el plan del próximo trabajo a realizar por los desarrolladores. Este artefacto debe responder a 3 preguntas para lograr que sea efectivo: 1) El por qué, 2) El qué, 3) El Cómo. Ahora, el listado del Sprint Backlog se compone de lo siguiente: La meta del Sprint (El por qué), un conjunto de elementos del Product Backlog que se han seleccionado para el Sprint (El qué), un plan diseñado para generar el incremento (el cómo). Este plan es diseñado por los desarrolladores y también es actualizado por ellos mismos a medida que van descubriendo cosas durante el Sprint. En el Daily Scrum los desarrolladores actualizan su plan diario para cumplir con la meta del Sprint, no es obligatorio que los desarrolladores esperen hasta este momento para actualizarlo, a medida que inspeccionan su progreso, este listado debe ser actualizado y adaptado según sea necesario a medida que van descubriendo cosas durante el Sprint pero tomando en cuenta que la meta del Sprint no puede cambiar.

* Incremento: Es la entrega de valor que ha hecho el equipo cuando se termina el trabajo. ¿Cómo puede el equipo considerar que un elemento de Product Backlog puede convertirse en un Incremento? Bueno, cuando este cumple con la definición de terminado (Definition of Done). Además de adherirse a la definición de terminado, este debe complementarse con todos los incrementos anteriores y pasar por una rigurosa verificación para que el equipo pueda garantizar que todos los incrementos anteriores sigan funcionando, incluyendo la entrega actual. En cada Sprint, se pueden crear multiples incrementos que pueden ser desplegados en producción antes o después del Sprint Review, ya que este nunca debe ser considerado una ventana para hacer despliegues. A pesar de que se haya mostrado un incremento en el Sprint Review el equipo podría considerar no desplegarlo a producción hasta que esta funcionalidad o servicio tenga sentido que sea desplegado, es decir, puede ser desplegado cuando consideren apropiado.

Estos tres artefactos deben basarse en los fundamontos de Scrum en uno de los fundamentos de Scrum, en los tres pilares que son: Transparencia, Inspección y Adaptación. Cada uno de estos artefactos contribuye a tener visibilidad sobre el producto o servicio en el que se está trabajando y en cuanto al progreso que se ha llevado a cabo para cumplir con la meta del Producto y del Sprint. Esto también provee a todo el equipo, incluso a las partes interesadas, a tener una certeza de lo que se ha logrado o no. A través de la transparencia, se puede inspeccionar la situación actual en la que están y luego pueden adaptar sus planes, sus procesos, su entorno, sus prácticas organizacionales y así por el estilo para que el equipo pueda alinearse al objetivo de la organización. Temas como estos pueden tratarse en la Retrospectiva del Sprint (Sprint Retrospective).

Hasta el momento, ¿han logrado encontrar algo que no sea crucial para la implementación efectiva del Marco de Srum?, ¿A caso el Marco de Scrum es más complejo de lo que la organización esperaba? Bueno en realidad todavía nos falta mucho camino que recorrer en lo que al Marco de Scrum respecta, ya que no hemos terminado la parte teórica todavía y además nos falta hablar de la aplicación práctica del marco en la organización. Por favor, acompáñenme en este viaje y descubramos los beneficios de implementar Scrum y volvernos Ágiles. Me encantaría saber lo que piensan.

Los invito a que por favor me dejen sus comentarios, sugerencias o experiencias sobre el tema.