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 que importa
Um escritório de projetos vale pelas decisões que torna possíveis, não pelos relatórios que produz. Quando o PMO vira a área que persegue atualizações de status, já perdeu: a equipe aprende a preencher o formulário e a informação real volta a circular pelos corredores.
Meu filtro é a qualidade do relatório de status. Se todos os projetos estão em verde, o sistema de informação não serve: em qualquer portfólio real há iniciativas com problema, e uma organização saudável as mostra a tempo em vez de descobri-las no comitê de encerramento.
O que costuma dar errado
Onde costuma quebrar é na passagem para a operação. O projeto é declarado concluído quando é entregue, não quando a área que recebe consegue sustentá-lo. Três meses depois a equipe se dissolveu, ninguém documentou nada, e a operação convive com algo que não entende e não pode modificar.
O que observar
- Se o relatório de status mostra projetos em vermelho: um portfólio todo verde é um portfólio sem informação.
- Quais riscos estão identificados, quem é dono de cada um e quando foram revisados pela última vez.
- O tamanho da primeira entrega útil: quanto mais longe estiver, mais se parece com uma aposta.
Como leio esta publicação
A forma como eu traria isto ao chão é reduzindo o tamanho das entregas. Um projeto de dezoito meses sem nada visível antes do mês doze é uma aposta, não um plano. Prefiro seis entregas que sirvam separadamente, mesmo que o total demore um pouco mais, porque cada uma corrige o rumo.
A notícia original está publicada em outro idioma; o trecho é citado como o veículo o entrega e o comentário é escrito em português.
Está vivendo isso na sua equipe?
Abra o chat e me conte como estão lidando com isso. Tenho interesse em comparar notas.
