Antes de responder esta pergunta, eu acredito que é preciso entender algumas diferenças.

Na gestão de projetos tradicional, o escopo é algo que requer muita atenção e cuidado, pois uma mudança lenta e gradual do escopo de um projeto, além dos objetivos planejados inicialmente, deve ser evitada durante o desenvolvimento do projeto.

Quando se fala em métodos ágeis, o escopo também é algo muito importante, mas a ideia de que haverá mudanças no escopo é bem-vinda.

Os métodos ágeis fixam o tempo e os recursos enquanto estão sendo desenvolvidos os itens de maior valor para o projeto / cliente. Na gestão de projetos tradicional, o escopo do produto é detalhado e deste detalhamento são estimados o tempo e os recursos.

Como nos métodos ágeis o tempo e os recursos são fixos, o projeto tem um custo e uma data de finalização pré definida, o que é muito importante já que nenhuma empresa e/ou projeto tem recursos ilimitados.

Depois de explicado a diferença na abordagem do escopo, voltemos a pergunta inicial.

Nos métodos ágeis, o escopo do produto deve ser definido em alto nível e disponibilizado numa lista conhecida como “product backlog” por um profissional com conhecimento no negócio, o “product owner” (PO). Até este ponto, nenhum detalhe de quais tarefas serão necessárias para cada item, tempo ou recurso deve ser estimado.

Depois do product backlog montado, o mesmo deve ser ordenado e priorizado pelo PO, de forma a colocar os itens de maior valor para o projeto no topo da lista.

Com o product backlog montado, ordenado e priorizado, uma parte é separada, estudada, detalhada e desenvolvida. Logo depois, uma outra parte é separada e o processo se repete até o final do tempo planejado para o projeto. Cada ciclo é conhecido como “sprint”.

Como o time deve fazer pequenas entregas sempre que possível, a empresa já pode tirar vantagens do que já foi disponibilizado. A mudança no escopo, neste caso, tende a eliminar desperdícios e aumentar o ROI do projeto.

Como o escopo não é fixo e não foi detalhado no início do projeto, o PO pode mudar e/ou reordenar o product backlog a cada sprint, mas não é desejável e nem recomendado que se façam mudanças no que já está em desenvolvimento.

O PO é o único responsável por manter itens no product backlog em ordem e priorizado de forma a trazer o máximo de valor para o projeto e/ou empresa.

É importante ressaltar que se o product backlog não chegar até o fim ao final do tempo planejado para o projeto, o PO deve avaliar se a contratação de mais sprints vai aumentar o ROI. Se não for, a ideia é encerrar o projeto e eliminar o que seria um desperdício. [Webinsider]

Leandro Garcia

Leandro Garcia (@lgarcias) é analista de sistema especialista. Possui o blog Leandro Garcia.