En los proyectos de software es necesario asignar tareas específicas a los miembros del equipo de trabajo con base en sus competencias y habilidades.

Cada asignación debe especificar claramente qué tareas se tienen que realizar y cuál es el resultado esperado, retomando criterios de aceptación concretos como parte del aseguramiento de la calidad de cada entregable.

Desde esta perspectiva, el enfoque ágil de Scrum permite la planeación del trabajo de una manera flexible y rápida, favoreciendo la generación de entregables de calidad por incrementos. Su filosofía se basa en administrar los requerimientos del usuario, priorizarlos, estimar el esfuerzo, ejecutar el trabajo y entregar un paquete funcional al cliente.

En este tema revisarás cómo gestionar los entregables de un proyecto bajo el enfoque Scrum, utilizando el artefacto del Product Backlog, donde cada elemento tiene una prioridad asignada por el Product Owner según las necesidades del cliente, el valor para la organización y los cambios en el mercado. También examinarás la forma en la que el Scrum Team debe seleccionar el trabajo del Backlog que se ejecutará en cada sprint, estimando, de manera consensuada, el esfuerzo necesario, ejecutando las tareas asignadas y declarando cuándo se han finalizado.

Dimensionamiento y refinamiento del Backlog

Para dimensionar la cantidad de trabajo de un proyecto bajo el enfoque Scrum, el primer paso es preguntarle al cliente lo siguiente: ¿qué espera obtener? o ¿a qué resultado desea llegar?

En el contexto del desarrollo de software a esto se le llama análisis de requerimientos, que es una primera etapa en la que se documentan las necesidades del usuario o cliente. En Scrum, dicha documentación se basa en la realización de User Stories, que son historias cortas donde se describen acciones de los usuarios finales del software que se está construyendo. Una User Story, o historia de usuario, tiene tres partes: el actor, la narración breve y el criterio de aceptación.

Se trata de una estructura minimalista que permite al usuario centrarse solamente en la parte de lo que quiere que realice el software, en lugar de entrar en detalles sobre alternativas de solución. Por otro lado, la parte que se refiere a cómo se va a llevar a cabo dicho desarrollo de software es un trabajo que realiza el Scrum Master en un análisis posterior.

El International Scrum Institute (2019) recomienda usar la siguiente plantilla para documentar las User Stories:

En esta plantilla cada elemento está perfilado en términos específicos:

El actor: es la persona que interactúa con el sistema. La recomendación es que sea lo más específico posible, por ejemplo, un administrador, un cliente autenticado, un visitante.

La acción: describe aquello que el actor desea o debe realizar al interactuar con el software.

Logro/resultado: explica el resultado esperado de la acción.

A continuación, observa algunos ejemplos de User Stories:

Como podrás apreciar, a través de este tipo de declaraciones, el usuario describe claramente lo que quiere lograr, desde su perspectiva, enfocándose solo en la acción + el resultado. Vistas en conjunto, todas las historias de usuario conforman el Scrum Product Backlog.

Estimaciones del esfuerzo

El Scrum Team analiza cada User Story con el fin de obtener una estimación del trabajo que implica. La estimación del trabajo la utiliza el Product Owner para priorizar los elementos del Product Backlog.

Cabe aclarar que es muy importante que en el ejercicio de estimación del esfuerzo no intervenga el Product Owner, ya que podría sesgar esta estimación a favor de sus intereses por generar resultados lo antes posible. Así se evitaría que el equipo de trabajo no se sienta presionado por el Product Owner.

Las estimaciones del esfuerzo pueden ser dimensionadas según:

• Su tamaño: 1, 2, 3...10, donde el 1 es un tamaño pequeño y 10 constituye un esfuerzo 10 veces más grande.
• Potencia 2: 1, 2, 4, 8, 16, 32, 64.
• Secuencia Fibonacci: (0, 1, 2, 3, 5, 8, 13, 21, 34, etcétera).

Nota: Puedes usar cualquier otra escala que describa cantidades incrementales de esfuerzo.

El equipo de trabajo debe llegar a un acuerdo sobre la unidad de estimación utilizada.

Estimación del esfuerzo mediante Scrum Poker

Es un método de estimación que produce resultados muy acertados y que se basa en el juego de cartas denominado poker. Fue creado por Mike Cohn como una herramienta de planeación ágil en 2014. A continuación, se describen los pasos de este método, solo que se requiere tener/hacer lo siguiente antes de iniciar:

1. Enlistar las User Stories del Product Backlog.
2. Tener un mazo de cartas numeradas.

Es recomendable utilizar la numeración Fibonacci para evitar entrar en discusiones sobre si una estimación es alta, pero su distancia es muy corta. Es más sencillo determinar que una estimación es 13 en lugar de 21.

Por otra parte, si la estimación es muy alta, es posible que el equipo tenga que descomponer aún más la User Story en cuestión, o bien, puede ser que su descripción sea tan ambigua que el equipo no la entiende.

Es una parte natural del proceso de estimación, en la cual los miembros del equipo suelen incrementar sus estimaciones con el fin de tener tiempo extra para cualquier imprevisto, de manera que puedan tener una reserva por si surgen imprevistos en el camino. Es aquí donde el Scrum Master puede intervenir para ofrecer una estimación más real según su experiencia.

Los pasos del Scrum Poker son los siguientes:

Definición de "Terminado" (DOD)

El término DoD, o Definition of Done, es importante en el enfoque Scrum, puesto que señala el momento en el que una característica del software está terminada y cumple con los requisitos funcionales y no funcionales esperados, así como los estándares de calidad sobre el diseño, código, pruebas unitarias y criterios de evaluación del cliente.

El marco de trabajo de Scrum establece que el Scrum Team no puede decidir si la User Story ha concluido, pues no puede ser juez y parte. Para ello se requiere una revisión del resultado generado con una lista de verificación.

Según el International Scrum Institute (2019), un DoD no es estático y puede ser discutido entre los miembros del equipo o los mismos interesados del proyecto, siempre y cuando estén alineados al éxito del mismo. Entre los niveles de DoD se pueden encontrar:

Product Backlog

Este artefacto gestiona todos los requerimientos del proyecto Scrum encaminados a la generación de valor para el negocio, el usuario o el cliente. Si un requerimiento se encamina por otra dirección, deben descartarlo, ya que ocasionaría desperdicios de tiempo y esfuerzo.

Al interior del Product Backlog, no solo encontrarás User Stories, sino también prerrequisitos (condiciones que se deben cumplir antes de iniciar el proyecto), requisitos de prueba o ambientes de desarrollo, así como características complementarias del software.

Características del Backlog:

Aquí se expone el ejemplo de un Product Backlog:

Backlog Refinement

El refinamiento del Product Backlog consiste en mantener actualizados los requerimientos del proyecto. Se recomienda que este proceso se lleve a cabo en una sesión de 30 minutos, dos veces por semana, con la participación del Scrum Team, Product Owner y el Scrum Master.

Las acciones por realizar en este evento son las siguientes:

Algunas recomendaciones que hace el International Scrum Institute (2019) para facilitar este proceso de refinamiento son las siguientes:

• Involucrar a todo el equipo: revisa que todos los miembros del equipo participen en el refinamiento lo antes posible.
• Asegurar una estimación y prioridad adecuada: si los elementos del backlog se encuentran estimados y priorizados adecuadamente, se asegurará que puedan entregarse en el periodo de un sprint.
• Mejorar el proceso de estimación: cada sprint arrojará información sobre la estimación asignada. Considera esta información para la estimación futura.
• Identificar dependencias: reconoce si el esfuerzo de un sprint depende del trabajo de otro equipo.
• Descubrir riesgos: es un buen momento para tomar en cuenta los posibles riesgos que impactan en el proyecto.

Simulación del sprint

Existen algunas plataformas con las que puedes llevar el control de un proyecto Scrum, por ejemplo, Jira, Trello, Rally, Asana, Pivotal tracker, Bugzilla, Basecamp, Redmine, entre otras opciones que podrás encontrar en Internet. La mayoría utiliza tableros Kanban para darle seguimiento a las tareas de un sprint.

En este curso usarás la versión gratuita de Jira, que es una plataforma que permite trabajar con proyectos Scrum desde una interfaz web sencilla. Tiene la ventaja de que puedes limitar la cantidad de trabajo asignado a una persona, permitiendo que tu equipo de trabajo visualice las tareas asignadas y su avance.

Enseguida, se describirán los pasos para usar esta herramienta.

El siguiente enlace es externo a la Universidad Tecmilenio, al acceder a él considera que debes apegarte a sus términos y condiciones.

Paso 1. Crea una cuenta desde la siguiente página: https://www.atlassian.com/software/jira

Esta pantalla se obtuvo directamente del software que se está explicando en la computadora, para fines educativos.

Paso 2. Crea un proyecto llamado "Mi Proyecto Scrum" usando la plantilla de Scrum.

Esta pantalla se obtuvo directamente del software que se está explicando en la computadora, para fines educativos.

Paso 3. Incluye herramientas con las que puedas conectar con tu equipo, por ejemplo, Microsoft Teams.

Esta pantalla se obtuvo directamente del software que se está explicando en la computadora, para fines educativos.

Paso 4. Invita a tus compañeros al equipo. Recuerda que un proyecto Scrum debe estar integrado por equipos que tengan de cuatro a nueve miembros. Para efectos del presente ejemplo, agrega tres contactos para que formen parte de tu equipo y haz clic en el botón "Listo".

Esta pantalla se obtuvo directamente del software que se está explicando en la computadora, para fines educativos.

De esta forma, estarás listo para comenzar con una simulación del proyecto Scrum.

Para iniciar, generarás una lista de User Stories que serán parte del Product Backlog. En Jira se les denomina incidencia o issue.

Para generar esta lista, usarás la opción de creación rápida en el Backlog haciendo clic en [ir al backlog] y respondiendo a la pregunta: ¿qué se debe hacer? Puedes utilizar alguno de estos ejemplos:

Es recomendable que la primera columna del tablero Kanban tenga el nombre de Backlog. Puedes modificar los nombres haciendo doble clic sobre el título de las columnas.

Observa que cada User Story es numerado a partir de las siglas del nombre del proyecto + un número consecutivo: MPS-1, MPS-2, etcétera.

Esta pantalla se obtuvo directamente del software que se está explicando en la computadora, para fines educativos.

Posteriormente, prioriza las actividades. En Jira basta con arrastrar cada incidente en el orden de importancia. Para realizarlo, selecciona las User Story que formarán parte del primer sprint y arrástralas a la sección correspondiente.

Luego, haz clic en "Iniciar Sprint". Jira desplegará este cuadro de diálogo con el que puedes configurar el nombre del sprint, su duración, la fecha de inicio y el objetivo. La fecha de finalización se calculará de manera automática.

Esta pantalla se obtuvo directamente del software que se está explicando en la computadora, para fines educativos.

El siguiente paso será realizar el evento llamado Sprint Planning. En este momento será importante estimar los story points y asignar la tarea a un miembro del equipo.

Esta pantalla se obtuvo directamente del software que se está explicando en la computadora, para fines educativos.

En caso de que algún User Story o historia de usuario sea muy grande para ser realizada en el periodo de tiempo destinado para el sprint, puedes subdividirla en tareas más cortas haciendo clic en la opción de "Añadir una incidencia secundaria".

Después, vas a simular que avanzas las tareas entre los tableros. Recuerda que puedes agregar nuevas columnas en tu tablero. Por ejemplo, una columna llamada "En Revisión" para aquellas User Stories que deban ser validadas antes de considerarse terminadas. Otra puede ser "Bloqueadas" para aquellos casos en donde no es posible avanzar y se requiere de alguna intervención por parte del Scrum Master o del Product Owner.

Esta pantalla se obtuvo directamente del software que se está explicando en la computadora, para fines educativos.

Enseguida, avanza las tareas hasta la columna "Listo" y haz clic en el botón "Completar Sprint".

Esta pantalla se obtuvo directamente del software que se está explicando en la computadora, para fines educativos.

Considera que al final de cada sprint se realizan los eventos del Sprint Review y Sprint Retrospective antes de continuar con el siguiente sprint.

Gestión de los incrementos

Según Schwaber y Sutherland (2020), "un incremento es un peldaño concreto hacia el Objetivo del Producto". Dicho de otra forma, en cada iteración o sprint, el equipo de trabajo agrega una funcionalidad adicional al proyecto de software en construcción. Es muy parecido a una construcción de una torre en la que se van agregando hileras de ladrillos hasta convertirla en un faro.

Cada incremento es evaluado por los interesados durante el evento llamado Sprint Review. Aquí validan que cumpla con los criterios de aceptación previamente definidos. Muchos lo consideran como un Sprint Demo porque realizan una demostración del trabajo realizado.

Sprint Review

Es una reunión a la que se invita a los interesados del proyecto, en la que se presenta la funcionalidad agregada al sistema. En este momento, los interesados pueden trabajar con la funcionalidad y emitir una evaluación, compartir comentarios de retroalimentación, agregar requerimientos nuevos con User Stories que se incluyen en el Product Backlog o incluso volver a hacer ajustes a la función recién entregada.

Este es un evento que no debe tratarse como una reunión de seguimiento o de justificación de los posibles retrasos de la entrega del resultado del sprint, sino como una buena oportunidad para retroalimentar al equipo de trabajo sobre el resultado, que además fortalece la confianza y colaboración del equipo de trabajo, así como la transparencia, que es uno de los pilares del enfoque Scrum.

Por lo general, es una reunión que organiza el Product Owner, pero que es moderada por el Scrum Master. En este escenario, es responsabilidad del Product Owner invitar a los interesados del proyecto involucrados en la revisión de las funcionalidades generadas durante el sprint. La sesión debe incluir una descripción de los elementos tomados del Product Backlog y explicar a la audiencia el acuerdo al que se llegó como DoD.

Aquí es donde los miembros del Scrum Team demuestran las funcionalidades terminadas. Es preferible que sea el mismo responsable asignado al User Story. Si existen varios elementos del Backlog relacionados, se puede asignar a un miembro del equipo que explique todo el módulo de las User Stories. Los interesados pueden realizar preguntas sobre el módulo y hacer comentarios de retroalimentación que serán recopilados por el Product Owner. Esta información será parte esencial del Sprint Planning de la siguiente iteración.

Sprint Retrospective

Este evento lo organiza el Scrum Master. Su principal objetivo es crear una sesión de lecciones aprendidas después de terminar un sprint. Esta es la oportunidad para que el equipo del proyecto establezca un proceso de mejora continua y concentre todos sus esfuerzos hacia la creación de valor para la organización.

A este respecto, Igbal (2021) recomienda que se motive a otros miembros del equipo para que sean facilitadores de este evento, ya que puede abrir otros enfoques y perspectivas del trabajo. De igual forma, en el evento se pueden tener invitados que directa o indirectamente estén involucrados en el proyecto.

En opinión del especialista, se puede elaborar el siguiente tablero para utilizarlo en algún evento de sprint Retrospective. En este tablero, se colocan Post-it o Sticky Notes según la columna. De forma consensuada, hay que seleccionar de 1 a 3 notas de mejora para el siguiente sprint.

Hay que señalar que es posible que durante la sesión se aborden problemas que surgieron en el sprint, pero que es complicado identificar cuál es su causa raíz. Para esos casos, existe una herramienta muy útil: el ejercicio de los cinco porqués:pero

En este ejercicio, el Scrum Master es un observador en cuanto a la ejecución de los eventos y debe identificar si surge algún riesgo (amenaza/oportunidad) que deba ser considerado en algún análisis posterior que precise de la realización de un plan de respuesta específico.

En este tema revisaste cómo administrar las User Stories que pertenecen al Product Backlog. Considera que cada requerimiento del Backlog debe ser priorizado dependiendo de la importancia y urgencia de la funcionalidad esperada, mientras que la estimación del esfuerzo es un ejercicio que le corresponde a los developers, que son guiados por el Scrum Master.

Cuando el equipo de trabajo selecciona los User Stories que serán parte del sprint, se genera un compromiso individual y colectivo para hacer realidad dichas asignaciones, de manera que todo el equipo trabajará en colaboración y se mantendrá motivado hasta generar el resultado esperado al finalizar el sprint.

A todas luces, los sprint Reviews y sprint Retrospectives son eventos indispensables para presentar los avances del proyecto, obtener retroalimentación del trabajo realizado y establecer un proceso de mejora continua para el siguiente sprint.

Asegúrate de:

• Priorizar y estimar el esfuerzo de trabajo de cada elemento del Product Backlog para planear el sprint.
• Familiarizarte con la herramienta Jira para usarla como una plataforma de planeación, ejecución, monitoreo y control del trabajo.
• Reconocer la utilidad de los eventos del sprint Review y sprint Retrospective para gestionar los incrementos.

Los siguientes enlaces son externos a la Universidad Tecmilenio, al acceder a ellos considera que debes apegarte a sus términos y condiciones.

Videos

Para conocer más acerca de los eventos Scrum, te sugerimos revisar lo siguiente:

• Atlassian. (2019, 4 de enero). Backlog Grooming - Agile Coach (2019) [Archivo de video]. Recuperado de https://www.youtube.com/watch?v=zkZJxvKzILY
• JorgeRuizAgile. (2018, 11 de agosto). El Product Backlog de forma sencilla | Scrum [Archivo de video]. Recuperado de https://www.youtube.com/watch?v=JuIVHk1wvcw
• Scrum.org. (2021, 8 de enero). What is a Sprint Review 2020 [Archivo de video]. Recuperado de https://youtu.be/uYHRRM9foMQ

Lecturas

Para conocer más acerca del refinamiento del Backlog, te sugerimos revisar lo siguiente:

• KeepCoding. (2022). ¿Qué es el Product Backlog en Scrum? Recuperado de https://keepcoding.io/blog/que-es-el-product-backlog-en-scrum/
• Rocha, G. (2021). El incremento en Scrum. Recuperado de https://profile.es/blog/incremento-scrum/