Aún no tienes acceso a esta clase

Crea una cuenta y continúa viendo este curso

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

13/21
Recursos

Aportes 67

Preguntas 11

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad? Crea una cuenta o inicia sesión.

El backlog del sprint va a ser un subconjunto de elementos de la lista del producto y estas historias de usuario son las que vamos a trabajar y los objetivos que queremos cumplir.

*Etapas intermedias:

  • Historias de usuario
  • Historias que hemos decidido trabajar
  • Historias que están en progreso
  • Historias que se van a empezar a probar
  • Historias terminadas

Trello es una buena herramienta para darle seguimiento a las actividades. Aqui les dejo un link del tablero que yo uso https://trello.com/b/2SFC7g8G/scrum-ejemplo

Lista de pendientes del sprint debe estar lo suficientemente detallado para que el equipo sea capaz de comprenderlo en los daily stand-ups

El dueño del backlog del sprint es el equipo de desarrollo, y ellos tienen control sobre esta lista y están en su derecho de rechazar otras historias. Sin embargo el Product owner podrá dialogar con el equipo para bajar la prioridad o eliminar historias de usuarios

Como se define las prioridades:

  • Valor para el cliente, que historias generan más valor al producto
  • Urgencia, cuando algo tiene una fecha limite
  • Riesgo / Oportunidad, definir el impacto que una historia puede tener sobre otras
  • Esfuerzo que tanto trabajo le va a tomar al equipo desarrollar la historia

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.

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

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

¿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.

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.

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.

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 (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.

Sprint Backlog

¿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.

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

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.

Buen curso

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

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.

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.

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

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:

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.

sigo con la duda, el backlog sprint debe ser definido por el scrum master y el equipo? o tambien debe intervenir el product owner?

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.

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

  • Produc Owner y el equipo de desarrollo.

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.

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.

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?