¿Cómo empezar? Prioridades y Backlog del Sprint

recomiendo esta aplicación https://airtable.com/invite/r/OFFmVEGv mezcla excel con trello e incluso tiene un template llamado product manager con toda la metodología desarrollada, me ayudo mucho a entender el proceso

**Lista de Pendientes del Sprint (Sprint backlog): **

• Es un subconjunto de la Lista de Producto (Product backlog) y contiene todos los elementos que serán desarrollados durante el Sprint.

• De estos elementos dependerá el incremento a desarrollar y los objetivos del Sprint.

• Debe tener suficiente detalle para que todo el equipo sea capaz de comprenderlo en los daily stand-ups (Scrum diario)

• Solo el equipo de desarrollo puede aceptar que se agreguen elementos al Sprint Backlog.

• Si un elemento se vuelve innecesario a mitad de un sprint se puede sacar de la lista de pendientes.

Definiendo prioridades
Se debe tomar en cuenta el siguiente orden para dar prioridad a las historias de usuarios:

• Lo que genera más valor para el cliente

• Urgencia: Por ejemplo, si una historia tiene una fecha para que se pueda utilizar o integrar al sistema.

• Riesgo/Oportunidad: Si la historia afecta positiva o negativamente a otras historias, es decir, si puede retrasar o agilizar a otras historias.

• Esfuerzo: Cuánto esfuerzo le tomará al equipo de desarrollo en completar la historia de usuario.

Hola a todos, en base a lo aprendido en el curso de Scrum he creado una plantilla en Trello que sirve como herramienta para documentar el proceso de priorización de historias de usuario. Documentar este proceso permite tener una visión completa de todas las historias y de las razones que fundamentan el abordar unas antes que otras.
La plantilla es pública por si desean utilizarla 😃
Cualquier sugerencia será bienvenida
Les dejo el enlace: https://trello.com/b/USqpPlem/backlog-prioritization-process-template/mariagabrielane/recommend

para comentar entre Jira y trello , jira tiene mejores opciones en su version free el unico limite son 10 usuarios en el proyecto.

Sprint Backlog

¿Por dónde comenzar? Prioridades y backlog del sprint

• Backlog del Sprint: Es un subonjunto de la lista del producto y contiene todos los elementos que serán desarrollados durante el sprint.

Todas las personas que participan del scrum diario deben tener conocimiento del Sprint-backlog. Solo el equipo de desarrollo puede aceptar que se agreguen elementos al sprint Backlog.

Definiendo prioridades:

• Valor para el Cliente
• Urgencia
• Riesgo / Oportunidad
• Esfuerzo.

Algunas herramientas populares para gestión de proyectos con el modelo Kanban:

.

• Notion
• Clickup
• Airtable
• Quire
• SamePage
• Monitask
• Nifty
• Wrike
• Celoxis
• Meistertask
• Miro
• Trello
• Jira
  .
  Ahora que todo se aceleró a lo digital muchas de las herramientas que existían han aumentado las funcionalidades que tienen hasta poder hacer prácticamente de todo y buscando encabezar el gusto de los equipos de trabajo al hacer que se pueda trabajar en una sola aplicación en lugar de usar varias. Notion es la que utilizo y hasta ahora es fenomenal, Trello es un clásico y por la gran cantidad de plantillas y número de usuarios será difícil que la reemplacen en el corto tiempo. Clickup es otro todo terreno que está comenzando a ser conocido por sus múltiples funcionalidades. Agrego otros clásicos como Airtable y Jira más otros menos conocidos pero con muy buena pinta y buenos reviews.

Les dejo mi mapa 😄

En el tema del valor para el cliente considero que es importante tener la información completa, puesto que habrá historias que para nosotros como equipo de desarrollo generan valor pero para el cliente no tanto. Y por eso es importante tener una comunicación clara de manera que podamos expresarle al usuario cliente él porque algunas historias general más valor que otras pero asimismo el también nos puede argumentar desde su perspectiva de dueño del negocio.

Backlog del sprint es una parte de la lista del producto y contiene las HU que van a ser desarrollados durante el sprint. De estas HU dependerá el incremento del productos y los objetivos del sprint. Debe tener un detalle suficiente para que todo el equipo sea capaz de entenderlo.

El dueño del backlog del sprint es el equipo de desarrollo, tienen toda la potestad para no aceptar HU a mitad del sprint, normalmente no se deben incluir HU una vez comenzado el sprint. Durante el desarrollo del sprint se pueden eliminar HU si se vuelven irrelevantes.

¿Cómo definir las prioridades?

• Valor para el cliente.

• Urgencia.

• Riesgo / Oportunidad: si no hago esta HU qué tanto me puedo atrasar respecto a las HU que vienen adelante. si no hago la HU de registro de usuarios al sistema qué tanto se puede atrasar la HU del carrito de compras, historial de pedidos del usuario, preferencias de producto del usuario. Si hago esta HU cuántas HUs más puedo desarrollar.

• Esfuerzo: qué tanto esfuerzo le va a tomar al equipo completar esta HU.

Backlog del sprint (o lista de pendientes del sprint) y prioridades
Es un subconjunto de la lista de producto que contiene los elementos (historias de usuario) que se desarrollarán en el sprint. Nos darán la forma del producto y los objetivos al final del sprint.
El plan debe estar bien explicado para que todos sean capaces de comprenderlo en los daily scrums.
El dueño del backlog del sprint no **es ** el product owner, sino el equipo. Es el equipo de desarrollo el que acepta si se pueden agregar o no nuevas historias de usuarios. Incluso se pueden eliminar de la lista historias de usuarios que no sean prioritarias. Si hay un elemento innecesario en el sprint, se puede sacar de la lista de pendientes.
¿Cómo se decide si algo es prioritario?
Depende de los siguientes factores:

• Valor para el cliente
• Urgencia
• Riesgo (que tanto se pueden atrasar otras historias)
• Oportunidad: cuantas historias más voy a poder hacer o cuantos productos más puedo agilizar.
• Esfuerzo: tiempo del sprint, cuantas personas trabajaran en él.

Comparto mis apuntes

• El backlog sprint es un subconjunto de la lista de producto (product backlog) y contiene todos los elementos que serán desarrollados durante el sprint
• La lista de pendientes del sprint debe de ser un plan muy bien detallado como para que todo el equipo sea capaz de comprenderlo en los daily standup
• Solo el equipo de desarrollo puede aceptar que se agreguen elementos al backlog sprint
• Si un elemento se vuelve inncesario, se puede sacar de la lista de pendientes, no tiene caso en trabajar en cosas que no se van a usar
• Normalmente no se incluyen historias empezado el sprint, pero en la práctica se agregan estas historias, asi que como product owner, se debe de platicar con el equipo de desarrollo antes de incluir

Definiendo prioridades

• Valor para el cliente: Se tiene que definir que actividades generan más valor para el propósito del cliente
• Urgencia: Hay que trabajar en los módulos que tengan una fecha límite, por ejemplo la actualización de las políticas de usuario
• Riesgo / oportunidad: Que impacto me puede generar el no hacer una historia de usuario o la oportunidad que me genera el hacer una historia, con cuáles más voy a poder continuar
• Esfuerzo: Que tanto esfuerzo le va a llevar al equipo, completar esas historias de usuario, medio sprint, todo el sprint, que tantos programadores van a tener que trabajar en esto

Prioridades del sprint backlog

El sprint backlog es un subconjunto de las historias de usuario contenidas en el product backlog, incluyendo sólo las que se desarrollarán durante el sprint. Las historias seleccionadas determinarán los objetivos y el incremento obtenido al finalizar el sprint.

Para definir la prioridad de una historia de usuario, se deben tener en cuenta los siguientes aspectos:

1. Valor para el cliente: Las historias que aporten más valor al cliente (por ejemplo permitiéndole realizar tareas de la operación diaria) son más prioritarias que las que no lo hacen.

2. Urgencia: Cuando la historia tiene una fecha límite para ser entregada o puesta en producción se deberá priorizar de acuerdo al tiempo hasta esa fecha.

3. Riesgo/Oportunidad: Se habla de riesgo u oportunidad cuando la historia afecta negativa o positivamente a otras. Se puede decidir priorizar tareas que en caso de no completarse retrasen la implementación de otras (riesgo), o cuya implementación pueda ser reutilizada en otras historias (oportunidad), incluso de otros proyectos (por ejemplo, login).

4. Esfuerzo: Cuánto esfuerzo (cantidad de horas/días de trabajo o integrantes del equipo) requerirá completar la historia.

Cuando el sprint está en curso, el encargado del sprint backlog pasa a ser el equipo de desarrollo, y solo este puede aceptar o rechazar que se agreguen historias. Lo ideal es que no se incluyan nuevas historias al backlog del sprint en curso, pero está contemplado que en casos de urgencia exista una negociación para redefinir prioridades y quitar alguna de las que todavía no se han trabajado.

También puede darse el caso contrario, donde se quite del sprint backlog una historia que por alguna razón dejó de ser prioritaria o necesaria, de esta forma se evita trabajar en cosas innecesarias.

Así pues, una buena manera de distinguirlas podría ser en base a los tipos de trabajo que implican. Es decir, las historias de usuario contienen varios tipos de trabajo (por ejemplo, programación, pruebas, diseño de la base de datos, diseño de interfaz de usuario, análisis, etc.) mientras que las tareas se limitan a un solo tipo de trabajo.

https://proagilist.es/blog/agilidad-y-gestion-agil/agile-scrum/conoces-la-diferencia-historias-usuario-tareas/#:~:text=Las historias de usuarios forman,parte del Backlog de sprint.

¿Por donde comenzar a trabajar nuestro proyecto?
El backlog del sprint es la lista de pendientes del Sprint.

• Un subconjunto de la lista de producto.
• Contiene todos los elementos que serán desarrollados durante el sprint.

• De estos elementos dependerá el incremento a desarrollar y los objetivos del sprint

Stories -> To do -> In progress -> Testing -> Done.

• Trello o Jira.

Lista de pendientes:

• Debe tener un plan lo suficientemente detallado para que todo el equipo sea capaz de comprenderlo en los daily Scrum.
• Solo el equipo es dueño del Backlog del sprint, a difencia del Backlog del producto, donde el dueño es el PO.
• Si un elementose vuelve innecesario a mitad de un sprint se puede sacar de la lista de pendientes.

¿Cómo se Definen las prioridades?

1. Valir para el cliente
2. Urgencia: estar disponible para X fecha.
3. Riesgo/oportinudad: “Si no hago esta historia de usuario, que tanto me puedo atrazar con respecto a las historias de usuarios que vienen más adelante? ¿Qué impacto me puede generar no hacer esta historia?” o “Si hago esto en cuantas otras historias voy a poder usarlas”
4. Esfuerzo: ¿Qué tanto esfuerzo le va a tomar al equipo completar esta historia? todo el sprint? un día del sprint? 2 días? va a tomar el esfuerzo de 3 programadores? de 1? de 5?

¿Por dónde comenzar? Prioridades y backlog del sprint

El backlog del sprint es un subconjunto de la lista de producto y contiene todos los elementos que serán desarrollados durante el Sprint. De estos elementos dependerá el incremento a desarrollar y los objetivos del sprint.

El proceso de desarrollo de un sprint se puede entender como:

🗒️ Stories

Este sistema se puede manejar en físico como en una pizarra pero también en digital en herramientas como Trello.

Solo el equipo de desarrollo puede aceptar que se agreguen elementos al Sprint Backlog. Si un elemento se vuelve innecesario a mitad de un sprint se puede sacar de la lista de pendientes.

¿Cómo se definen las prioridades?

1️⃣ Valor para el cliente

2️⃣ Urgencia

3️⃣ Riesgo / Oportunidad

4️⃣ Esfuerzo

Backlog de Sprint : * Elementos de las lista del producto que van a ser trabajados durante el sprint actual. * Incrementa valor al desarrollo o producto.
Ej: STORIES --> TO DO --> IN PROGRESS --> TESTING --> DONE
Lista de pendientes del Sprint
Plan detallado para que todo el equipo sea capaz de comprenderlo en los daily meetings.
El equipo se convierte en el nuevo dueño de la Lista de Pendientes del Sprint, el cual puede decidir si aceptan, agregan mas elementos o sacan elementos si fuera necesario. consenso.
Definiendo Prioridades
Valor para el cliente
Urgencia
Riesgo / Oportunidad
Esfuerzo

El dueño del Baclong Sprint es el equipo de desarrollo.
Si un elemento se vuelve innecesario a mitad de un sprint se puede sacar de la lista de pendientes.
Definir prioridades:

• Valor para el cliente
• Urgencia
• Riesgo / Oportunidad
• Esfuerzo

¿POR DONDE COMENZAR? PRIORIDADES Y BACKLOG DEL SPRINT

Lista de Pendientes del Sprint

Es un subconjunto de la Lista de Producto y contiene todos los elementos que serán desarrollados durante el sprint

De estos elementos dependertá el incremento a desarrollar y los objetivos del Sprint

Este plan debe tener detalle suficiente
como para que todo el equipo sea capaz
de comprenderlo en los daily stand-ups
(Scrum diario)

Solo el equipo de desarrollo puede
aceptar que se agreguen elementos al
Sprint Backlog.
Si un elemento se vuelve innecesario a
mitad de un sprint se puede sacar de la
lista de pendientes.

Definiendo prioridades

Prioridad - Valor para el cliente

Prioridad - Valor para el cliente / urgencia

Prioridad - Valor para el cliente / urgencia/Riesgo, Oportunidad

Prioridad - Valor para el cliente / urgencia/Riesgo, Oportunidad/ Esfuerzo

• El Sprint Backlog, es el subconjunto de los elementos del Product Backlog, que se ejecutaran durante el sprint.
• Etapas de desarrollo de Sprint Backlog, puede ser La lista de las historias, las historias que empezaremos a realizar, las que están en progreso, las que están para revisión o pruebas y las completadas.
• El sprint Backlog debe tener un plan suficientemente detallado, para que todo el equipo pueda comprenderlo.
• El equipo de desarrollo es el dueño del sprint Backlog y decide si aceptar o no nuevas historias, a mitad del sprint. asimismo también puede eliminar historias irrelevantes.
• Para definir las prioridades, se debe basar en el valor para el cliente, en la urgencia, en el riesgo u oportunidad, y el esfuerzo para completar la historia.

¿Quién define el contenido del backlog del sprint?

• Produc Owner y el equipo de desarrollo.

El equipo de desarrollo, entonces, también cumple una función de juez y su decisión de añadir o remover debe ser transparente

Este sería un ejemplo del sprint

Definimos el Backlog del Sprint: 🚀

++Backlog del Sprint:
++

• Es un subconjunto de elementos de la lista de producto que se van a trabajar.
• Son las historias de usuario que se van a trabajar en el Sprint en particular.
• Estás historias de usuario nos van a dar los objetivos que queremos cumplir al final de sprint.

Lista de pendientes del Sprint: 😇

• Debe tener un plan lo suficientemente detallado para que todos lo puedan entender durante el daily stand-up.
• El dueño del Backlog del Sprint ya no es el Product Owner o Manager, sino el equipo de desarrollo por lo que son los únicos que pueden aceptar que se agreguen más elementos al Sprint.
• Normalmente es necesario agregar nuevas historias al sprint después que ya ha comenzado. Aquí nos sentamos con el equipo desarrollo y definimos que historias de usuario que están dentro del Sprint podemos sacar para priorizar la nueva historia que queremos agregar.
• Si nos damos cuenta que una historia no es relevante, la podemos eliminar del Sprint. Ya no son necesarios algunas funcionalidades y si debemos sacarlo, lo hacemos.

Definición de prioridades: 💚

• Valor para el cliente: Funcionalidad de impacto para el usuario.
• Urgencia: Urgencia del desarrollo de la funcionalidad.
• Riesgo: Sino desarrollo está historia de usuario que tanto me puedo atrasar con las historias de usuario que vienen más adelante (impacto que puede generar no realizar esta historia).
• Oportunidad: Si hago está historia cuántas historias más voy a poder hacer o en cuántos productos voy a poder utilizar la misma lógica de esta historia.
• Esfuerzo: Estimamos el esfuerzo del equipo para poder completar la historia.

Pregunta de examen:
¿Quién define el contenido del backlog del sprint?

Sprint Backlog; Es representado en un Scrumboard o tablero de tareas, el cual proporciona una constante representación visual del estado de las historias de usuario en el backlog.
En el Sprint Backlog también se incluye cualquier riesgo asociado a las varias tareas. Cualquier actividad de mitigación de riesgos para atender los riesgos identificados también se incluirían como tareas en el Sprint Backlog.
Una vez que el Equipo Scrum finaliza y se compromete al Sprint Backlog no se deben agregar nuevas historias de usuario; sin embargo, las tareas que pudieron haberse pasado por alto o ignoradas de las historias de usuario comprometidas pudieran ser agregadas. Si durante un sprint surgen nuevos requerimientos, estos serán agregados al Backlog Priorizado del Producto e incluidos en un futuro sprint.

Se pueden quitar historias de usuario a la mitad del sprint? … puede ser por bloqueantes o errores en el calculo de la capacidad del equipo en el planning?

La lista de objetivos a completar en la iteración (Product Backlog Items) se puede gestionar mediante un tablón de tareas (Scrum Taskboard). Al lado de cada objetivo se ponen las tareas necesarias para completarlo, en forma de post-its, y se van moviendo hacia la derecha para cambiarlas de estado (pendientes de iniciar, en progreso, hechas). Para cada miembro del equipo se puede utilizar adhesivos de colores más pequeños sobre cada tarea, de manera que se pueda ver en qué tareas está trabajando cada cual.

Si tu equipo o empresa manejan GitLab como servicio de control de versiones hay una board muy similar a trello y es muy practico porque ahí también pueden estar las historiad de usuario

¿Por dónde empezar?

Pendientes del Sprint

• Claro y detallado.
• El dueño es el equipo de desarrollo.

Prioridades

1. Valor para el cliente.
2. La urgencia.
3. El riesgo / Oportunidad.
4. El esfuerzo del equipo por completar la historia.

Como recordar:

Definir prioridades:

Valor del cliente
Urgencia
Riesgo
Esfuerzo

VURE
Idea: Vudú y Religión (porque inician con Vu y Re)

Un hombre quería vengarse de su jefe y fue a una tienda de magia negra. Allí le ofrecieron un muñeco vudú que podía controlar los movimientos y las emociones de su víctima. El hombre estaba muy interesado en sacarle valor a su dinero y le preguntó a la bruja cuánto costaba el muñeco. La bruja le dijo que era muy caro y que tenía que hacer el pedido con mucha urgencia, porque había poca disponibilidad y mucha demanda. El hombre aceptó y le dio sus datos personales y los de su jefe. La bruja le advirtió que había un riesgo muy grande de que la religión se enterara de su plan y lo persiguiera por practicar el vudú. Le dijo que tendría que esforzarse mucho para ocultar el muñeco y evitar que lo descubrieran. El hombre no le hizo caso y se llevó el muñeco a su casa. Al día siguiente, intentó usarlo para hacerle daño a su jefe, pero se dio cuenta de que el muñeco no funcionaba. Entonces llamó a la bruja para reclamarle, pero nadie contestó el teléfono. De repente, escuchó un golpe en la puerta y vio a unos hombres vestidos de negro que venían a arrestarlo por herejía.

Backlog del Sprint

Estimación de HU:

• Complejidad
• Cantidad de trabajo
• Conocimientos necesarios
• Incertidumbre

Los puntos a asignar son un empírico de trabajo.
Poker planning: Asignación por persona de un #.

Se puede trabajar a través de escalas:
Escala de Fibonacci (1, 2, 3, infinito o ¿)
Escala potencial de 2: 2, 4, 6, 8…

Velocidad: puntos que el equipo puede completar durante el sprint
Capacidad: puntos que en teoría puede cubrir el equipo.

Etapas proceso de desarrollo (5):
Total, por hacer, en curso, en prueba y finalizadas
En pizarra o Jira/ Trelho

Organización:
Todo el equipo debe conocer el backlog
Desarrollo decide sobre la admin del backlog, si empezó el sprint hay que contemplar
Pueden cambiar o eliminar HU de acuerdo a prioridades y necesidades
Definir prioridades:

• Valor para el cliente
• Urgencia
• Riesgo (que pasa con el sprint si lo hago) u oportunidad (Si hago esta HO que beneficio tiene para el plan general)
• Esfuerzo: tiempo y programadores

Backlog del Sprint es un subconjunto de la lista del producto y contiene todos los elementos que serán desarrollados durante el Sprint.

Definiciòn de prioridades:

• Valor para el cliente
• Urgencia
• Riesgo u Oportunidad
• Esfuerzo

Hola chicos hay una app de Scrum en la playstore
Video de presentación de la app de Scrum

En 2022 me gustaría recomendar ClickUp https://clickup.com/teams/agile

Casualmente cuando comence a estudiar Scrum (antes de llegar a Platzi), una de las principales herramientas que se comentaban era Trello. Y es una herramienta que me ha ayudado mucho en mi día a día en mi trabajo.

backlog list = lista de trabajos pendientes

Explicación más que clara por el profesor

quien es el dueño de backlog del spring

Etapas:
Stories->To do -> In progress - Testing -> Done
El equipo de desarrollo es dueño del sprint baklog
Definiendo prioridades:
-Valor para el cliente
-Urgencia
-Riesgo / Oportunidad
-Esfuerzo

Buen curso

Si ya sabemos que algo perdió valor lo podemos retirar del sprint (y)

a que bueno entender muy bien el backlog del sprint. ahora si entiendo muchas cosas

En el Backlog se pueden incluir entradas para explorar necesidades del cliente, analizar opciones técnicas, describir requisitos funcionales y no funcionales, el trabajo necesario para lanzar el producto y otros ítems de trabajo tales como la corrección de errores (bugs) o la configuración del entorno.

Azure Devops, Excellent

Gracias

Prioridades

Definiendo prioridades

buen aporte

Trello es una herramienta muy buena!, lo utilizo para programar mi día. =D

Entonces no solo el product owner es el encargado de esa responsabilidad?

Es un subconjunto de la lista del producto y contiene todos los elementos que serán desarrollados durante del sprint
De estos elementos dependerá el incremento a desarrollar y los objetivos del sprint.
Este plan debe tener detalle suficiente como para que todo el equipo sea capaz de comprenderlo en los daily stand-up (scrum diario)
Solo el equipo de desarrollo puede aceptar que se agreguen elementos al sprint backlog
Si un elemento se vuelve innecesario a mitad de un sprint se puede sacar de la lista.

Lo que dice Gerardo en cuanto a que un cliente me pida una urgencia y me dañe el sprint es normal, pero me parece muy bueno que SCRUM plantee que se negocie con el DEV TEAM las historias que se puedan sacar para darle espacio a esas urgencias.

lamentablemente muchos equipos les toca aceptar trabajos adicionales cuando ya se ha iniciado el proceso. Al final los equipos terminan molestos por esta situación.

PRIORIDADES Y BACKLOG DEL SPRINT
Subconjunto de la lista de producto (product backlog) - historias de usuario que trabajaremos en el sprint en particular

Historias - To do - In Progress - Testing - Done
Jira
Trello

Lista de pendientes del sprint - Sprint Backlog
Un plan detallado para que todos lo puedan entender en el daily scrum, tener claro el backlog del sprint
El dueño del backlog del sprint es el equipo de desarrollo, ellos decidieron no aceptar historias a mitad del sprint. Solo se pueden incluir historias al inicio del sprint
Solo el equipo de desarrollo puede aceptar que se agreguen elementos al Sprint Backlog

Definiendo prioridades
Valor para el cliente - Que historia es más importante
Urgencia -
Riesgo o Oportunidad - Si no hago la historia de usuario que tanto me puedo atrasar
Esfuerzo - Que tanto esfuerzo le va a tomar al equipo realizar la historia, si va a tomar todo un sprint o un día del sprint

PRIORIDADES Y BACKLOG DEL SPRINT.
Lista de pendientes del sprint: es un subconjunto de la lista del producto, contiene los elementos a desarrollar en el sprint.
La lista de pendientes debe tener detalle suficiente para que todo el equipo sea capaz de comprender en el daily, scrum diario. Solo el equipo de desarrollo puede aceptar que se agreguen elementos al Sprint backlog. Si la prioridad cambia se pueden modificar características, aunque sea a mitad de sprint.
Prioridades:

• Valor para el cliente.
• Urgencia
• Riesgo / Oportunidad.
• Esfuerzo.
  Software de apoyo: https://trello.com/ y https://www.atlassian.com/es/software/jira

Etapas

1. Historias que son parte del Backlog
2. Historias que hemos decido comenzar a trabajar
3. Historias que estamos trabajando en el instante
4. Historias que vamos a comenzar a probar o están lista para que se empiecen a probar
5. Historias que están completas

Definiendo prioridades

• Valor
• Urgencia
• Riesgo/Oportunidad
• Esfuerzo

Yo uso jira y lo amo!

El aporte del equipo SCRUM es muy importante en la planeación y toma de decisiones.

En la review de Sprint es donde se generan los cambios en la historias del usuario, porque es donde el usuario valida si la HU quedo bien definida… se genera el control de cambio y debe quedar incluido en el sprint.

Mi pregunta es quien y en que momento se define la prioridad de las historias. Es el PO cuando arma el proximo sprint? Es el equipo cuando las estima?

Aprendiendo cada día mas. Gracias!!

El backlog del sprint es un subconjunto de esa lista de elementos, son las historias de usuario que se trabajarán en ese sprint en particular. estas historias nos darán al final el objetivo que se quiere cumplir.

Orden de trabajo en el sprint backlog

User Stories

• To Do
• Work in Progress
• QA
• Completed

¿Cómo medir la prioridad de cada user story? Para, por ejemplo, trabajarlas primero.

• Urgencia
• Valor para el cliente
• Esfuerzo
• Riesgo / Oportunidad.

Riesgo: ¿Cuánto me atraso si no trabajo en esta US?
Oportunidad: ¿En cuántos features podré reutilizar la lógica de esta US?

Prioridad se define por :
-Valor para el cliente
-Urgencia
-Riesgo/oportunidad
-Esfuerzo

Lista de Pendientes del Sprint

• Subconjunto de la Lista de Producto
• Los elementos a desarrollarse en el sprint
• De ellos depende el incremento a desarrollar y el objetivo del Sprint
• Detallados
• El equipo de desarrollo es dueño del Sprint Backlog
• El PO es dueño de la Lista de Producto

Etapas:
User Stories Todo In Progress Testing Done

Definiendo Prioridades
Elementos:

• Valor para el cliente
• Urgencia del cliente
• Riesgo / Oportunidad
• Esfuerzo del equipo

Lista de pendientes del Sprint. Es un subconjunto de la lista de producto y contiene todos los elementos que serán desarrollados durante el Sprint. De estos elementos dependerá el incremento a desarrollar y los objetivos del Sprint.

Solo el DevTEam puede aceptar que se agreguen elementos al Sprint del backlog. También se pueden sacar elementos si se vuelven innecesarios.

Sprint Backlog
Una pequeña lista del Product Backlog
Que se va a trabajar en un Sprint determinado
Subconjunto de la Product Backlog
Son las historias de usuario en el Sprint en particular
Lista de pendientes del Sprint:
Stories (historias)
To do (Por comenzar)
In progress (Trabajando en ese momento)
Testing (Historia Lista para probar)
Done (Historias completas)
Este plan debe tener suficiente detalle para que todos puedan comprenderlo en los Daily stand
El dueño del Sprint Backlog es el Dev Team, solo ellos pueden agregar elementos

Definición del backlog del sprint

Entendi perfectamente los 3 primeros pero el de esfuerzo no comprendería porque se toma en cuenta si eso sería mas de cara al equipo, y la verdad al cliente eso poco le importa.

Buen aporte sobre el uso de herramientas como Trello o Jira para tener la Lista de Pendientes del Sprint según su estado. Acabo de crear una cuenta en Trello.

Notion rules 🤘

Lista de pendientes de Sprint

• Stories
• Por hacer
• Haciendo
• Por testear
• Finalizado
  Todas las personas deben tener conocimiento del backlog del sprint y luego ya no es dueño el producto owner si no el equipo de desarrollo.
  Aspectos para definir prioridades
• Valor para el cliente
• Urgencia
• Riesgo – oportunidad
• Esfuerzo

Asana tiene una muy buena versión gratuita.

Una pregunta, ¿esos criterios de priorización están listados por jerarquía?
¿O son criterios que vamos a ir evaluando dependiendo de nuestro Cliente?