Image The Scrum framework includes five events. Each is an opportunity to inspect and adapt: to learn, to change direction and to improve. They provide just enough - but not too much - structure to enable the Scrum Team to collaborate effectively.
Image The Scrum framework includes five events. Each is an opportunity to inspect and adapt: to learn, to change direction and to improve. They provide just enough - but not too much - structure to enable the Scrum Team to collaborate effectively.
That's why each Scrum event has a maximum timebox. Those timeboxes are upper limits, not recommended durations! The goal is to make the events just long enough to achieve their purpose, and no longer.
The SprintThe Sprint is timeboxed to a maximum of one month. Within that limit, it should be just long enough for the Developers to deliver a done Increment, and no longer. Two-week Sprints are the most common for software teams. Some teams, such as reporting teams, prefer one week. A few teams (for example, certain COBOL teams) have used three weeks. A team delivering physical hardware might need a full month.
A longer Sprint delays feedback and increases the investment in something that may not work. It also raises the chance that what is being built will miss stakeholder needs. In that sense, the Sprint acts as a timebox for risk: shorter is usually better.
The Product Owner’s needs matter too. Sprint length determines how often the Product Owner can engage stakeholders at the Sprint Review and adjust direction based on real feedback. Some products and stakeholder groups need that inspection more frequently than others.
Because the Sprint must result in something usable, the time required depends on the type of product. The Scrum Team should decide what works best for their unique context. But when in doubt, select a shorter Sprint.
In context
- Topic: Proyectos, PMO y Riesgos — Gestión de proyectos, oficinas de proyecto y riesgo del portafolio.
- Source: Scrum.org
- Published: 18/08/2026
Continue reading at the original source →
Excerpt published automatically by the site radar. The full text belongs to its publisher and is linked above.
Por qué importa
Una oficina de proyectos vale por las decisiones que hace posibles, no por los reportes que produce. Cuando la PMO se convierte en el área que persigue actualizaciones de estado, ya perdió: el equipo aprende a llenar el formato y la información real vuelve a viajar por los pasillos.
Mi filtro es la calidad del reporte de estado. Si todos los proyectos están en verde, el sistema de información no sirve: en cualquier portafolio real hay iniciativas en problemas, y una organización sana las muestra a tiempo en vez de descubrirlas en el comité de cierre.
Lo que suele salir mal
Donde suele romperse es en el traspaso a operación. El proyecto se declara terminado cuando se entrega, no cuando el área que lo recibe puede sostenerlo. Tres meses después el equipo se disolvió, nadie documentó nada y la operación convive con algo que no entiende y no puede modificar.
Qué mirar
- Si el reporte de estado muestra proyectos en rojo: un portafolio todo en verde es un portafolio sin información.
- Qué riesgos están identificados, quién es dueño de cada uno y cuándo se revisaron por última vez.
- El tamaño de la primera entrega útil: mientras más lejos esté, más se parece a una apuesta.
Cómo leo esta entrada
La forma en que yo bajaría esto a tierra es reduciendo el tamaño de las entregas. Un proyecto de dieciocho meses sin nada visible antes del mes doce es una apuesta, no un plan. Prefiero seis entregas que sirvan por separado, aunque el total tarde un poco más, porque cada una corrige el rumbo.
La noticia original está publicada en otro idioma; acá se cita el extracto tal como lo entrega el medio y el comentario se escribe en español.
¿Lo estás viviendo en tu equipo?
Abrí el chat y contame cómo lo están manejando. Me interesa comparar notas.
