Um problema comum em diversos times é a chegada de novas demandas. Elas vêm de diversas fontes e formatos diferentes: itens de trabalho, histórias de usuários, tíquetes, tarefas, atividades, iniciativas etc. Nesse contexto, uma pergunta que os times normalmente fazem é: tudo o que me demandam eu devo fazer? Esses pedidos têm algum valor? Para isso nós podemos utilizar o upstream.
O fluxo de trabalho
A primeira coisa que temos que apresentar é que podemos mapear todo o trabalho em um fluxo de trabalho. O mapeamento mínimo é o mesmo para todo o tipo de processo de trabalho: a fazer, fazendo e feito. Tudo o que o time ainda precisa fazer, o que está em andamento e o que já foi concluído.

Além disso, conforme compreendemos melhor o trabalho do nosso time, quais etapas existem, podemos acrescentar as etapas exatas que o fluxo de trabalho possui.

O que é o upstream
Infelizmente, muitos times não mapeiam o trabalho que acontece antes do item entrar nas etapas de construção. Essa parte do fluxo, fundamental para o processo, se chama upstream. Ele lida com descoberta, ideação, refinamento e seleção de itens que podem entrar no fluxo principal (downstream). É onde acontece a gestão da demanda: decidir o que vale a pena fazer antes de comprometer a equipe de entrega.
Por que utilizar o upstream?
Toda vez que seu time trabalha em algo, você insere um custo na produção daquele item. Por exemplo, se uma pessoa trabalhou 1 hora em um item, minimamente você deve saber que o custo adicionado naquele item é igual ao salário bruto que aquela pessoa recebe dividido por 30 dividido por 24. Isso ainda é uma aproximação grosseira, pois há outros custos envolvidos naquele trabalho.
Portanto, o que queremos é evitar desperdício e maximizar ganhos. Sendo assim, é muitíssimo importante descobrirmos o que deve ser feito pelo nosso time e descartar tudo o que não agrega valor ao nosso produto ou serviço. É justamente por isso que o upstream é necessário.
Compreendendo onde fica o upstream no mapeamento do fluxo de trabalho
Algo que temos que ficar atentos é que todo fluxo possui três pontos de vital importância:

Ponto de Recebimento da Demanda
O time junto com seus clientes (consumidores) deve entrar em acordo para estabelecer um protocolo de recebimento da demanda. O time pode utilizar um sistema de tiquetes com um conjunto básico de informações ou até mesmo um e-mail (não recomendo em hipótese alguma). Inclusive pode ser o momento em que o Product Owner percebe uma necessidade e apenas escreve a história de usuário.
Em suma, é o ponto em que o time deixa claro para seus clientes que a demanda dele foi recepcionada. Entretanto, não quer dizer que ela será feita, apenas que está recebida na lista de itens a fazer (backlog).
Ponto de Comprometimento
Esse é o ponto que, após análise, descoberta e avaliação, o time aceita o item e se compromete a transformá-lo em parte do produto/serviço. Vale lembrar que também é um combinado entre o cliente e o time, pois este ponto é fundamental para a gestão de expectativas, afinal o cliente agora sabe que a demanda dele será atendida.
Em contrapartida, os itens podem até ser descartados após este ponto, porém já haverá bastante custo inserido nele. Caso aconteça, podemos levar o caso para uma retrospectiva e avaliar como podemos melhorar o upstream do time para que isso nunca mais aconteça.
Ponto de Entrega
Esse é o último ponto do nosso fluxo de trabalho. Quando um item passa por ele, o cliente pode utilizar imediatamente o acréscimo do produto ou serviço. Logo, o item está entregue e não há mais nenhum serviço a ser feito nele. Se o consumidor quiser, ele pode começar a utilizá-lo. Assim como os demais, o time e o cliente precisam fazer um acordo sobre ele, pois é necessário avaliar se as expectativas foram atingidas.
Onde está o upstream?
O upstream é justamente as etapas do fluxo de trabalho entre o Ponto de Recebimento da Demanda e o Ponto de Comprometimento.

Exemplos de etapas do upstream
As etapas que você terá no upstream dependem muito de como o seu time trabalha e o tipo de serviço que ele fornece. Alguns exemplos são:
- Refinamento
- Estudo de Viabilidade
- Triagem
- Análise
- Exploração
- Descoberta (ou como preferem chamar: discovery)
- Decisão Go-No Go
- Minimum Viable Product (MVP)
- Priorização
Não são exemplos de upstream
Também há pessoas que confundem o upstream com o downstream. Alguns exemplos de etapas que não devemos considerar como upstream, pois elas já estão criando o produto final.
- Criação de telas
- Documentação (completa)
- Manutenção / suporte
- Design de arquitetura / API
- Construção / atualização de banco de dados
Podem estar no upstream ou downstream
Também há etapas que dependem bastante de como o time se estrutura e elas podem estar tanto no upstream quanto no downstream. Escreverei alguns exemplos abaixo
User Experience (UX) estará no upstream, após o trabalho do UX, haverá a possibilidade de não dar continuidade ao item de trabalho. No downstream, se for etapa obrigatória para a construção do item, porém sem impacto na decisão de construir ou não o item.
Validação com stakeholders estará no upstream caso eles tenham que validar e decidir se o item será construído conforme imaginado pelo time. Downstream, caso a validação seja para verificar se o item já desenvolvido atendeu às necessidades.
Protótipo. Na prática, é muito raro a galera descartar um protótipo após começar a construir. Se ele está sendo utilizado para validar uma ideia, ele está no upstream, porém se todo o “protótipo” caminha para a construção completa, eu colocaria essa etapa no downstream.
Minimum Viable Product (MVP) se você aplica esse conceito de forma correta: Validar ou invalidar uma hipótese, não tenha dúvida de que ele compõe o seu upstream. Agora, como infelizmente uma boa parte dos times utiliza apenas como a primeira entrega do produto, ele deve estar no seu downstream. Para ser sincero, se esse for o seu caso, nem se preocupe em colocar uma etapa MVP no seu fluxo, pois é apenas a construção normal do produto / serviço, só com um nome chique para destacar a primeira entrega das demais.
O resultado do upstream
Quando chegamos na última etapa do upstream, há três decisões possíveis
Descartar
Depois dessa análise, refinamento e avaliação, o time concluiu que não deve construir esse item. Pode ser porque ele não é relevante para o produto ou serviço, incompatível com as necessidades do cliente, tecnicamente inviável, os custos não compensam a construção, entre muitos outros. O fato é que aquele item não será feito e jamais entrará no downstream. Atenção: o time descarta o item e não o devolve ao backlog. Então eles o jogam na lixeira das ideias.
Investir ou Continuar
Após análise, refinamento e avaliação, o time concluiu que deve construir o item. Ele atravessa o ponto de comprometimento e vai para o downstream.
Colocar na prateleira (Shelve)
Após análise, verificamos que não temos informações suficientes para tomar uma decisão quanto a descartar ou continuar. O item tem alguma importância, porém não é urgente e não podemos neste momento gastar mais tempo analisando-o. Então o time coloca o item na prateleira para que, em um momento oportuno, possamos continuar a análise e aí sim descartá-lo ou continuá-lo.
Essa ação se aplica quando há alta incerteza de retorno sobre o investimento necessário ou informações insuficientes sobre os benefícios que aquele item trará. Futuramente ele poderá ser convertido em um item de trabalho quando as condições econômicas forem favoráveis ou descartado quando as condições econômicas permanecerem desfavoráveis.

Facilitando a decisão
Veja este texto sobre Políticas Explícitas e também uma olhada nesse texto sobre Definição de Transição. Na gestão do fluxo, podemos colocar pequenos checklists para avaliar se o item está apto ou não para passar entre as etapas. No upstream, podemos fazer algo semelhante, porém o nome é Critério de Decisão (Decision Criteria) ou também conhecido como Critério de Investimento (Investment Criteria).
Eles funcionam como pontos de decisão que avaliam se os critérios mínimos para continuar investindo naquele item foram satisfeitos. Sempre que os critérios não são atendidos, a ideia não pode ser promovida e uma nova decisão precisa ser tomada sobre se a colocamos na prateleira ou descartamos.

Conclusão
O upstream não é apenas uma parte no fluxo de trabalho: ele é fundamental para que o time aprenda a separar o que realmente gera valor do que traria apenas desperdício. Em síntese, ao compreender melhor como mapear essas etapas, tomar decisões conscientes sobre descartar, investir ou colocar na prateleira, e aplicar critérios de investimento claros, sua equipe ganha foco, reduz custos e aumenta a capacidade de entregar resultados relevantes.
Quer aprofundar esse conhecimento e aprender na prática como estruturar fluxos eficazes, equilibrar demanda e capacidade e aplicar o método Kanban em diferentes contextos?
👉 Participe do treinamento de Kanban System Design (KSD).
Nele você terá acesso a ferramentas, simulações e estudos de caso que irão transformar a forma como você e sua organização lidam com demandas, prioridades e resultados.
Até a próxima.