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.
Why it matters
A project management office is worth the decisions it makes possible, not the reports it produces. Once the PMO becomes the function chasing status updates, it has already lost: the team learns to fill in the template and the real information goes back to travelling through the corridors.
My filter is the quality of the status report. If every project is green, the reporting system is not working: in any real portfolio some initiatives are in trouble, and a healthy organisation surfaces them in time rather than discovering them at the closure committee.
What usually goes wrong
Where it usually breaks is the handover to operations. The project is declared finished when it is delivered, not when the receiving area can sustain it. Three months later the team has dissolved, nobody documented anything, and operations lives with something it does not understand and cannot change.
What to watch
- Whether the status report shows any red projects: an all-green portfolio is a portfolio without information.
- Which risks are identified, who owns each one, and when they were last reviewed.
- The size of the first useful delivery: the further out it is, the more it resembles a bet.
How I read this entry
The way I would bring this down to earth is by shrinking the size of the deliveries. An eighteen-month project with nothing visible before month twelve is a bet, not a plan. I would rather have six deliveries that stand on their own, even if the total takes a little longer, because each one corrects the course.
This entry is an excerpt from the original source, selected by the site radar. The commentary above is the site's own and does not belong to the cited publisher.
Living through this in your own team?
Open the chat and tell me how you're handling it. I'm interested in comparing notes.
