Glosario
Guía SBOK – Términos y Conceptos Importantes®
| Letra chica | Definición |
|---|---|
| Método de 100 puntos | El método de los 100 puntos fue desarrollado por Dean Leffingwell y Don Widrig (2003). Consiste en dar al cliente 100 puntos que puede utilizar para votar por las características que considere más importantes. |
| Entregables aceptados | Los entregables que cumplen con los criterios de aceptación de la historia de usuario son aceptados por el propietario del producto. Estos se consideran Entregables Aceptados que pueden ser liberados al cliente si así lo desea. |
| Escalamientos accionables | El Cuerpo de Guía de Scrum puede determinar que algunas políticas de la empresa no permiten que los equipos obtengan el máximo se beneficia de la aplicación de Scrum. En tal caso, es necesario desencadenar una escalada para obtener aprobación de un cambio de política. |
| Adaptación | La adaptación ocurre a medida que el equipo central de Scrum y las partes interesadas aprenden a través de la transparencia y la inspección y luego se adaptan realizando mejoras en el trabajo que realizan. |
| Estimación de afinidad | La estimación de afinidad es una técnica utilizada para estimar rápidamente un gran número de historias de usuario mediante categorías. Las categorías pueden ser pequeñas, medianas o grandes, o pueden numerarse utilizando valores de puntos de historia para indicar el tamaño relativo. Algunos beneficios clave de este enfoque son que el proceso es muy transparente, visible para todos y es fácil de realizar. |
| Mejoras accionables acordadas | Las mejoras accionables acordadas son el resultado principal del proceso de Retrospect Sprint. Son la lista de elementos accionables que el equipo ha elaborado para abordar problemas y mejorar los procesos con el fin de mejorar su rendimiento en futuros Sprints. |
| Solicitudes de cambio aprobadas | Las solicitudes de cambio aprobadas son cambios que se han aprobado para incluirse en el trabajo pendiente de productos priorizados. A veces, las Solicitudes de Cambio Aprobadas pueden originarse en los gerentes del programa o del portafolio y serían entradas que se agregarán a la lista de cambios aprobados en el proyecto para su implementación en futuros Sprints. |
| Líder asertivo | Los líderes asertivos enfrentan los problemas y muestran confianza para establecer autoridad con respeto. |
| Resultados de Evaluaciones/Benchmarking | La evaluación/evaluación comparativa ayuda a establecer un estándar mínimo al crear un producto o servicio y conduce a cambios en los criterios de finalización. A veces, también pueden proporcionar un impulso para que un propietario de producto de programa o cartera desarrolle nuevas historias de usuario para implementar las mejores prácticas. |
| Elementos de acción asignados y fechas de vencimiento | Una vez que se han elaborado y refinado las Mejoras Accionables Acordadas, el Equipo Scrum puede considerar los elementos de acción para implementar las mejoras. Cada elemento de acción tendrá una fecha de vencimiento definida para su finalización. |
| Líder autocrático | Los líderes autocráticos toman decisiones por su cuenta, permitiendo a los miembros del equipo poca o ninguna participación o discusión antes de tomar una decisión. Este estilo de liderazgo solo debe usarse en raras ocasiones. |
| Herramientas de software automatizadas | Las herramientas de software automatizadas son herramientas de software utilizadas para la programación, recopilación y distribución de información. |
| Mejor coordinación del equipo | La reunión de Scrum de Scrums facilita la coordinación del trabajo entre varios equipos de Scrum. Esto es especialmente importante cuando hay tareas que implican dependencias entre equipos. Las incompatibilidades y discrepancias entre el trabajo y los entregables de los diferentes equipos se exponen rápidamente. Este foro también brinda a los equipos la oportunidad de mostrar sus logros y dar su opinión a otros equipos. |
| Evaluación comparativa | Una empresa debe comparar sus propias prácticas con las de otras empresas con regularidad para mantenerse al día con la competencia. El benchmarking es el proceso de comparar los procesos de negocio y las métricas de rendimiento de una organización con los de las empresas líderes en la misma u otras industrias. |
| Lluvia de ideas | Sesiones en las que las partes interesadas relevantes y los miembros del equipo central de Scrum comparten ideas abiertamente a través de debates y sesiones de intercambio de conocimientos, que normalmente son dirigidas por un facilitador. |
| Justificación del negocio | La justificación empresarial demuestra las razones para emprender un proyecto. Responde a la pregunta “¿Por qué es necesario este proyecto?” La justificación empresarial impulsa toda la toma de decisiones relacionadas con un proyecto. |
| Necesidades del negocio | Las necesidades de negocio son aquellos resultados de negocio que se espera que el proyecto cumpla, como se documenta en la Declaración de Visión del Proyecto. |
| Requisitos del negocio | Los requisitos empresariales definen lo que se debe entregar para satisfacer las necesidades empresariales y proporcionar valor a las partes interesadas. La suma de todos los conocimientos obtenidos a través de diversas herramientas, como entrevistas a usuarios o clientes, cuestionarios, sesiones de JAD, análisis de brechas, análisis FODA y otras reuniones, ayuda a obtener una mejor perspectiva sobre los requisitos comerciales y ayuda a crear el backlog de productos priorizados. |
| Grupos de interés del negocio | Las partes interesadas del negocio se consideran roles no esenciales en un proyecto Scrum. Las partes interesadas del negocio incluyen patrocinadores, usuarios y clientes. |
| Solicitud(es) de cambio | Las solicitudes de cambios generalmente se presentan como solicitudes de cambio. Las solicitudes de cambio permanecen en un estado no aprobado hasta que se aprueban formalmente. |
| Jefe de Producto | En el caso de proyectos grandes, el Propietario Principal del Producto prepara y mantiene el Backlog general de Productos Priorizados para el proyecto. Coordina el trabajo entre los Product Owners de los Equipos Scrum. Los propietarios del producto, a su vez, gestionan sus respectivas partes del backlog de productos priorizados. |
| Jefe de Scrum Master | En el caso de proyectos de gran envergadura, el Chief Scrum Master es responsable de moderar la reunión de Scrum of Scrums (SoS) y eliminar los impedimentos que afecten a varios equipos. |
| Coaching/Líder de Apoyo | Los líderes de coaching y apoyo dan instrucciones y luego apoyan y monitorean a los miembros del equipo escuchando, asistiendo, alentando y presentando una perspectiva positiva en tiempos de incertidumbre. |
| Colaboración | La colaboración en Scrum se refiere a que el equipo central de Scrum trabaje en conjunto e interactúe con las partes interesadas para crear y validar los entregables del proyecto para cumplir con los objetivos descritos en la Visión del Proyecto. La colaboración ocurre cuando un equipo trabaja en conjunto para aprovechar las contribuciones de los demás para producir algo más grande. |
| Plan de colaboración | La colaboración es un elemento extremadamente importante en Scrum y el Plan de Colaboración describe cómo los diversos tomadores de decisiones, las partes interesadas del negocio y los miembros del equipo se involucran y colaboran entre sí. |
| Colocación | La colocación consiste en que todos los miembros del equipo central de Scrum estén ubicados en el mismo lugar de trabajo, aprovechando las ventajas de una mejor coordinación, resolución de problemas, intercambio de conocimientos y aprendizaje. |
| Confirmar historias de usuario | En este proceso, el Equipo Scrum se compromete a entregar Historias de Usuario aprobadas por el Product Owner para un Sprint. El resultado de este proceso serían las Historias de Usuario Comprometido. |
| Plan de Comunicación | Este plan especifica los registros que se deben crear y mantener a lo largo del proyecto. Se utilizan una variedad de métodos para transmitir información importante del proyecto a las partes interesadas. El Plan de Comunicación define estos métodos, así como quién es responsable de las diversas actividades de comunicación. |
| Plan de Recursos Humanos de la Empresa | El Plan de Recursos Humanos de la empresa proporciona información general sobre cuándo estará disponible un personal determinado para diversos proyectos, programas y carteras. El plan también proporciona información sobre las habilidades y capacidades disponibles dentro de la empresa y sobre los planes para contratar al personal necesario para los esfuerzos futuros. |
| Misión de la empresa | La misión de la empresa proporciona un marco para formular las estrategias de una empresa u organización que guía su toma de decisiones general. |
| Políticas de la empresa | Las políticas de la empresa son un conjunto de principios, reglas y directrices formuladas o adoptadas por una organización. Cambiar las políticas de la empresa afectaría a las historias de usuario creadas, ya que se han creado siguiendo las políticas existentes. |
| Visión de la empresa | Comprender la visión de la empresa ayuda al proyecto a mantener su enfoque en los objetivos de la organización y el potencial futuro de la empresa. El propietario del producto puede tomar la orientación y la dirección de la visión de la empresa para crear la declaración de visión del proyecto. |
| Realizar una reunión diaria | Llevar a cabo una reunión diaria es un proceso en el que se lleva a cabo una reunión muy centrada y con un límite de tiempo todos los días. Esta reunión se conoce como Daily Standup Meeting, que es un foro para que el equipo de Scrum se actualice mutuamente sobre su progreso y cualquier impedimento que puedan enfrentar. |
| Llevar a cabo la planificación de lanzamientos | En este proceso, el equipo central de Scrum revisa las historias de usuario de alto nivel en el backlog de productos priorizados para desarrollar un cronograma de planificación de lanzamientos, que es esencialmente un cronograma de implementación por fases que se puede compartir con las partes interesadas. La longitud de los sprints también se determina en este proceso. |
| Gestión de conflictos | Las técnicas de gestión de conflictos son utilizadas por los miembros del equipo para gestionar cualquier conflicto que surja durante un proyecto Scrum. Las fuentes de conflicto a menudo incluyen cronogramas, prioridades, recursos, jerarquía de informes, problemas técnicos, procedimientos, personalidad y costos. |
| Mejora Continua | La mejora continua es un enfoque de Scrum en el que el equipo aprende de la experiencia y el compromiso de las partes interesadas para mantener constantemente actualizado el backlog de productos priorizados con cualquier cambio en los requisitos. |
| Justificación continua del valor | La Justificación Continua del Valor se refiere a la evaluación del valor del negocio con regularidad para determinar si la justificación o la viabilidad de la ejecución del proyecto sigue existiendo. |
| Rol(es) principal(es) | Los roles principales son aquellos roles que se requieren obligatoriamente para producir el producto del proyecto, están comprometidos con el proyecto y, en última instancia, son responsables del éxito de cada Sprint dentro del proyecto y del proyecto en su conjunto. |
| Crear entregables | Crear Entregables es el proceso en el que el Equipo Scrum trabaja en las tareas del Backlog del Sprint para crear Entregables del Sprint. |
| Crear un backlog de productos priorizado | En este proceso, las epopeyas se refinan y elaboran, y luego se priorizan para crear un backlog de producto priorizado para el proyecto. En este punto también se establecen los Criterios de Finalización. |
| Crear la visión del proyecto | En este proceso, se revisa el Caso de Negocio del Proyecto para crear una Declaración de Visión del Proyecto que servirá de inspiración y proporcionará enfoque para todo el proyecto. En este proceso se identifica el Product Owner. |
| Crear historias de usuario | En este proceso, se crean las historias de usuario y sus criterios de aceptación de historias de usuario relacionados. Las historias de usuario suelen ser escritas por el propietario del producto y están diseñadas para garantizar que los requisitos del cliente se representen claramente y puedan ser comprendidos plenamente por todas las partes interesadas de la empresa. |
| Diagrama de flujo acumulativo (CFD) | Un diagrama de flujo acumulativo (CFD) es una herramienta útil para informar y realizar un seguimiento del rendimiento del proyecto. Proporciona una representación visual simple del progreso del proyecto en un momento determinado. Por lo general, se usa para proporcionar un estado de nivel superior del proyecto general y no actualizaciones diarias para Sprints individuales. |
| Cliente | El Cliente es un individuo o la organización que adquiere el producto, servicio u otro resultado del proyecto. Para cualquier organización, dependiendo del proyecto, puede haber clientes internos (es decir, dentro de la misma organización) o clientes externos (es decir, fuera de la organización). |
| Priorización basada en el valor del cliente | La priorización basada en el valor del cliente otorga una importancia primordial al cliente y se esfuerza por implementar primero las historias de usuario con el valor más alto. Estas historias de usuario de alto valor se identifican y se mueven a la parte superior del backlog de productos priorizados. |
| Reunión diaria de pie | La reunión diaria de pie es una reunión diaria corta, con un límite de tiempo de 15 minutos. Los miembros del equipo se reúnen para informar sobre su progreso respondiendo a las tres preguntas siguientes:¿Qué he hecho desde la última reunión?¿Qué planeo hacer antes de la próxima reunión?¿A qué impedimentos u obstáculos (si los hay) me enfrento actualmente? |
| Descomposición | La descomposición es una herramienta mediante la cual las tareas de alto nivel se dividen en tareas de nivel inferior más detalladas. Las historias de usuario son descompuestas en tareas por los miembros del equipo Scrum. Las historias de usuario del backlog de productos priorizados deben descomponerse lo suficiente como para proporcionar al equipo de Scrum la información adecuada para crear entregables a partir de las tareas mencionadas en la lista de tareas. |
| Líder Delegado | Los líderes delegados están involucrados en la mayoría de la toma de decisiones; Sin embargo, delegan algunas responsabilidades de planificación y toma de decisiones a los miembros del equipo, especialmente si son competentes para manejar tareas. Este estilo de liderazgo es apropiado en situaciones en las que el líder está en sintonía con los detalles específicos del proyecto y cuando el tiempo es limitado. |
| Demostración y validación de Sprint | En este proceso, el Equipo Scrum demuestra los Entregables del Sprint al Propietario del Producto y a las partes interesadas relevantes en una Reunión de Revisión del Sprint. |
| Determinación de dependencias | Una vez que el equipo de Scrum ha seleccionado las historias de usuario para un Sprint determinado, debe considerar las dependencias, incluidas las relacionadas con la disponibilidad de las personas, así como las dependencias técnicas. Documentar correctamente las dependencias ayuda a los equipos de Scrum a determinar el orden relativo en el que se deben ejecutar las tareas para crear los entregables del sprint. Las dependencias también destacan la relación e interacción entre las tareas, tanto dentro del Equipo Scrum que trabaja en un Sprint determinado como con otros Equipos Scrum en el proyecto. |
| Patrones de diseño | Los patrones de diseño proporcionan una forma formal de registrar una resolución a un problema de diseño en un campo específico de especialización. Estos patrones registran tanto el proceso utilizado como la resolución real, que luego se puede reutilizar para mejorar la toma de decisiones y la productividad. “En este proceso, la Declaración de la Visión del Proyecto sirve como base para el desarrollo de grandes proyectos de alto nivel. Historias denominadas Epopeyas. Se pueden llevar a cabo reuniones de grupos de usuarios para desarrollar epopeyas”. |
| Contrato de Desarrollo por Fases | Este contrato hace que los fondos estén disponibles cada mes o cada trimestre después de que un lanzamiento se complete con éxito. Proporciona un incentivo tanto al cliente como al proveedor y garantiza que el riesgo monetario del cliente se limite a ese período de tiempo en particular, ya que los lanzamientos fallidos no se financian. |
| Líder Directivo | Los líderes directivos instruyen a los miembros del equipo sobre qué tareas se requieren y cuándo y cómo deben realizarse. |
| Dependencias discrecionales | Las dependencias discrecionales son dependencias que se colocan en el flujo de trabajo por elección. Por lo general, las dependencias discrecionales son determinadas por el equipo de Scrum en función de experiencias pasadas o mejores prácticas en un campo o dominio en particular. |
| Done Criteria | Done Criteria are a set of rules that are applicable to all User Stories. A clear definition of Done is critical, because it removes ambiguity from requirements and helps the team adhere to mandatory quality norms. This clear definition is used to create the Done criteria that are an output of the Create Prioritized Product Backlog process. A User Story is considered done when it is demonstrated to and approved by the Product Owner who judges it on the basis of the Done Criteria and the User Story Acceptance Criteria. |
| Earned Value Analysis | Earned Value Analysis analyzes actual project performance against planned performance at a given point in time. It measures current variances in the project’s schedule and cost performance and forecasts the final cost based on the determined current performance. |
| Empirical Process Control | An Empirical Process Control model helps make decisions based on observation and experimentation rather than on detailed upfront planning. It relies on the three main ideas of transparency, inspection, and adaptation. |
| Epic(s) | Epic(s) are written in the initial stages of the project when most User Stories are high-level functionalities or product descriptions and requirements are broadly defined. They are large, unrefined User Stories in the Prioritized Product Backlog. |
| Estimate Range | Estimates for projects should be presented in ranges. Precise figures may give an impression of being highly accurate when in fact they may not be. In fact, estimates by definition are understood not to be precisely accurate. Estimate ranges should be based on the level of confidence the team has in each estimate. |
| Estimate Tasks process | In this process, the Scrum Core Team, in a Task Estimation Workshop, estimates the effort required to accomplish each task in the Task List. |
| Estimation Criteria | The primary objective of using Estimation Criteria is to maintain relative estimation sizes and minimize the need for re-estimation. Estimation Criteria can be expressed in numerous ways, with two common examples being story points and ideal time. |
| Expected Monetary Value | This is a risk assessment technique where the potential financial impact of a risk is determined based on its Expected Monetary Value (EMV). EMV is calculated by multiplying the monetary impact by the risk’s probability, as approximated by the customer. |
| Explorer-Shopper-Vacationer-Prisoner (ESVP) | This is an exercise that can be conducted at the start of the Retrospect Sprint Meeting to understand the mind-set of the participants and set the tone for the meeting. Attendees are asked to anonymously indicate which best represents their outlook in the meeting. |
| External dependencies | External dependencies are those related to tasks, activities, or products that are outside the scope of the work to be executed by the Scrum Team, but are needed to complete a project task or create a project deliverable. External dependencies are usually outside the Scrum Team’s control. |
| Focus Group Meetings | Focus groups assemble individuals in a guided session to provide their opinions, perceptions, or ratings of a product, service, or desired result. Focus group members have the freedom to ask questions to each other and to get clarifications on particular subjects or concepts. Through questioning, constructive criticism, and feedback, focus groups lead to a better quality product and thereby contribute to meeting the expectations of the users. |
| Formar un equipo Scrum | Los miembros del equipo Scrum se identifican durante este proceso. Normalmente, el Product Owner tiene la responsabilidad principal de seleccionar a los miembros del equipo, pero a menudo lo hace en colaboración con el Scrum Master. |
| Etapa de formación | La etapa de formación es la primera etapa de la formación del equipo, a menudo considerada una etapa divertida porque todo es nuevo y el equipo aún no ha encontrado ninguna dificultad con el proyecto. |
| Cuatro preguntas por equipo | Un conjunto de preguntas que se hacen en cada reunión de Scrum de Scrums (SoS). Cada representante del equipo Scrum proporcionará actualizaciones de su equipo, que generalmente se proporcionan en forma de respuestas a cuatro preguntas específicas.¿En qué ha estado trabajando mi equipo desde la última reunión?¿Qué hará mi equipo hasta la próxima reunión?¿Qué contaban otros equipos con nuestro equipo para terminar que aún no se ha hecho?¿Qué planea hacer nuestro equipo que pueda afectar a otros equipos? |
| Análisis de brechas | El análisis de brechas es una técnica utilizada para comparar el estado actual y real con algún estado deseado y determinar cómo cerrar la brecha entre ellos. |
| Identificar el entorno | Identificar el número y los tipos de entornos necesarios para numerosos equipos Scrum que comenzarán y finalizarán sus Sprints el mismo día. |
| Identificar el proceso del Scrum Master y de las partes interesadas | En este proceso, el Scrum Master y las partes interesadas se identifican utilizando criterios de selección específicos. |
| Identificar tareas | En este proceso, las historias de usuario comprometidas se dividen en tareas específicas y se compilan en una lista de tareas. Esto se hace como parte de la Reunión de Planificación del Sprint. |
| Estándares de la industria | Es necesario implementar nuevos estándares de la industria o cambios en los estándares existentes para mantener un producto o servicio viable. Por lo tanto, las historias de usuario relacionadas deben incluirse en el programa priorizado y/o en el backlog de la cartera y priorizarse en consecuencia. |
| Impedimento | Un impedimento es cualquier obstáculo u obstáculo que reduzca la productividad del Equipo Scrum. |
| Fase de implementación | La Fase de Implementación incluye procesos relacionados con la ejecución de las tareas y actividades para crear el producto de un proyecto. |
| Contrato de Incentivos y Penalizaciones | Este contrato se basa en el acuerdo de que el proveedor será recompensado con un incentivo financiero, si los productos del proyecto se entregan a tiempo, pero incurrirá en penalizaciones financieras, si la entrega se retrasa. |
| Contrato de Entrega Incremental | Este contrato incluye puntos de inspección a intervalos regulares. Ayuda al cliente u otras partes interesadas del negocio a tomar decisiones con respecto al desarrollo del producto periódicamente a lo largo del proyecto en cada punto de inspección. El cliente puede aceptar el desarrollo del producto, decidir detener el desarrollo del producto o solicitar modificaciones del producto. |
| Fichas | Las fichas, a menudo descritas como Story Cards, se utilizan para realizar un seguimiento de las historias de usuario a lo largo del proyecto. Esto aumenta la visibilidad y la transparencia y facilita el descubrimiento temprano de cualquier problema que pueda surgir. |
| Fase de inicio | Esta fase se compone de los procesos relacionados con el inicio de un proyecto: Crear la visión del proyecto, identificar al Scrum Master y a las partes interesadas, formar un equipo de Scrum, desarrollar epopeyas, crear un backlog de productos priorizado y llevar a cabo la planificación de la versión. |
| Inspección | La inspección se refiere al seguimiento necesario para seguir el control empírico del proceso, para garantizar que los entregables del proyecto se ajusten a los requisitos. |
| Dependencias internas | Las dependencias internas son aquellas dependencias entre tareas, productos o actividades que están bajo el control del Equipo Scrum y dentro del alcance del trabajo a ejecutar por el Equipo Scrum. |
| Tasa Interna de Retorno (TIR) | La tasa interna de retorno (TIR) es una tasa de descuento de una inversión en la que el valor presente de las entradas de efectivo se hace igual al valor presente de las salidas de efectivo para evaluar la tasa de rendimiento de un proyecto. Al comparar proyectos, uno con una TIR más alta suele ser mejor. |
| Cuestiones | Los problemas son generalmente certezas bien definidas que están sucediendo actualmente en el proyecto, por lo que no es necesario realizar una evaluación de probabilidad como lo haríamos para un riesgo. |
| Entrega iterativa | La entrega iterativa es la entrega gradual de valor al cliente. |
| Sesiones de JAD | Una sesión de Diseño de Aplicaciones Conjuntas (JAD) es una técnica de recopilación de requisitos. Se trata de un taller facilitado altamente estructurado que acelera el proceso de creación de la visión del proyecto, ya que permite a las partes interesadas del negocio y a otros responsables de la toma de decisiones llegar a un consenso sobre el alcance, los objetivos y otras especificaciones del proyecto. |
| Contrato de Joint Venture | Este contrato se utiliza generalmente cuando dos o más partes se asocian para realizar el trabajo de un proyecto. Las partes involucradas en el proyecto lograrán algún retorno de la inversión porque los ingresos o beneficios generados se compartirán entre las partes. |
| Análisis de Kano | El análisis de Kano fue desarrollado por Noriaki Kano (1984) y consiste en clasificar las características o requisitos en cuatro categorías en función de las preferencias del cliente:Excitadores/DeleitadoresSatisfactoresInsatisfechosIndiferente |
| Líder del Laissez Faire | Un estilo de liderazgo, en el que el equipo queda en gran medida sin supervisión y el líder no interfiere en sus actividades laborales diarias. Esto a menudo conduce a un estado de anarquía. |
| Equipo central grande | El equipo central grande está compuesto por el propietario principal del producto, el jefe de Scrum Master, los Scrum Masters, los propietarios del producto y miembros seleccionados de los equipos de Scrum que trabajan en el proyecto grande |
| Duración del sprint | Sobre la base de las diversas entradas, incluidos los requisitos comerciales y el cronograma de planificación de lanzamientos, el propietario del producto y el equipo Scrum deciden la duración de los Sprints para el proyecto. Una vez determinado, la duración del Sprint suele ser fija para el proyecto. La longitud del sprint es la duración de los sprints determinados para un proyecto. |
| Dependencias obligatorias | Estas dependencias son inherentes a la naturaleza del trabajo, como una limitación física, o pueden deberse a obligaciones contractuales o requisitos legales. |
| Estudio de mercado | El estudio de mercado se refiere a la investigación, recopilación, recopilación y análisis organizados de datos relacionados con las preferencias del cliente por los productos. A menudo incluye datos extensos sobre las tendencias del mercado, la segmentación del mercado y los procesos de marketing. |
| Criterios de selección de miembros | Los criterios de selección de miembros son creados por las partes interesadas del negocio para definir a los miembros del Cuerpo de Orientación de Scrum, sus roles y responsabilidades, el número de miembros y sus habilidades y experiencia requeridas. |
| Criterios mínimos de aceptación | Los Criterios Mínimos de Aceptación son declarados por la unidad de negocio. A continuación, pasan a formar parte de los criterios de aceptación de cualquier historia de usuario de esa unidad de negocio. Cualquier funcionalidad definida por la unidad de negocio debe cumplir con estos Criterios Mínimos de Aceptación, si va a ser aceptada por el respectivo Propietario del Producto. |
| Riesgos mitigados | Los riesgos mitigados se refieren a los riesgos que el equipo Scrum aborda o mitiga con éxito durante el proyecto. |
| Monopolio del dinero | El Dinero Monopólico es una técnica que consiste en dar al cliente “dinero monopólico” o “dinero falso” igual al monto del presupuesto del proyecto y pedirle que lo distribuya entre las Historias de Usuario bajo consideración. De esta forma, el cliente prioriza en función de lo que está dispuesto a pagar por cada Historia de Usuario. |
| Priorización de MoSCoW | El esquema de priorización de MoSCoW deriva su nombre de las primeras letras de las frases “Must have”, “Should have”, “Could have” y “Won’t have”. Las etiquetas están en orden decreciente de prioridad, siendo las características “Imprescindibles” aquellas sin las cuales el producto no tendrá valor y las características “No tendrá” aquellas que, aunque sería bueno tenerlas, no es necesario incluirlas. |
| Valor Actual Neto (VAN) | El Valor Presente Neto (VAN) es un método utilizado para determinar el valor neto actual de un beneficio financiero futuro, dada una inflación o tasa de interés asumida. |
| Función no esencial | “Los roles no esenciales son aquellos roles que no son obligatorios para el proyecto Scrum. Pueden incluir el equipo Miembros que están interesados en el proyecto pero que no tienen un papel formal en el equipo del proyecto. Estas personas pueden: interactúa con el equipo, pero puede no ser responsable del éxito del proyecto”. |
| Etapa de normalización | La tercera etapa de la formación del equipo cuando el equipo comienza a madurar, resolver sus diferencias internas y encontrar soluciones para trabajar juntos. Se considera un período de ajuste. |
| Número de historias | El número de historias se refiere a la cantidad de historias de usuario que se entregan como parte de un solo sprint. Se puede expresar en términos de conteo simple o conteo ponderado. |
| Oportunidades | Los riesgos que pueden tener un impacto positivo en el proyecto se denominan oportunidades. |
| Costo de oportunidad | El costo de oportunidad se refiere al valor de la siguiente mejor opción de negocio o proyecto que se descartó en favor del proyecto elegido. |
| Métodos de implementación organizacional | Los mecanismos de implementación de cada organización tienden a ser diferentes en función de la industria, los usuarios objetivo y el posicionamiento. Dependiendo del producto que se entregue, la implementación puede tener lugar de forma remota o puede implicar el envío físico o la transición de un artículo. |
| Matriz de Recursos Organizacionales | La Matriz de Recursos Organizacionales es una representación jerárquica de una combinación de una estructura organizacional funcional y una estructura organizacional de proyecto. Las organizaciones matriciales reúnen a los miembros del equipo para un proyecto de diferentes departamentos funcionales, como tecnología de la información, finanzas, marketing, ventas, fabricación y otros departamentos, y crean equipos multifuncionales. |
| Comparación emparejada | La comparación emparejada es una técnica en la que se prepara una lista de todas las historias de usuario en el backlog de productos priorizados. A continuación, cada historia de usuario se toma individualmente y se compara con las otras historias de usuario de la lista, una a la vez. Cada vez que se comparan dos historias de usuario, se toma una decisión sobre cuál de las dos es más importante. A través de este proceso, se puede generar una lista priorizada de historias de usuario. |
| Análisis de Pareto | Esta técnica de evaluación del riesgo implica clasificar los riesgos por magnitud. Ayuda al equipo Scrum a abordar los riesgos en orden de sus posibles impactos en el proyecto. |
| Ciclo PDCA/PDSA | El Ciclo Planificar-Hacer-Verificar-Actuar, también conocido como el Ciclo de Deming o Shewhart, fue desarrollado por el Dr. W. Edwards Deming, considerado el padre del control de calidad moderno y el Dr. Walter A. Shewhart. Más tarde, Deming modificó Planificar-Hacer-Verificar-Actuar a Planificar-Hacer-Estudiar-Actuar (PDSA) porque sintió que el término “Estudio” enfatizaba el análisis en lugar de simplemente la inspección, como lo implica el término “Verificar”. Tanto Scrum como el ciclo Deming/Shewhart/PDCA son métodos iterativos que se centran en la mejora continua. |
| Etapa escénica | La etapa final de la formación del equipo, cuando el equipo se vuelve más cohesivo y opera a su nivel más alto en términos de rendimiento. Los miembros se han convertido en un equipo eficiente de profesionales que son consistentemente productivos. |
| Personas | Las personas son personajes ficticios muy detallados, representativos de la mayoría de los usuarios, así como de otras partes interesadas de la empresa que pueden no utilizar directamente el producto final. Las personas se crean para identificar las necesidades de la base de usuarios objetivo. |
| Plan de pilotaje | Un plan piloto se puede utilizar para trazar una implementación piloto en detalle. El alcance y los objetivos de la implementación, la base de usuarios de la implementación de destino, un cronograma de implementación, los planes de transición, la preparación requerida del usuario, los criterios de evaluación para la implementación y otros elementos clave relacionados con la implementación se especifican en el plan piloto y se comparten con las partes interesadas del negocio. |
| Fase de planificación y estimación | La fase de Planificación y Estimación consta de procesos relacionados con las tareas de planificación y estimación, que incluyen Crear Historias de Usuario; Aprobar, estimar y confirmar historias de usuario; Crear tareas; Tareas de estimación; y Actualizar el Backlog de Sprint. |
| Planificación para el valor | La planificación del valor se refiere a la justificación y confirmación del valor del proyecto. La responsabilidad de determinar cómo se crea valor recae en las partes interesadas (patrocinador, clientes y/o usuarios), mientras que el equipo Scrum se concentra en lo que se va a desarrollar. |
| Planificación del póker | El Planning Poker, también llamado Estimation Poker, es una técnica de estimación que equilibra el pensamiento grupal y el pensamiento individual para estimar el tamaño relativo de las historias de usuario o el esfuerzo requerido para desarrollarlas. |
| Cartera | Un portafolio es un grupo de programas y/o proyectos relacionados, con el objetivo de ofrecer resultados comerciales tal como se definen en la Declaración de Visión del Portafolio. El trabajo pendiente de cartera priorizado incorpora los trabajos pendientes de programa priorizado para todos los programas de la cartera. |
| Propietario de Producto de Portafolio | El Portfolio Product Owner define los objetivos estratégicos y las prioridades para el portfolio. Scrum Master de Portafolio El Scrum Master de Portafolio resuelve problemas, elimina impedimentos, facilita y lleva a cabo reuniones para el portafolio. |
| Portafolio Scrum Master | El Scrum Master de Portafolio resuelve problemas, elimina impedimentos, facilita y realiza reuniones para el portafolio. |
| Entregables potencialmente entregables de proyectos | Los entregables potencialmente entregables de los proyectos son insumos valiosos para la coordinación a nivel de programa o cartera. Al final de los Sprints en los proyectos, se completan los incrementos de productos o los entregables. Las Historias de Usuario incluidas en estos incrementos cumplen con los criterios de Definición de Hecho, así como con sus respectivos Criterios de Aceptación. |
| Priorización | Priorizar se puede definir como determinar el orden de las cosas y separar lo que se hará ahora, de lo que se puede hacer más adelante. |
| Cartera de productos priorizada | El backlog de producto priorizado es un documento de requisitos único que define el alcance del proyecto al proporcionar una lista priorizada de características del producto o servicio que entregará el proyecto. |
| Reunión de revisión del backlog de productos priorizados | Una reunión de revisión del backlog del producto (también conocida como sesión de refinamiento del backlog del producto priorizado) es una reunión formal durante el proceso de refinamiento del backlog del producto priorizado, que ayuda al equipo de Scrum a revisar y obtener consenso sobre el backlog del producto priorizado. |
| Cuadrícula de impacto de probabilidad | Una cuadrícula donde se evalúan los riesgos para determinar la probabilidad de ocurrencia y el impacto potencial en los objetivos del proyecto. Por lo general, se asigna una calificación numérica tanto para la probabilidad como para el impacto de forma independiente. A continuación, los dos valores se multiplican para derivar una puntuación de gravedad del riesgo, que se puede utilizar para priorizar los riesgos. |
| Árboles de probabilidad | Los eventos potenciales se representan en un diagrama con una rama para cada resultado posible de los eventos. La probabilidad de cada resultado se indica en la rama apropiada, y estos valores se pueden utilizar para calcular el impacto general de la ocurrencia de riesgos en un proyecto. |
| Producto | El término “producto” en la Guía SBOK puede referirse a un producto, servicio u otro producto que proporciona valor al cliente. ® |
| Plan de colaboración para propietarios de productos | El Plan de Colaboración de Propietarios de Producto debe definir cómo colaboran varios Propietarios de Producto con el Propietario Principal del Producto. |
| Prioritized Program or Portfolio Backlog Review Meetings | At the program or portfolio level, there is representation from each project in the program or from each program in the portfolio. To streamline the meeting, it is generally recommended to have only one representative from each project or program attend at the program or portfolio level. |
| Product Owner | The Product Owner is the person responsible for maximizing business value for the project. He or she is responsible for articulating customer requirements and maintaining business justification for the project. |
| Program | A program is a group of related projects, with the objective to deliver business outcomes as defined in the Program Vision Statement. The Prioritized Program Backlog incorporates the Prioritized Product Backlogs for all the projects in the program. |
| Program and Portfolio Risks | Risks related to a portfolio or program that will also impact projects that are part of the respective portfolio or program. |
| Program Product Owner | The Program Product Owner defines the strategic objectives and priorities for the program. |
| Program Scrum Master | The Program Scrum Master solves problems, removes impediments, facilitates, and conducts meetings for the program. |
| Proyecto | Un proyecto es una empresa colaborativa para crear nuevos productos o servicios o para entregar resultados según se define en la Declaración de Visión del Proyecto. Los proyectos suelen verse afectados por limitaciones de tiempo, coste, alcance, calidad, personas y capacidades organizativas. |
| Beneficios del proyecto | Los beneficios del proyecto incluyen todas las mejoras medibles en un producto, servicio o resultado que podrían proporcionarse a través de la finalización exitosa de un proyecto. |
| Presupuesto del proyecto | El presupuesto del proyecto es un documento financiero que incluye el costo de las personas, los materiales y otros gastos relacionados en un proyecto. Por lo general, el presupuesto del proyecto es aprobado por el patrocinador o patrocinadores para garantizar que haya fondos suficientes disponibles. |
| Carta del proyecto | Una carta de proyecto es una declaración oficial de los objetivos y resultados deseados del proyecto. En muchas organizaciones, el acta de constitución del proyecto es el documento que autoriza oficial y formalmente el proyecto, proporcionando al equipo la autoridad por escrito para comenzar el trabajo del proyecto. |
| Costos del proyecto | Los costos del proyecto son los costos de inversión y otros costos de desarrollo de un proyecto |
| Razonamiento del proyecto | “El razonamiento del proyecto incluye todos los factores que apoyan o contribuyen a la necesidad del proyecto, ya sea positivo o negativas, elegidas o no (p. ej., capacidad inadecuada para satisfacer la demanda existente y prevista, disminución de la satisfacción del cliente, bajos beneficios y requisitos legales)”. |
| Escalas de tiempo del proyecto | Las escalas de tiempo reflejan la duración de un proyecto. Los plazos relacionados con el caso de negocio también incluyen el tiempo durante el cual se obtendrán los beneficios del proyecto. |
| Reunión de Visión del Proyecto | Una Reunión de Visión de Proyecto es una reunión con las Partes Interesadas del Negocio del Programa, el Propietario del Producto del Programa, el Scrum Master del Programa y el Propietario Principal del Producto. Ayuda a identificar el contexto empresarial, los requisitos empresariales y las expectativas de las partes interesadas del negocio para desarrollar una Declaración de Visión del Proyecto eficaz. |
| Declaración de la Visión del Proyecto | El resultado clave del proceso de creación de la visión del proyecto es una declaración de visión del proyecto bien estructurada. Una buena visión del proyecto explica la necesidad del negocio y lo que se pretende satisfacer con el proyecto, en lugar de cómo satisfará la necesidad. |
| Elementos no funcionales propuestos para la cartera de productos | Es posible que los requisitos no funcionales no estén completamente definidos en las primeras etapas del proyecto y pueden surgir durante las reuniones de Sprint Review o Retrospect Sprint. Estos elementos deben agregarse al trabajo pendiente de productos priorizados a medida que se detectan. |
| Calidad | La calidad se define como la capacidad del producto o entregables terminados para cumplir con los criterios de aceptación y lograr el valor comercial esperado por el cliente. |
| Garantía de calidad | El aseguramiento de la calidad se refiere a la evaluación de los procesos y normas que rigen la gestión de la calidad en un proyecto para garantizar que sigan siendo relevantes. Como parte del trabajo se llevan a cabo actividades de aseguramiento de la calidad. |
| Control de calidad | El control de calidad se refiere a la ejecución de las actividades de calidad planificadas por el equipo Scrum en el proceso de creación de entregables que son potencialmente entregables. También incluye el aprendizaje de cada conjunto de actividades completadas con el fin de lograr una mejora continua. |
| Gestión de la calidad | La gestión de la calidad en Scrum permite a los clientes darse cuenta de cualquier problema en el proyecto con antelación y les ayuda a reconocer si un proyecto va a funcionar para ellos o no. La gestión de la calidad en Scrum se facilita a través de tres actividades interrelacionadas:Planificación de la calidadControl de calidadGarantía de calidad |
| Planificación de la calidad | La planificación de la calidad se refiere a la identificación y definición del producto requerido de un Sprint y del proyecto, junto con los criterios de aceptación, los métodos de desarrollo a seguir y las responsabilidades clave de los miembros del equipo Scrum con respecto a la calidad. |
| Mejoras recomendadas en el cuerpo de orientación de Scrum | Como resultado de la planificación del proyecto grande, se pueden hacer sugerencias para revisar o mejorar las Recomendaciones del Cuerpo de Orientación de Scrum. Si el Organismo Rector acepta estas sugerencias, se incorporarán como actualizaciones a la documentación del Cuerpo Rector de Scrum. |
| Refactorización | La refactorización es una herramienta específica de los proyectos de software. El objetivo de esta técnica es mejorar la capacidad de mantenimiento del código existente y hacerlo más simple, conciso y flexible. Refactorizar significa mejorar el diseño del código actual sin cambiar cómo se comporta el código. Se trata de lo siguiente:Eliminación de código repetitivo y redundanteDividir métodos y funciones en rutinas más pequeñasDefinición clara de variables y nombres de métodosSimplificación del diseño del códigoHacer que el código sea más fácil de entender y modificar |
| Refinar el backlog de productos priorizados | Refinar el backlog de productos priorizados es un proceso en el que el backlog de productos priorizados se actualiza y mantiene continuamente. Regulaciones Las regulaciones incluyen cualquier regulación federal, local, estatal o de la industria a la que debe adherirse el programa o la cartera. A veces, es posible que sea necesario actualizar las recomendaciones del Cuerpo de Guía de Scrum para reflejar las nuevas regulaciones. |
| Entregables rechazados | Los entregables rechazados son los entregables que no cumplen con los criterios de aceptación definidos. Se mantiene y actualiza una lista de los entregables rechazados después de cada reunión de revisión del Sprint con los entregables que no se aceptaron. |
| Actualizaciones rechazadas a las recomendaciones del organismo de orientación de Scrum | Es posible que no siempre se acepten las mejoras del cuerpo de orientación de Scrum. Si la mejora recomendada es rechazada por los miembros del Órgano de Orientación de Scrum, se proporciona a la parte pertinente comentarios que compartan el motivo de ese rechazo. |
| Clasificación de Priorización Relativa | La clasificación de priorización relativa es una lista simple de historias de usuario en orden de prioridad. Es un método eficaz para determinar las historias de usuario deseadas para cada iteración o lanzamiento del producto o servicio. |
| Tamaño relativo/puntos de historia | Además de utilizarse para estimar el costo, los puntos de historia también se pueden utilizar para estimar el tamaño total de una historia de usuario o función. Este enfoque asigna un valor de puntos de historia en función de una evaluación general del tamaño de una historia de usuario teniendo en cuenta el riesgo, la cantidad de esfuerzo requerido y el nivel de complejidad. |
| Contenido de la publicación | Consiste en información esencial sobre los entregables que pueden ayudar al equipo de atención al cliente. |
| Notas | Las notas de la versión deben incluir criterios de envío externos o orientados al mercado para el producto que se va a entregar. |
| Programación de planificación de lanzamientos | Un cronograma de planificación de lanzamientos es uno de los resultados clave del proceso de planificación de lanzamientos de conducta. Un cronograma de planificación de lanzamientos establece qué entregables se entregarán a los clientes, junto con los intervalos planificados y las fechas para los lanzamientos. Es posible que no haya un lanzamiento programado al final de cada iteración de Sprint. |
| Sesiones de planificación de lanzamientos | El objetivo principal de las sesiones de planificación de lanzamientos es crear un programa del plan de lanzamiento y permitir que el equipo de Scrum tenga una visión general de los lanzamientos y el calendario de entrega del producto que están desarrollando, de modo que puedan alinearse con las expectativas del propietario del producto y de las partes interesadas comerciales relevantes. |
| Métodos de preparación de lanzamientos | Los métodos de preparación de lanzamientos son los métodos utilizados para ejecutar las tareas identificadas en el Plan de preparación para lanzamientos con el fin de preparar los entregables para ser enviados/liberados. |
| Métodos de priorización de versiones | “Release Prioritization Methods are used to develop a Release Planning Schedule. These methods are usually industry- and/or organization-specific and are usually determined by senior management in an organization.” |
| Release Readiness Plan | It details the steps to be taken by relevant Scrum Teams and any other individuals to confirm that the minimum requirements for release have been met, and the product or product increment is ready for release. |
| Release Readiness Sprint | If there is a need for specific tasks to be performed to get ready for a Release and to confirm that the minimum requirements for release have been met, these tasks are performed in a Release Readiness Sprint. A Release Readiness Sprint, if required, is only done once per Release as the last Sprint prior to the Release. |
| Resolved Issues | In Scrum of Scrums Meetings, Scrum Team members have the opportunity to transparently discuss issues impacting their project. This timely discussion and resolution of issues in the Scrum of Scrums Meeting greatly improves coordination between different Scrum Teams and also reduces the need for redesign and rework. |
| Retrospect Program or Portfolio Meeting | The Retrospect Program or Portfolio Meeting is similar to the Retrospect Release Meeting but is carried out at the program or portfolio level. The major difference is that the frequency of Retrospect Program and Portfolio Meetings is much lower than that of the Retrospect Release Meetings |
| Retrospect Release | In this process, which completes the project, organizational business stakeholders and Scrum Core Team members assemble to retrospect the project and identify, document, and internalize lessons learned. Often, these lessons lead to the documentation of agreed actionable improvements, to be implemented in future projects. |
| Retrospect Release Meeting | The Retrospect Release Meeting is a meeting to determine ways in which team collaboration and effectiveness can be improved in future projects. Positives, negatives, and potential opportunities for improvement are also discussed. This meeting is not Time-boxed and may be conducted in person or in a virtual format |
| Retrospect Sprint | In this process, the Scrum Master and Scrum Team meet to discuss the lessons learned throughout the Sprint. The lessons learned are documented and can be applied to future Sprints. |
| Retrospect Sprint Log(s) | The Retrospect Sprint Log is a record of the opinions, discussions, and actionable items raised in a Retrospect Sprint Meeting. The Scrum Master may facilitate creation of this log with inputs form Scrum Core Team members |
| Retrospect Sprint Meeting | The Retrospect Sprint Meeting is Time-boxed to 4 hours for a one-month Sprint and conducted as part of the Retrospect Sprint process. The length may be scaled up or down relative to the length of the Sprint. During this meeting, the Scrum Team gets together to review and reflect on the previous Sprint in terms of the processes followed, tools employed, collaboration and communication mechanisms, and other aspects relevant to the project. |
| Return on Investment (ROI) | Return on Investment (ROI), when used for project justification, assesses the expected net income to be gained from a project. It is calculated by deducting the expected costs or investment in a project from its expected revenue and then dividing this (net profit) by the expected costs in order to get a return rate. |
| Risk | Risk is defined as an uncertain event or set of events that can affect the objectives of a project and may contribute to its success or failure. |
| Risk Assessment | Risk assessment refers to evaluating and estimating identified risks. |
| Risk Attitude | Essentially, the Risk Attitude of the Business Stakeholder(s) determines how much risk the Business Stakeholder(s) consider acceptable. This is a determining factor in when they will decide to take actions to mitigate potential adverse risks. |
| Risk Appetite | Risk appetite refers to how much uncertainty a business stakeholder or organization is willing to take on. |
| Risk Averse | Risk Averse is one of the categories of Utility Function. It refers to the Business Stakeholder being unwilling to accept a risk no matter what the anticipated benefit or opportunity. |
| Risk Breakdown Structure | In this structure, risks are grouped based on their categories or commonalities. For example, risks may be categorized as financial, technical, or safety related. |
| Risk Burndown Chart | A chart that depicts cumulative project risk severity over time. The likelihood of the various risks are plotted on top of each other to show cumulative risk on the y-axis. The initial identification and evaluation of risks and the creation of the Risk Burndown Chart are done early in the project. |
| Risk Checklists | Risk Checklists include key points to be considered while identifying risks, common risks encountered in Scrum projects, or even categories of risks that should be addressed by the team. |
| Risk communication | Risk Communication involves communicating the findings from the first four steps of Risk Management to the appropriate Business Stakeholder(s) and determining their perception regarding the uncertain events. |
| Risk Identification | Risk Identification is an important step in Risk Management which involves using various techniques to identify all potential risks. |
| Risk Meeting | Risks can be more easily prioritized by the Product Owner by calling a meeting of the Scrum Core Team and optionally inviting relevant Business Stakeholders to the meeting. |
| Risk Mitigation | Risk Mitigation is an important step in Risk Management that involves developing an appropriate strategy to deal with a risk. |
| Risk Neutral | Risk Neutral is one of the categories of Utility Function that refers to a Business stakeholder being neither risk averse nor risk seeking; any given decision is not affected by the level of uncertainty of the outcome. When two possible scenarios carry the same level of benefit, the risk neutral stakeholder will not be concerned if one scenario is riskier than the other. |
| Risk Prioritization | Risk Prioritization is an important step in Risk Management that involves prioritizing risks to be included for specific action in the Prioritized Product Backlog. |
| Risk Prompt Lists | Risk Prompt Lists are used in stimulating thoughts regarding the source from which risks may originate. Risk Prompt Lists for various industries and project types are available publicly. |
| Risk Seeking | Risk Seeking is one of the categories of Utility Function that refers to a Business stakeholder being willing to accept risk even if it delivers a marginal increase in return or benefit to the project. |
| Risk threshold | Risk Threshold refers to the level at which a risk is acceptable to the stakeholder’s organization. A risk will fall above or below the risk threshold. If it is below, the Business stakeholder or organization is more likely to accept the risk. |
| Risk-Based Spike | Risk-Based Spikes are basically experiments that involve research or prototyping to better understand potential risks. In a spike, an intense two to three-day exercise is conducted (preferably at the beginning of a project before the Develop Epic(s) or Create Prioritized Product Backlog processes) to help the team determine the uncertainties that could affect the project. |
| Scope | The scope of a project is the total sum of all the product increments and the work required for developing the final product. |
| Scrum Guidance Body | The Scrum Guidance Body (SGB) is an optional role. It generally consists of a group of documents and/or a group of experts who are typically involved with defining objectives related to quality, government regulations, security, and other key organizational parameters. |
| Scrum Guidance Body Expertise | Scrum Guidance Body Expertise relates to documented rules and regulations, development guidelines, or standards, and best practices. |
| Scrum Guidance Body Meetings | The Scrum Guidance Body meets regularly to discuss the potential need for an update of the Scrum Guidance Body Recommendations (e.g., recommended improvements from Retrospectives and other processes, updated regulations, etc.). The frequency of the meetings is decided by the Scrum Guidance Body based on the specific needs of the enterprise. |
| Scrum Guidance Body Members | The Scrum Guidance Body (SGB) members can include Scrum experts, selected Scrum Masters, Product Owners and team members (on all levels). However, there should be a limit on the number of members that a SGB can have in order to ensure that it remains relevant and does not become prescriptive in nature. |
| Scrum Master | The Scrum Master is one of the Scrum Core Team roles. He or she facilitates creation of the project’s deliverables, manages risks, changes, and impediments during the Conduct Daily Standup, Retrospect Sprint, and other Scrum processes. |
| Scrum Masters/Scrum Teams Collaboration Plan | The Scrum Masters/Scrum Teams Collaboration Plan defines how the numerous Scrum Masters and Scrum Teams collaborate with each other to provide highest value in the shortest possible time. |
| Scrum of Scrums Meeting | A Scrum of Scrums Meeting is an important element when scaling Scrum to large projects. Typically, there is one representative in the meeting from each Scrum Team—usually the Scrum Master—but it is also common for anyone from the Scrum Team to attend the meeting if required. This meeting is usually facilitated by the ChiefScrum Master and is intended to focus on areas of coordination and integration between the different ScrumTeams. |
| Scrum Team | The Scrum Team is one the Scrum Core Team roles. The Scrum Team works on creating the deliverables of the project and contributes to realizing business value for all Business stakeholders and the project. |
| Scrum Team Lessons Learned | The self-organizing and empowered Scrum Team is expected to learn from mistakes made during a Sprint and these lessons learned help the teams improve their performance in future Sprints. |
| Scrum Team Representatives | A representative nominated by the team to represent them in the Scrum of Scrums (SoS) Meetings based on who can best fulfill the role depending on current issues and circumstances. |
| Scrumboard | Scrumboard is a tool used by the Scrum Team to plan and track progress during each Sprint. The Scrumboard contains four columns to indicate the progress of the estimated tasks for the Sprint: a To Do column for tasks not yet started, an In Progress column for the tasks started but not yet completed, a Testing column for tasks completed but in the process of being tested, and a Done column for the tasks that have been completed and successfully tested. |
| Self-organization | Scrum practices encourage the idea that employees are self-motivated and seek to accept greater responsibility. Hence, they deliver much greater value when self-organized. |
| Shared Resources | Shared resources can include people, environment, and equipment that are needed by all or some of the Scrum Teams working on the project. In a large project, the shared resources may be limited and are needed by all or some of the Scrum Teams at the same time. |
| Ship Deliverables | In this process, Accepted Deliverables are delivered or transitioned to the relevant Business Stakeholder(s). A formal Working Deliverables Agreement documents the successful completion of the Sprint. |
| Simple Schemes | Simple Schemes involve labeling items as Priority “1”, “2”, “3” or “High”, “Medium” and “Low” and so on. Although this is a simple and straightforward approach, it can become problematic because there is often a tendency to label everything as Priority “1” or “High”. |
| Skills Requirement Matrix | The skills requirement matrix, also known as a competency framework, is used to assess skill gaps and training requirements for team members. A skills matrix maps the skills, capabilities, and interest level of team members in using those skills and capabilities on a project. Using this matrix, the organization can assess any skill gaps in team members and identify the employees who will need further training in a particular area or competency. |
| Speed Boat | Speed Boat is a technique that can be used to conduct the Retrospect Sprint Meeting. Team members play the role of the crew on a Speed Boat. The boat must reach an island, which is symbolic of the Project Vision. Sticky notes are used by the attendees to record engines and anchors. Engines are things which help them reach the island, while anchors are things that are hindering them from reaching the island. This exercise is time-boxed to a few minutes. |
| Sponsor | The sponsor is the individual or the organization that provides resources and support for the project. The sponsor is also the Business stakeholder to whom everyone is accountable to. The sponsor may be one or more individuals or an organizational group. |
| Sprint | A Sprint is a Time-boxed iteration of one to four weeks in duration during which the Scrum Team works on and creates the Sprint Deliverables. |
| Sprint Backlog | Sprint Backlog is a list of the tasks to be executed by the Scrum Team in the upcoming Sprint. |
| Sprint Burndown Chart | Sprint Burndown Chart is a graph that depicts the amount of work remaining in the ongoing Sprint. |
| Sprint Deliverables | Sprint Deliverables refer to product increments or deliverables that are completed at the end of each Sprint. |
| Sprint Planning Meeting | Sprint Planning Meeting is conducted at the beginning of a Sprint as part of the Update Sprint Backlog process. It is Time-boxed to eight hours for a one-month Sprint and is divided into two parts – Objective Definition and Task Estimation. |
| Sprint Review Meeting | The Sprint Review Meeting is time-boxed to four hours for a one-month Sprint and can be scaled according to the length of the Sprint. During the Sprint Review Meeting, the Scrum Team presents the deliverables of the current Sprint to the Product Owner, who may accept or reject the deliverables. |
| Sprint Tracking Tools | Sprint Tracking Tools are used to track the progress of a Sprint and to know where the Scrum Team stands in terms of completing the tasks in the Sprint Backlog. A variety of tools can be used to track the work in a Sprint, but one of the most common is a Scrumboard, also known as a task board or progress chart. |
| Sprint Velocity | Sprint Velocity is the rate at which the team can complete the work in a Sprint. It is usually expressed in the same units as those used for estimating, normally story points or ideal time. |
| Stakeholder Analysis | A standard stakeholder analysis is used to identify the business stakeholders on program and portfolio levels. Further details related to program or portfolio business stakeholders may be identified as personas in the Create and Refine Program or Portfolio Backlog process. |
| Storming stage | The second stage of team formation where the team begins trying to accomplish the work. However, power struggles may occur and there is often chaos or confusion among team members. |
| Story Mapping | Story Mapping is a technique to provide a visual outline of the product and its key components. Story Mapping, first formulated by Jeff Patton (2005), is commonly used to illustrate product roadmaps. Story maps depict the sequence of product development iterations and map out which features will be included in the first, second, third, and subsequent releases. |
| Supporting Leader | Supporting leaders employ listening, empathy, commitment, and insight while sharing power and authority with team members. Supporting leaders are stewards who achieve results by focusing on the needs of the team. This style is the embodiment of the Scrum Master role. |
| Sustainable Pace | Sustainable Pace is the pace at which the team can work and comfortably maintain. It translates to increased employee satisfaction, stability, and increased estimation accuracy, all of which ultimately leads to increased customer satisfaction. |
| SWOT Analysis | SWOT is a structured approach to project planning that helps evaluate the strengths, weaknesses, opportunities, and threats related to a project. This type of analysis helps identify both the internal and the external factors that could impact the project. |
| Target Customers for Release | Not every release will target all business stakeholders or users. The Business Stakeholders may choose to limit certain releases to a subset of users. The Release Plan specifies the Target Customers for the Release. |
| Task Estimation Workshop | Task Estimation Workshop enable the Scrum Team to estimate the effort required to complete a task or set of tasks and to estimate the people effort and other resources required to carry out the tasks within a given Sprint. |
| Task List | This is a comprehensive list that contains all the tasks to which the Scrum Team has committed to for the current Sprint. It contains descriptions of each task, and may also contact task estimates. |
| Task-Oriented Leader | Task-Oriented Leaders enforce task completion and adherence to deadlines. |
| Team Building Plan | Since a Scrum Team is cross-functional, each member needs to participate actively in all aspects of the project. The Scrum Master should identify potential issues that could crop up with team members and try to address them diligently in the Team Building Plan in order to maintain an effective team. |
| Team Calendar | A Team Calendar contains information regarding availability of team members including information related to employee vacation, leaves, important events, and holidays. |
| Team Expertise | Team Expertise refers to the expertise of the Scrum Team members to understand the User Stories and Tasks in the Sprint Backlog in order to create the final deliverables. Team Expertise is used to assess the inputs needed to execute the planned work of the project. |
| Team Specialization | In a large project, Team Specialization may be required. There are three dimensions of Team Specialization. The first dimension is the need for accomplishing specific tasks. The second dimension is the need for special skills of single team members. The third dimension is that there may be limitations in team flexibility. |
| Technical Debt | Technical Debt (also referred to as design debt or code debt) refers to the work that teams prioritize lower, omit, or do not complete as they work towards creating the primary deliverables associated with the project’s product. Technical Debt accrues and must be paid in the future. |
| Theory X | Theory X leaders assume that employees are inherently unmotivated and will avoid work if possible, warranting an authoritarian style of management. |
| Theory Y | Theory Y leaders assume that employees are self-motivated and seek to accept greater responsibility. Theory Y involves a more participative management style. |
| Theory Z | Theory Z leaders assume that employees will focus on self-actualization when their basic necessities are met. Theory Z also involves a more participative management style. |
| Threats | Threats are risks that could affect the project in a negative manner. |
| Three Daily Questions | Three Daily Questions used in Daily Standup Meetings which are facilitated by the Scrum Master, where each Scrum Team member provides information in the form of answers to three specific questions:What have I done since the last meeting?What do I plan to do before the next meeting?What impediments or obstacles (if any) am I currently facing? |
| Time-boxing | Time-boxing refers to setting short periods of time for work to be done. If the work undertaken remains incomplete at the end of the Time-box, it is moved into a subsequent Time-box. Time-boxes provide the structure needed for Scrum projects, which have an element of uncertainty, are dynamic in nature, and are prone to frequent changes. |
| Transparency | Transparency allows all facets of any Scrum process to be observed by anyone. Sharing all information leads to a high trust environment.s |
| Unapproved Change Requests | Request for changes are usually submitted as Change Requests. Change Requests remain unapproved until they get formally approved. |
| Updated Program Product Backlog | A Program Product Backlog that undergoes periodic refining to incorporate changes and new requirements. |
| Updated Scrum Guidance Body Membership | As a result of assessing the Scrum Guidance Body membership, new members may be included in the Scrum Guidance Body and existing members may be removed or leave the Scrum Guidance Body |
| Update Sprint Backlog | In this process, the Scrum Core Team holds Sprint Planning Meetings where the group creates a Sprint Backlog containing all tasks to be completed in the Sprint. |
| Updated Implementation Deadlines for Projects | Implementation deadlines for projects may be updated to reflect the impact of new or changed User Stories that need to modify or introduce new requirements. |
| Updated Prioritized Program or Portfolio Backlog | The Prioritized Program or Portfolio Backlog may be updated with new User Stories, new Change Requests, new identified risks, updated User Stories, or reprioritization of existing User Stories |
| User | Users are the individuals or the organization that directly uses the project’s product, service, or other results. Like customers, for any organization, there can be both internal and external users. In some cases, customers and users may be the same. |
| User Group Meetings | User Group Meetings involve relevant Business Stakeholder(s), primarily users or customers of the product. They provide the Scrum Core Team with first-hand information about user expectations. This helps in formulating the Acceptance Criteria for the product and provides valuable insights for developing Epics. |
| User Stories | User Stories adhere to a specific, predefined structure and are a simplistic way of documenting the requirements and desired end-user functionality. The requirements expressed in User Stories are short, simple, and easy-to-understand statements resulting in enhanced communication among the Business stakeholders and better estimations by the team. |
| User Story Acceptance Criteria | Every User Story has associated Acceptance Criteria. User Stories are subjective, so the Acceptance Criteria provide the objectivity required for the User Story to be considered as Done or not Done during the Sprint Review providing clarity to the team on what is expected of a User Story. |
| User Story Workshops | User Story Workshops are held as part of the Develop Epic(s) process. The Scrum Master facilitates these sessions. The entire Scrum Core Team is involved and at times it is desirable to include other Business Stakeholder(s). |
| User Story Writing Expertise | The Product Owner, based on his or her interaction with the stakeholders, own business knowledge and expertise, and inputs from the team, develops User Stories that forms the initial Prioritized Product Backlog for the project. |
| Utility Function | Utility Function is a model used for measuring Business stakeholder risk preference or attitude toward risk. It defines the Business Stakeholder(s)’ level or willingness to accept risk. |
| Value Stream Mapping | Value Stream Mapping uses flowcharts to illustrate the flow of information needed to complete a process and may be used to streamline a process by helping to determine non-value-adding elements. |
| Vendor | Vendors include external individuals or organizations that provide products and services that are not within the core competencies of the project organization. |
| Voice of the Customer (VOC) | The Voice of the Customer (VOC) can be referred to as the explicit and implicit requirements of the customer, which must be understood prior to the designing of a product or service. The Product Owner represents the Voice of the Customer. |
| Sala de guerra | War Room es el término comúnmente utilizado para describir la ubicación donde se encuentran todos los miembros del equipo Scrum que trabajan. Normalmente, está diseñado de tal manera que los miembros del equipo pueden moverse libremente, trabajar y comunicarse fácilmente porque están ubicados muy cerca unos de otros. |
| Técnica Delphi de banda ancha | Wideband Delphi es una técnica de estimación basada en grupos para determinar cuánto trabajo está involucrado y cuánto tiempo llevará completarlo. Las personas dentro de un equipo proporcionan de forma anónima estimaciones para cada característica y las estimaciones iniciales se trazan en un gráfico. A continuación, el equipo analiza los factores que influyeron en sus estimaciones y procede a una segunda ronda de estimación. Este proceso se repite hasta que las estimaciones de los individuos están cerca unas de otras y se puede llegar a un consenso para la estimación final. |
| Entregables de trabajo | Este resultado es el entregable final para el que se aprobó el proyecto. |
| Acuerdo de Entregables de Trabajo | Los entregables que cumplen con los Criterios de Aceptación reciben la aprobación formal del negocio por parte del cliente o del patrocinador. |
Recomienda esta sección
Facebook
Twitter
LinkedIn