Os Backlogs estão sob críticas por algum tempo. Lean considera-os como inventário e desperdício. Mary Poppendieck chega ao ponto de sugerir que o product backlog deve ser eliminado se não estiver atendendo ao propósito desejado. Em linhas semelhantes Jeff Patton sugeriu que backlogs curtos achatados falham em transmitir uma visualização de alto nível do sistema. Ele sugeriu usar um mapa de estórias.
De acordo com Jeff, um dos problemas mais comuns que os times Ágeis enfrentam é que eles rapidamente perdem o a visão do todo. A razão para isso é a maneira de como as estórias são organizadas, ignorando completamente o sistema que está sendo construído. Jeff fez uma interessante analogia,
"Nós gastamos muito tempo trabalhando com nossos clientes. Trabalhamos duro para entender seus objetivos, seus usuários, e a maior parte do sistema que poderíamos construir. Então finalmente vamos aos detalhes - os pedaços da funcionalidade que gostaríamos de construir. Na minha cabeça eu vejo uma árvore onde o tronco é construído a partir dos objetivos ou benefícios desejados que impulsionam o sistema; os ramos grandes são os usuários; os pequenos ramos e galhos são as capacidades que eles precisam; e finalmente as folhas são as user stories pequenas o suficiente para colocar dentro do desenvolvimento das iterações."
"Depois de todo esse trabalho, depois de estabelecer todo este entendimento compartilhado eu sinto que temos que puxar todas as folhas da árvore e carragá-las dentro de um saco de folhas - e então cortar a árvore."
"Isto é o que um backlog achatado significa pra mim. Um saco de folhas secas fora de context."
Jeff sugeriu usar um mapa de estórias no lugar do backlog. O mapa de estórias se parece com isso
Aqui, no topo do mapa, estão as grandes estórias ou atividades que os usuários fazem quando interagem com o sistema. A ordem das atividades é a ordem em que os usuários interagem com o sistema. Abaixo as atividades são as tarefas do usuário. Esta é a coleção de tarefas que o usuário executa para realizar a atividade. Por exemplo, se gerenciamento de email é uma atividade então "enviar mensagem," "escrever mensagem," "deletar mensagem," "marcar mensagem como spam", etc, são tarefas do usuário.
Jeff acrescentou que as atividades no mapa formam a espinha dorsal do sistema e as tarefas são as costelas. A idéia não é priorizar a espinha dorsal porque ela é a fundação onde o sistema se encaixa. Portanto, as estórias devem ser priorizadas. Todo o planejamento deve ser feito na base da espinha dorsal e isto é útil para decidir sobre a prioridade das tarefas do usuário que formam as costelas.
O benefício de usar um mapa de estórias é que o todo é agora um tema central. Aparte destes outros benefícios que Jeff sugeriu eram,
Eu posso caminhar pelo mapa do início ao fim com um usuário, pessoas de neǵocio, ou desenvolvedor e contar uma estória sobre os usuários do sistema e o que eles estão fazendo. Eu posso avançar ao longo do topo do mapa, e apenas tocar nos pontos importantes. Eu posso me aprofundar no mapa para discutir os detalhes.
Falando através do mapa com os usuários e com os outros me ajuda a encontrar as coisas que eu esqueci. Eu frequentemente ouço "você esqueceu de alguns passos aqui" para quando os usuários fazem isso.
Eu posso anotar o mapa com pontos negativos ou oportunidades. Como eu falo através do mapa com um usuário é comum ouvir-lhe dizer, "isso aqui é realmente um problema com o sistema de hoje."
Assim, um mapa de estórias ajuda o time a focar constantemente no produto que eles estão construindo. Ele ajuda os times a não perderem o foco na floresta por causa das árvores.