Backlog Incremento e Transparência no SCRUM: Gestão de Times e Métodos Ágeis

Backlog Incremento e Transparência no SCRUM Gestão de Times Métodos Ágeis Diretor Executivo DAVID LIRA STEPHEN BARROS Gerente Editorial ALESSANDRA VANESSA FERREIRA DOS SANTOS Projeto Gráfico TIAGO DA ROCHA Autoria LUIZ GUSTAVO REZENDE MOTTA AUTORIA Luiz Gustavo Rezende Motta Olá Sou graduado em Ciência da Computação e tenho experiência técnicoprofissional de mais de 10 anos na área de Gestão de Projetos Passei por empresas como Unimed Benner e Postal Saúde Sou apaixonado pelo que faço e adoro transmitir minha experiência de vida àqueles que estão iniciando em suas profissões por isso fui convidado pela Editora Telesapiens a integrar seu elenco de autores independentes Estou muito feliz em poder ajudar você nesta fase de muito estudo e trabalho Conte comigo ICONOGRÁFICOS Olá Esses ícones irão aparecer em sua trilha de aprendizagem toda vez que OBJETIVO para o início do desenvolvimento de uma nova competência DEFINIÇÃO houver necessidade de apresentar um novo conceito NOTA quando necessárias observações ou complementações para o seu conhecimento IMPORTANTE as observações escritas tiveram que ser priorizadas para você EXPLICANDO MELHOR algo precisa ser melhor explicado ou detalhado VOCÊ SABIA curiosidades e indagações lúdicas sobre o tema em estudo se forem necessárias SAIBA MAIS textos referências bibliográficas e links para aprofundamento do seu conhecimento REFLITA se houver a necessidade de chamar a atenção sobre algo a ser refletido ou discutido ACESSE se for preciso acessar um ou mais sites para fazer download assistir vídeos ler textos ouvir podcast RESUMINDO quando for preciso fazer um resumo acumulativo das últimas abordagens ATIVIDADES quando alguma atividade de autoaprendizagem for aplicada TESTANDO quando uma competência for concluída e questões forem explicadas SUMÁRIO Backlog do Produto 12 CaracterísticasChave 12 Priorização 13 Requisitos 14 Requisitos Funcionais 14 Requisitos não Funcionais 15 Critérios 16 User Story 17 Backlog da Sprint 23 Característica do Backlog da Sprint 24 Como Criar um Backlog de Sprint 25 Por que o Backlog da Sprint é Importante 26 Criando um Bom Backlog da Sprint 26 Melhores Práticas para Planejar a Sprint Backlog 26 Stakeholders da Sprint Backlog 27 Dicas para Planejar a Sprint Backlog 27 Reunião de Planejamento da Sprint 28 Considerações para Execução do Planejamento 28 Medindo o Progresso de Projetos SCRUM com Burndown Chart 28 Como Criar um Burndown Chart 30 Atualizando o Burndown Chart no Daily Meeting 31 Incremento 33 Incrementos Entregáveis 36 Definição de Preparado 37 Como é a Definição de Preparado 38 Transparência do Artefato 40 Definição de Pronto 41 O que Significa Pronto42 Como é Criada a Definição de Pronto 44 9 UNIDADE 04 Gestão de Times Métodos Ágeis 10 INTRODUÇÃO Os artefatos do SCRUM representam o trabalho ou o valor para o fornecimento de transparência e oportunidades para inspeção e adaptação Os artefatos definidos para o SCRUM são especificamente projetados para maximizar a transparência das informaçõeschaves de modo que todos tenham o mesmo entendimento sobre eles Podem ser representados por backlog do produto backlog da sprinte interação incremento O backlog do produto é uma lista ordenada de tudo que deve ser necessário no produto e é a origem única dos requisitos para qualquer mudança a ser feita Os itens do backlog do produto de ordem mais alta topo da lista devem ser mais claros e mais detalhados do que os itens de ordem mais baixa Estimativas mais precisas são feitas com base em maior clareza e maior detalhamento quanto menor for a ordem na lista menos detalhes existem O backlog da sprint é um conjunto de itens do backlog do produto selecionados para a sprint juntamente com o plano para entregar o incremento do produto e atingir o objetivo da sprint O backlog da sprinté a previsão do time de desenvolvimento sobre qual funcionalidade estará no próximo incremento e sobre o trabalho necessário para entregála Incremento é a soma de todos os itens do backlog do produto completados durante a sprinte o valor dos incrementos de todas as sprints anteriores Ao final da sprint um novo incremento deve estar concluído o que significa que deve estar em condição utilizável e atender à definição do time SCRUM Ao longo desta unidade letiva veremos esses conceitos Gestão de Times Métodos Ágeis 11 OBJETIVOS Olá Seja muito bemvindo à Unidade 4 Backlog incremento e transparência no SCRUM Nosso objetivo é auxiliar você no desenvolvimento das seguintes competências profissionais até o término desta etapa de estudos 1 Organizar requisitos de escopo para o produto em desenvolvimento por meio de backlogs 2 Controlar a lista de afazeres de uma atividade por meio de sprint backlogs 3 Organizar incrementos no produto de forma interativa 4 Discernir sobre a definição de pronto para gerar transparência no artefato Gestão de Times Métodos Ágeis 12 Backlog do Produto OBJETIVO Neste capítulo você será capaz de entender como organizar requisitos de escopo para o produto em desenvolvimento por meio de backlogs Isto será fundamental para o exercício de sua profissão E então motivado para desenvolver esta competência Então vamos lá Avante O backlog do produto product backlog é uma lista de funcionalidades desejadas em um produto ou seja os requisitos que um cliente espera receber ao final do projeto descrito com sua própria linguagem O ponto central do SCRUM é a criação do product backlog pois é nele que o projeto começa É diferente do modelo tradicional de gestão de projetos em que precisamos fechar o escopo para poder começar a executar No SCRUM acreditase que o início do projeto não é o melhor momento para isso afinal nesse ponto ainda não se conhece suficientemente o projeto e é necessário avançar um pouco mais em algumas hipóteses antes de se obter uma certeza Quando um projeto é iniciado não há nenhum esforço abrangente que demande muito tempo para escrever todas as tarefas ou os requisitos previsíveis Normalmente tudo o que é óbvio consta do projeto o que quase sempre é mais que suficiente para a primeira sprint A partir daí o product backlog deverá crescer e mudar na medida em que se conhece melhor o produto e os clientes CaracterísticasChave Para o planejamento eficaz da nossa primeira entrega precisamos desdobrar as característicaschaves do produto programadas para o primeiro release em requisitos ou histórias Na sequência do processo esses requisitos são priorizados e estimados assim como são definidos os perfis e a quantidade dos Gestão de Times Métodos Ágeis 13 integrantes do time de projeto Dessa forma é possível ao final do processo de planejamento obter prazos e estimativas de custo para o projeto Durante a reunião de planejamento sprintplanning o dono do produto Product Owner prioriza os itens do product backlog e os descreve ao time de desenvolvimento Este por sua vez determina quais itens conseguirá concluir na próxima sprinte os passa do product backlog para a sprint backlog Ao fazêlo o time desdobra cada item em uma ou várias tarefas de sprint backlog para que seja possível o compartilhamento de atividades de forma mais efetiva Conceitualmente o time inicia do topo da lista priorizada de product backlog e desenha uma linha logo abaixo do item que o time considerar ser o último possível de se concluir durante a sprint Na prática não é incomum ver um time selecionar por exemplo os cinco itens mais importantes e dois itens que estão abaixo na lista mas associados aos cinco iniciais As estimativas são realizadas pelos desenvolvedores mas é notório que são muito imprecisas e somente são utilizadas para uma grosseira alocação de tarefas nas várias sprints Priorização De forma mais ampla a equipe SCRUM e o Product Owner precisam considerar todo o backlog ao ordenar seus itens a fim de otimizar o valor ou o Retorno Sobre o Investimento ROI A maioria das pessoas normalmente acredita que o ROI é prioritário entretanto devemos pensar o ROI como resultado de longo prazo decorrente da ordenação correta de todo o backlog ao invés da simples soma do ROI dos itens individuais Isso é verdade de certa forma porque o ROI de um item isolado depende de sua posição no backlog Gestão de Times Métodos Ágeis 14 IMPORTANTE Priorizar uma lista significa ordenar seus itens pela importância em relação aos outros As prioridades guiam a comparação dois a dois dos itens na lista Pense na aplicação do algoritmo de ordenação por bolhas bubble sort para priorizar o backlog do Produto compare os dois itens do topo e troqueos de posição se estiverem na ordem errada Requisitos A criação do backlog do produto é realizada a partir do desdobramento das característicaschaves estabelecidas na visão do produto em requisitos funcionais e requisitos não funcionais Requisitos Funcionais De maneira geral os requisitos funcionais são as funções do produto que podem ser descritas priorizadas e estimadas Requisitos também são conhecidos no mundo ágil como histórias Uma história descreve uma necessidade ou situação futura que o cliente pretende alcançar por meio da utilização do produto a ser desenvolvido Normalmente a descrição de uma história ou um requisito utiliza a seguinte estrutura Quadro 1 Descrição de uma história PRECISA PRECISA PRECISA Cliente Reservar filmes pela Internet Para poder retirálos no drivethru da loja Atendente Obter a posição atualizada de um filme Para informar o cliente sobre sua disponibilidade Gestor de loja Consultar informações sobre o histórico dos clientes Para criar e oferecer promoções mais atraentes Fonte Elaborado pelo autor 2021 Gestão de Times Métodos Ágeis 15 Com base nesses exemplos conseguimos visualizar necessidades atuais ou futuras a partir de três pontos de vista diferentes A primeira coluna quem referese ao cliente ao atendente e ao gestor da loja Na segunda coluna o quê é informada a necessidade ou a situação futura desejada Na terceira para quê sua finalidade Uma história para ser considerada completa precisa ser formada por essas três partes quem o quê e para quê Não se trata contudo de uma receita de bolo Podemos descrever requisitos de outras formas como mostrado no exemplo a seguir Reserva de filmes pela internet com retiradas pelo drivethru da loja Consulta da posição atualizada do acervo de filmes atendimento presencial ou por telefone Consulta à informação sobre histórico de transações do cliente criação e oferta de promoções Requisitos não Funcionais Requisitos não funcionais são aspectos subjetivos relacionados à história Vamos considerar o seguinte requisito consulta à posição atualizada do acervo de filmes com tempo de resposta satisfatório A dúvida usual nesse tipo de requisito é o que é tempo de resposta satisfatório Tratase de uma condição que pode gerar várias interpretações Dependendo do perfil do usuário podem existir tolerâncias maiores ou menores Por esse motivo a única forma de resolver esse problema é transformar um requisito não funcional ou a parte não funcional do requisito em algo funcional objetivo Para tanto precisamos definir o que é tempo de resposta satisfatório Se nossos clientesusuários estabelecem uma tolerância máxima de 2 segundos como tempo de resposta satisfatório é possível garantir essa condição com servidores links de acesso arquitetura do site etc Priorização e ordenação andam de mãos dadas Todas as comparações são locais ou seja são restritas a uma otimização local Gestão de Times Métodos Ágeis 16 Critérios Para um requisito fazer parte do backlog do produto deve respeitar os seguintes critérios Ser independente o requisito deve ser capaz de atender à necessidade ou situação futura informada pelo cliente sem depender de outro requisito Essa condição é fundamental para garantir flexibilidade durante o ciclo de desenvolvimento do produto Ser negociável enquanto não for convertido em produto o requisito deve permitir alterações como mudança de prioridade aumentoredução de sua abrangência e desdobramento em outros requisitos Pode inclusive ser reescrito ou mesmo descartado desde que mantido na entrega do produto o valor esperado pelo cliente final Ser priorizado valuable o requisito deve obrigatoriamente assegurar a entrega de valor para o cliente Caso contrário seu desenvolvimento poderá representar desperdício de esforço para o time de projeto Por esse motivo o requisito é priorizado pelo dono do produto de acordo com o valor agregado ao negócio cliente final Ser estimado o requisito deve apresentar condições para que seu prazo de desenvolvimentoentrega possa ser estimado Caso o requisito não ofereça essas condições em virtude por exemplo de seu tamanho deverá ser desdobrado em requisitos menores até que possa ser adequadamente estimado Ser pequeno small esse critério está diretamente relacionado ao anterior O requisito deve estar descrito de forma que sua estimativa tenha certo nível de certeza quanto menor melhor Outro aspecto a ser observado é que a duração prevista do requisito não deve ultrapassar o prazo de execução dos ciclos de trabalho estabelecidos para o projeto sprints Gestão de Times Métodos Ágeis 17 Ser inspecionado testable o requisito propriamente dito ou sua descrição deve prover as informações necessárias para que possa ser inspecionadotestado pelo cliente final Requisitos que não podem ser validados elevam os níveis de risco do projeto e podem ocasionar problemas graves em etapas mais avançadas do projeto Conforme discutido até aqui fica evidente que a elaboração de requisitos não é uma tarefa simples principalmente para quem não está habituado a planejar projetos dessa forma Por esse motivo talvez seja melhor explorar um pouco mais o tema para assegurar o correto entendimento de conceitos e práticas relacionados à elaboração e gestão do backlog do produto ACESSE Para saber mais acesse o link disponível aqui User Story Para estruturar adequadamente o backlog do produto utiliza se o conceito de User Story que contém a descrição detalhada dos requisitos de cada solicitação a ser implementada Ou seja deve conter as necessidades dos usuários ou dos clientes e não as funcionalidades do sistema User Story é uma breve descrição de uma funcionalidade dita com base na perspectiva da pessoa que deseja a nova capacidade geralmente um usuário ou cliente do sistema Tratase de uma mudança de paradigma quando comparado ao framework proposto pelo Project Management Institute PMI para gestão de projetos Esse é um dos papéis do Product Owner traduzir as necessidades do cliente por meio do backlog do produto em uma linguagem não técnica compreensível para todas as pessoas envolvidas no projeto Gestão de Times Métodos Ágeis 18 Cada User Story pode ser composta de ID Identificação única apenas um número com autoincremento Seu objetivo é evitar que ao mudarmos seu nome percamos o controle sobre as histórias garantir traceability ou rastreabilidade Nome Nome curto e descritivo para a história como Layout do Relatório O nome tem que ser explicativo o bastante para que os membros do time e o Product Owner entendam minimamente o que estamos falando e específico o suficiente para distinguila das demais histórias Normalmente usamse entre 2 e 10 palavras Importância Definir qual a importância dessa história na perspectiva do Product Owner em relação ao cliente Por exemplo 10 ou 150 Quanto mais pontos mais importante Estimativa inicial Estimativa preliminar que o time apresenta sobre quanto tempo será necessário para concluir determinada história se comparada às demais Cada empresa trabalha sua estimativa de uma maneira mas normalmente atribuise uma pontuação que está diretamente relacionada à complexidade da tarefa e que servirá como base para calcular quantos dias horas ou recursos serão necessários para entregar Se a pontuação estiver muito alta uma dica interessante é quebrar a tarefa em duas atividades assim ficará mais fácil acertar a estimativa A unidade está ligada aos pontos por história e geralmente corresponde mais ou menos à relação pessoasdias ideal Faça a seguinte pergunta em X dias nós apresentaremos uma implementação pronta demonstrável e testada Se a resposta for com 3 pessoas trancadas em uma sala levará aproximadamente 4 dias então a estimativa inicial é de 12 pontos por história Gestão de Times Métodos Ágeis 19 Demonstração Em alto nível criamos uma descrição de como a história será demonstrada na apresentação da sprint É apenas uma especificação de teste Faça assim depois faça aquilo e então isso deverá acontecer Figura 1 Demonstração Fonte Pixabay Mantenha o product backlog atualizado Histórias que não estejam mais alinhadas à visão do produto devem ser descartadas do backlog do produto Além disso quanto menor for o conjunto de histórias que devem ser priorizadas mais simples será a tarefa Por mais que seja difícil desapegar de uma história pensada e até certo ponto especificada é importante que isso seja feito pois constando no backlog do produto mesmo que com prioridade baixa pode influenciar na priorização das demais histórias e alterar o rumo do produto Dê importância à definição de pronto A definição de história preparada é outro fator que pode auxiliar bastante na priorização Sem ela a equipe de desenvolvimento pode não saber estimar corretamente uma história passando uma falsa noção de Gestão de Times Métodos Ágeis 20 tamanho da história para o Product Owner que tomará decisões sobre priorização com base em uma informação pouco confiável Conhecimento incerteza e risco de histórias Como esses fatores influenciam diretamente o sucesso do produto histórias com baixo grau de conhecimento e alto grau de incerteza e risco devem ter prioridade alta Isso porque quanto mais cedo forem desenvolvidas podese perceber o melhor caminho a ser seguido em um momento prematuro Caso contrário pode não haver o tempo necessário para desenvolver a história e colher os frutos do aprendizado do desenvolvimento dela Figura 2 Questionamentos Fonte Pixabay Qual é a influência da história no próximo release Histórias que permitam um lançamento mais rápido do produto também devem estar no topo do product backlog Por exemplo em um software de geração de nota fiscal a geração da nota é muito mais importante do que o cadastro dos produtos logo ela deve ser priorizada Atenção ao tamanho das histórias Lembrese que a história deve ser pequena suficiente para ser independente e agregar valor para o software e para o cliente Gestão de Times Métodos Ágeis 21 Dessa forma busque uma uniformidade no tamanho das histórias de modo que o product backlog principalmente em seu topo tenha apenas histórias na menor unidade possível À medida que avançamos podemos encontrar histórias maiores assim evitamos que a equipe estime histórias muito grandes que tenham maior risco de apresentar surpresas em seu desenvolvimento e com estimativas mais suscetíveis a erros Atenção à dependência entre as histórias Apesar da definição de que as histórias devem ser independentes muitas vezes não conseguimos evitar a dependência entre elas Nesse caso a melhor opção é deixar essa dependência visível com uma anotação uma cor diferente ou qualquer coisa que chame a atenção para isso Se a história A depende da história B não agrega valor para o negócio fazer a A antes da B e isso deve estar visível para todos os envolvidos no projeto Ouça todos os interessados no projeto A decisão sobre a prioridade do product backlog é única e exclusiva do Product Owner entretanto ele deve ouvir todos os interessados stakeholders no projeto para auxiliar seu processo de tomada de decisão Isso é importante pois o produto sendo desenvolvido não deve agradar somente ao Product Owner mas a todos os envolvidos no projeto principalmente interessados e clientes Utilize técnicas de priorização Novamente apesar de a decisão sobre as prioridades definidas ser única e exclusiva do Product Owner a utilização de técnicas como a técnica de Kano pode ser bastante útil quando existe dúvida sobre a prioridade de um pequeno conjunto de histórias Utilize as técnicas de priorização como suas aliadas para ajudar a resolver esses pequenos conflitos Gestão de Times Métodos Ágeis 22 DEFINIÇÃO A técnica de Kano é um método de gestão de qualidade que busca a melhoria de processos produtos ou serviços Tem como base principal as necessidades do cliente ou seja o que o cliente precisa O que deseja Como alcançar sua verdadeira satisfação Utilizar o modelo de Kano na empresa é uma ótima maneira de acompanhar as reais necessidades dos seus clientes e trabalhar em melhorias seja para produtos serviços atendimentos ou processos DOYLE 2019 Considere a priorização por temas A dependência entre histórias muitas vezes é inevitável Dessa forma agrupar as histórias dependentes e priorizar o tema também pode ajudar Essa priorização pode ser dividida em dois passos primeiramente priorizamse os temas e depois as histórias dentro de cada tema evitando que histórias de um mesmo tema fiquem espalhadas por todo o backlog do produto RESUMINDO E então gostou do que estudamos neste capítulo Esperamos que sim No entanto vamos recordar um pouco do que foi visto Neste capítulo vimos que tão importante quanto entender os conceitos existentes por trás de um backlog do produto é saber trabalhar de forma correta em sua criação e manutenção A definição das estimativas das histórias é responsabilidade do time de desenvolvimento com apoio do SCRUM Master e do Product Owner trabalhando juntos na busca dos objetivos estabelecidos e da produtividade esperada de coerência e produtividade Gestão de Times Métodos Ágeis 23 Backlog da Sprint OBJETIVO Na sprint existe o backlog Devido a sua importância vamos abordar neste capítulo o que é esse artefato quem é o responsável por seu desenvolvimento e todos os temas a ele relacionados ocasionando uma maior compreensão sobre a ligação dele com a sprint Vamos lá A responsabilidade de construir o backlog da sprinté do time de desenvolvimento que listará o que é necessário para criar o produto Devese listar todas as tarefas pertinentes para desenvolver o item desde a modelagem de dados construção da interface desenvolvimento das regras de negócio testes específicos etc Somente o time de desenvolvimento poderá adicionar ou remover tarefas da sprintbacklog e poderá fazêlo a qualquer momento A sprintbacklog é um artefato vivo durante a sprint Na reunião de planejamento ela não precisa estar completa é preciso que contenha apenas as atividades necessárias para os primeiros dias O time de desenvolvimento poderá complementar essa lista sempre que identificar novas tarefas a serem feitas ou ajustar as já definidas mas ainda não realizadas Esse artefato assim como o product backlog deverá ser visível para todo o time SCRUM fortalecendo o aspecto da transparência É comum a utilização de quadro Kanban ou quadro do SCRUM para demonstrar essas atividades e o seu status As atividades da sprintbacklog são medidas em horas e não devem ultrapassar oito pois assim a atividade durará no máximo um dia Se uma tarefa durar mais do que oito horas o ideal é dividila em tarefas menores O motivo dessa duração máxima é tornar seu acompanhamento muito mais fácil já que no SCRUM não se controlam percentuais de uma tarefa realizada mas sim a tarefa concluída em andamento e aberta Tarefas que não foram concluídas não são consideradas no avanço da sprint Gestão de Times Métodos Ágeis 24 Figura 3 Ideia Fonte Pixabay Ao final do dia é bem provável que a tarefa seja concluída e no dia seguinte na reunião diária todos possam acompanhar a evolução da sprint Esse talvez seja um dos pontos mais complicados para quem está acostumado às abordagens tradicionais pois normalmente as tarefas ou atividades são definidas em uma semana Por exemplo a modelagem de dados pode demorar mais do que oito horas a prototipação de uma tela complexa como uma frente de caixa PDV também pode ser grande demais para ser concluída em um dia demandando a divisão da atividade A modelagem por exemplo pode ser quebrada em partes menores como modelagem dos cadastros e modelagem das tabelas de movimentação O protótipo pode ser dividido em tela de venda tela de fechamento da venda tela de busca de produtos etc Característica do Backlog da Sprint O backlog da sprint é dinâmico por natureza A cada sprinto cenário anterior é repetido A boa prática é manter a sprint backlog ou a sprint goal a mais estática possível Durante cada sessão de planejamento de sprint a equipe retorna ao backlog do produto para escolher histórias de usuários recentemente Gestão de Times Métodos Ágeis 25 priorizadas para a sprint O backlog da sprinté um subconjunto do backlog do produto e é uma saída para uma reunião de planejamento No backlog da sprint a equipe SCRUM trabalha em como as histórias do usuário seriam implementadas em uma sprint dividindo em tarefas e estimandoas Suponha que o product backlog tenha as histórias 1 2 3 4 5 e 6 A equipe decide fazer as reportagens 1 2 e 4 A equipe de planejamento da sprintpercebeu que ainda há alguma dúvida que não foi bem respondida pelo Product Owner então decide não incluir a história do usuário 3 e pular para a história do usuário 4 que foi bem definida O backlog da sprinté propriedade da equipe de desenvolvimento e contém o quê e como o projeto é entregue Por último na equipe de backlog da sprintimplementamse convertemse os itens de backlog de produto mais priorizados em software de trabalho Para cada iteração sprint a equipe cria um plano com base no que está no topo do backlog do produto ao iniciar a sprint Como Criar um Backlog de Sprint O backlog da sprinté criado durante a reunião de planejamento A equipe apresenta a quantidade de trabalho que deseja fazer do backlog do produto para o backlog da sprinte decompõe ainda mais os PBIs nas tarefas A equipe decide como expressar isso nas tarefas A melhor maneira de representar a sprintbacklog é um quadro de tarefas físico usando cartões de índice e outras formas de identificação visual ou mantêlo eletronicamente em planilhas ou quadros de tarefas digitais O último tem algumas vantagens como transparência e facilidade de acesso mas adiciona complexidade caso o time SCRUM seja distribuído em vários sites A estrutura deve ser adaptada para refletir as necessidades do projeto Gestão de Times Métodos Ágeis 26 Por que o Backlog da Sprint é Importante É prática comum no SCRUM que o backlog da sprint seja representado em uma placa SCRUM ou em um quadro de tarefas O quadro fornece uma representação constantemente visível do status das histórias de usuário no backlog Também estão incluídos na sprint backlog os riscos associados às várias tarefas Quaisquer atividades de mitigação dos riscos identificados também serão incluídas como tarefas no backlog da sprint Uma vez que o backlog da sprinté finalizado e o time SCRUM se compromete com ele novas histórias de usuário não devem ser adicionadas No entanto tarefas que podem ter sido perdidas ou negligenciadas das histórias de usuários podem precisar ser adicionadas Se surgirem novos requisitos durante uma sprint eles serão adicionados ao backlog priorizado do produto geral e incluídos em uma sprint futura Criando um Bom Backlog da Sprint Envolva todos os membros da equipe no processo Discuta como cada item deve ser implementado Tenha uma definição de pronto Identifique todos os tipos de tarefas Não calcule tarefas em tudo Não atribua tarefas antecipadamente Revise o compromisso da sprint Não use muito tempo Evolua a sprint backlog durante a sprint Melhores Práticas para Planejar a Sprint Backlog A sprint backlog é uma lista ordenada de User Stories que a equipe acredita que possa ser completada durante o próxima sprint Essa lista é um subconjunto do product backlog no qual estão priorizadas todas as User Stories do projeto Gestão de Times Métodos Ágeis 27 Esses itens são puxados a partir do topo do product backlog durante a reunião de planejamento da sprint Esses User Stories estão no topo do product backlog porque o Product Owner as priorizou junto ao cliente com base no critério de geração de valor e no ROI Cada história da sprint deve ter uma pontuação que é atribuída com base no esforço relativo necessário para completar a história A equipe determina a melhor forma de trabalhar com a sprint backlog no entanto quando possível o time deve trabalhar prioritariamente sobre os itens de maior valor Stakeholders da Sprint Backlog PRODUCT OWNER Faz o mapeamento e a priorização do backlog assim como analisa a geração de valor e o ROI junto ao cliente SCRUM MASTER Remove os impedimentos da equipe TIME SCRUM Equipe multidisciplinar e autoorganizada formada por três a nove pessoas Consiste em programadores analista designer tester etc Todos no projeto trabalham colaborativamente para completar o conjunto de trabalho com o qual se comprometem Dicas para Planejar a Sprint Backlog Envolva toda a equipe no processo Discuta como cada item da User Story que será implementada e sua complexidade Identifique todas as tarefas sejam de natureza técnica ou não Reveja as tarefas da sprinte se elas cabem dentro do escopo Gestão de Times Métodos Ágeis 28 Reunião de Planejamento da Sprint A sprint planning meeting é uma reunião na qual estão presentes todos os stakeholders do projeto assim como qualquer pessoa interessada que esteja representando a gerência ou o cliente Nessa atividade do SCRUM o Product Owner apresenta as User Stories de maior prioridade para o time A equipe interage de forma que ocorra o compartilhamento do conhecimento e todos possam compreender o escopo da sprint Assim a equipe técnica tem conhecimento da complexidade da sprint e consegue estimar o esforço para a realização das tarefas Considerações para Execução do Planejamento Previsto o número de histórias que podem ser realizadas na sprint backlog o escopo deve ser blindado até o final da sprint No entanto se durante a sprinto Product Owner decidir que há uma característica de maior valor de negócio que precisa ser incluída na sprint ela deve ser interrompida Se houver uma interrupção que mude drasticamente as prioridades o Product Owner pode abortar a sprint Nesse caso a equipe realiza uma nova sprint meeting planning e uma nova sprint é iniciada Medindo o Progresso de Projetos SCRUM com Burndown Chart Os métodos e as práticas ágeis são extremamente efetivos e eficazes pois produzem resultados de qualidade em pouco tempo se comparados ao modelo em cascata ou outras abordagens tradicionais de desenvolvimento de software Esses resultados são sempre orientados à geração de valor para o cliente ao final de cada sprint do projeto Para alcançar esses resultados é primordial medir e controlar o progresso da sprint Além da questão do gerenciamento existe uma complexidade inerente que é a introdução de novos requisitos frequentemente a cada sprint Na Engenharia Civil ninguém pede para Gestão de Times Métodos Ágeis 29 mover o prédio 1 cm para o lado após a construção da fundação entretanto quando se fala sobre software a evolução é contínua Assim surge um problema para atender ao custo ao prazo e à qualidade associados à sprint Como monitorar e controlar de forma transparente o progresso das sprints de projetos ágeis com a metodologia SCRUM Na engenharia de software clássica cada projeto é composto por milestones marcos que servem para mensurar o progresso do projeto fazendo um comparativo entre o que foi planejado e o que foi realizado em termos de desenvolvimento Uma métrica para estimar o esforço são os Use Case Points lembrando que o esforço é uma métrica dada pela capacidade pessoa hora A desvantagem da métrica envolve a necessidade de ter todos os casos de uso do sistema documentados e detalhados para que seja possível analisar a complexidade No SCRUM todas as User Stories são descritas em uma única sentença simples Nesse contexto como monitorar e controlar as sprints Aqui reforçaremos a importância dos daily meetings para que a dinâmica seja compreendida É no encontro diário que a equipe aponta as tarefas que foram realizadas no dia anterior Assim cada membro dá seu depoimento e compartilha seu progresso com o time Nesse momento o membro seleciona a tarefa que tem maior aptidão para realizar durante o dia Com essas informações o SCRUM Master atualiza o burndown chart diariamente Abrindo um paralelo nenhum projeto atrasa um mês de uma vez O atraso é decorrente da somatória de vários dias de atraso No SCRUM se durante a reunião diária for apontado algum impedimento isso será avaliado assim como seu risco de forma que a sprint seja realizada dentro do prazo Se for um problema impactante a equipe se reúne e discute as medidas a serem tomadas em conjunto para dirimir o problema Gestão de Times Métodos Ágeis 30 Como Criar um Burndown Chart O primeiro passo é fazer o planejamento e a divisão das tarefas da sprint Isso é realizado na reunião de planejamento e utiliza uma técnica denominada Planning Poker Cada tarefa deve ter horas associadas e o tempo de uma tarefa é analisado usando uma sequência Fibonnaci 01 1 2 3 5 8 13 21 34 Ou seja uma tarefa deve ter entre três mínimo e seis horas máximo de modo que possa ser alocada em um dia Se a tarefa tem mais de seis horas deve ser analisada e subdividida Caso a tarefa tenha menos de três horas deve ser vinculada a outra tarefa associada Esse processo é realizado pelo time junto com o SCRUM Master de forma a compartilhar e gerar colaboração em torno da sprint Uma vez que a divisão de tarefas foi realizada o gráfico burndown ideal é traçado O ideal reflete o progresso assumindo que todas as tarefas serão concluídas dentro da sprinta uma taxa uniforme Para saber quantos pontos e a capacidade produtiva de um time para determinada sprint devese levar em consideração as seguintes variáreis Sprint duração de 2 semanas 10 dias úteis Equipe 7 membros Horasdia 6 Capacidade total 420 horas Ou seja para uma equipe de 7 membros cada um trabalhando 6 horas por dia no projeto durante 10 dias podemos executar um total de 420 horas de desenvolvimento Portanto na reunião de planejamento da sprint esse parâmetro deve ser levado em consideração Gestão de Times Métodos Ágeis 31 Figura 4 Exemplo de gráfico de Burndown Capacidade total 420 horas ou pontos 500 375 250 125 0 Fonte Elaborada pelo autor 2020 Atualizando o Burndown Chart no Daily Meeting O progresso realizado pela equipe de desenvolvimento deverá sempre estar próximo do progresso planejado Essa linha se inicia no mesmo ponto de origem do progresso ideal mas seu progresso é dado a partir da queima dos Story Points A reta será traçada a partir do produto do esforço realizado tempo gasto Assim diariamente após a equipe mover as tarefas da coluna de doing para done o SCRUM Master calcula o total de pontos realizados e atualiza o burndown chart conforme mostra a Figura 5 Gestão de Times Métodos Ágeis 32 Figura 5 Burndown chart atualizado após reunião diária Fonte Elaborada pelo autor 2020 RESUMINDO E então gostou do que estudamos neste capítulo Esperamos que sim No entanto vamos recordar um pouco do que foi visto Você deve ter compreendido o que vem a ser o blacklog da sprint Vimos que a responsabilidade para construir esse artefato é do time de desenvolvimento que listará o que é necessário para criar o produto pronto Devese listar todas as tarefas pertinentes para desenvolver o item desde a modelagem de dados construção da interface desenvolvimento das regras de negócio testes específicos etc Vimos também que esse artefato assim como o product backlog deverá ser visível para todo o time SCRUM fortalecendo o aspecto da transparência Assim vimos que a sprint backlog é portanto uma lista de atividades a serem realizadas na sprint para desenvolver os itens do backlog do produto selecionados Estudamos também as características de um backlog da sprinte como criar esse artefato considerando que ele é criado durante a reunião de planejamento Assim se tornou importante estudar o processo de criação desse artefato e a sua importância Gestão de Times Métodos Ágeis 33 Incremento OBJETIVO A sprinttrabalha com o incremento de algum projeto assim começamos indagando você sabe como ocorre esse incremento Qual a importância dele Em que consiste esse incremento São as respostas para essas perguntas que vamos trazer neste capítulo Vamos juntos Em cada sprint do projeto o time de desenvolvimento trabalha nos itens selecionados do alto do product backlog para a sprintbacklog do mais importante para o menos importante visando realizar a meta da sprint Já sabemos que Os Times Scrum são caracterizados por serem times pequenos autoorganizáveis e crossfuncionais squad1 para aperfeiçoar a flexibilidade criatividade e produtividade Esses times têm o comprometimento em entregar produtos de forma iterativa e incremental garantindo que uma versão potencialmente funcional do produto do trabalho esteja sempre disponível MONTEIRO TOKANO 2018 p 8 Assim o incremento do produto é o resultado desse trabalho ou seja é a soma de todos os itens completos em uma sprint Portanto é um incremento de funcionalidades prontas do produto de acordo com a definição de pronto produzido em cada sprint do projeto O incremento do produto é composto por novas funcionalidades e melhorias no que foi produzido anteriormente oriundas de itens do product backlog A natureza incremental desse trabalho faz com que um item já considerado pronto jamais volte para o desenvolvimento Gestão de Times Métodos Ágeis 34 Figura 6 Incremento Fonte Freepik Quando há necessidade de mudanças um novo item relativo a esse trabalho é criado no product backlog No entanto itens não prontos ao final da sprint não fazem parte do incremento do produto e devem voltar ao product backlog a critério do Product Owner É necessário considerar que o incremento São os itens do product backlog que foram completados durante a sprint juntamente com o valor dos incrementos de todas as sprints anteriores O incremento deve estar em condição de ser utilizado independentemente de o Product Owner decidir liberálo em produção ou não MONTEIRO TOKANO 2018 p 10 Esperase que o incremento do produto seja entregável ou potencialmente entregável de forma que o Product Owner possa decidir fazer uma entrega para os clientes do projeto ao final da sprint No entanto embora as entregas devam ser frequentes o Product Owner pode optar por acumular alguns incrementos do produto para só então fazer uma entrega release Ou seja entregável é diferente de entregue Entre as razões para tal um incremento nem sempre representa valor suficiente para ser utilizado por seus usuários Assim pode não fazer sentido entregálo ao final da sprint em que ele foi produzido Mesmo que Gestão de Times Métodos Ágeis 35 represente valor suficiente os clientes podem não conseguir absorver mudanças tão frequentemente ou pode haver questões políticas burocráticas ou técnicas que impeçam o Product Owner de realizar a entrega ao final de cada sprint Figura 7 Incremento para o usuário Fonte Freepik O time de desenvolvimento e o Product Owner demonstram o incremento do produto para os clientes do projeto e pessoas relevantes ao final de cada sprint na reunião de sprint review O principal objetivo dessa reunião é obter feedback dessas pessoas sobre o trabalho realizado e dar a elas um senso do progresso do projeto Para tornar esse feedback possível o incremento do produto deve representar valor visível para os presentes ou seja deve conter funcionalidades que possam ser experimentadas e usadas Gestão de Times Métodos Ágeis 36 Incrementos Entregáveis Em cada sprint é gerado pelo time de desenvolvimento um incremento do produto pronto de acordo com a definição de pronto Idealmente esse incremento está sempre apto a ser entregue para os clientes ou seja é entregável ou potencialmente entregável Figura 8 Incremento entregável Fonte Freepik Quando falamos que o incremento deve ser potencialmente entregável isso significa que o software desenvolvido deve ter plenas condições de ordem técnica para ir para a produção no entanto seu lançamento pode ser adiado em virtude de diferentes questões como negócios e mercado sendo de responsabilidade do Product Owner decidir colocálo para produção ou não Assim a entrega em si somente é feita quando o Product Owner julga que há valor suficiente para que seja utilizado Isso em muitos casos ocorre apenas ao se somar mais de um incremento do produto ou seja a partir dos resultados de mais de uma sprint Há casos contudo em que é necessário algum trabalho adicional antes que um conjunto de Incrementos do Produto possa de fato ser entregue Isso aumenta os riscos do projeto ao se postergar a detecção de problemas Gestão de Times Métodos Ágeis 37 Definição de Preparado A definição de preparado é um artefato utilizado para garantir que os itens a serem considerados na reunião de sprint planning estejam preparados segundo um critério bem definido É um acordo formal entre Product Owner e time de desenvolvimento sobre o estado em que um item do product backlog para ser considerado preparado para entrar na sprint backlog Mesmo que o item no momento da reunião de sprint planning seja de alta prioridade ele poderá ser rejeitado pelo time de desenvolvimento se não estiver preparado de acordo com a definição de preparado Essa definição não é um artefato oficial do SCRUM e portanto é opção do time de SCRUM usála ou não É comum times de SCRUM realizarem esse trabalho de preparação apenas durante a reunião de sprint planning Diversos times optam no entanto por antecipálo realizandoo ao longo da sprint anterior em sessões de refinamento do product backlog Essas sessões realizadas pelo Product Owner e por membros do time de desenvolvimento são importantes para diminuir os riscos de uma sprint mal planejada já que de outra forma detalhes demais são deixados para serem discutidos apenas na reunião de sprint planning Figura 9 SCRUM preparado Fonte Freepik Gestão de Times Métodos Ágeis 38 Esse trabalho excessivo torna a reunião longa cansativa e ineficiente originando uma sprint backlog mal formulada colocando em risco todo o trabalho da sprint O principal resultado esperado das sessões de refinamento do product backlog é que um número suficiente de itens a serem considerados na reunião de sprint planning seguinte esteja preparado para ser desenvolvido Nesses casos a definição de preparado funciona como um critério de entrada para a sprint Caso o item do product backlog esteja preparado de acordo com a definição de preparado ele pode ser aceito para discussão na reunião de sprint planning e consequentemente pode fazer parte da sprint backlog Se o item estiver pronto ele é aceito na reunião de sprint review e sai como parte do incremento do produto gerado Como é a Definição de Preparado A definição de preparado assim como a definição de pronto é criada antes do início do desenvolvimento do produto geralmente antes mesmo da primeira sprint Entretanto ela pode ser modificada e evoluir de forma a acomodar novas necessidades identificadas ao longo do projeto A definição de preparado geralmente tem o formato de uma lista de critérios condições ou ainda passos de um processo É comum a definição de preparado para itens do product backlog conter os seguintes tópicos Deve ter havido um alinhamento sobre o item de forma a gerar uma compreensão compartilhada sobre o que o item representa O item deve ter critérios de aceitação discutidos compreendidos e acordados entre o Product Owner e o time de desenvolvimento O item deve ter sido estimado pelo time de desenvolvimento O item deve ser pequeno o suficiente de acordo com algum critério estabelecido pelo time de desenvolvimento um valor máximo para sua estimativa por exemplo Gestão de Times Métodos Ágeis 39 Assim como a definição de pronto a definição de preparado é criada compreendida e compartilhada por todos os membros do time de SCRUM Assim deve se manter visível para todos eles RESUMINDO E então gostou do que estudamos neste capítulo Esperamos que sim Agora vamos recordar um pouco do que foi visto Você deve ter compreendido o que vem a ser o incremento sendo ele a soma de todos os itens completos em uma sprint Portanto é um incremento de funcionalidades prontas do produto de acordo com a definição de pronto produzido em cada sprint do projeto Esperase que o incremento do produto seja entregável ou potencialmente entregável de forma que o Product Owner possa decidir fazer uma entrega para os clientes do projeto ao final da sprint Além disso compreendemos que o time de desenvolvimento e o Product Owner demonstram o incremento do produto para os clientes do projeto e para as pessoas relevantes ao final de cada sprint na reunião de sprint review Estudamos também o que é preparado dentro da sprint consistindo em um artefato utilizado para garantir que os itens a serem considerados na reunião de sprint planning estejam preparados segundo um critério bem definido e a sua definição é criada antes do início do desenvolvimento do produto geralmente antes mesmo da primeira sprint Gestão de Times Métodos Ágeis 40 Transparência do Artefato OBJETIVO Teremos como foco ao longo deste capítulo a compreensão da transparência do artefato Sabendo que os atos devem ser transparentes e a importância do pronto na sprint Assim vamos nos debruçar a compreender o que são esses elementos Prontos Vamos embarcar juntos SCRUM implica em transparência Decisões para otimizar o valor e o controle de riscos são feitas com base na percepção existente do estado dos artefatos Na medida em que a transparência é plena essas decisões têm uma base sólida mas se os artefatos não são completamente transparentes essas decisões podem ser falhas os valores podem diminuir e os riscos podem aumentar IMPORTANTE O SCRUM Master deve trabalhar com Product Owner o time de desenvolvimento e outras partes envolvidas para entender se os artefatos são plenamente transparentes Há práticas para lidar com transparência incompleta e o SCRUM Master deve ajudar todos a aplicar a prática mais apropriada na ausência de transparência plena O SCRUM Master pode detectar transparência incompleta pela inspeção dos artefatos percebendo padrões ouvindo atentamente o que está sendo dito e detectando diferenças entre o esperado e o resultado real Gestão de Times Métodos Ágeis 41 Figura 10 SCRUM Master Fonte Freepik O trabalho do SCRUM Master é atuar com o time SCRUM e organizar o aumento da transparência dos artefatos Esse trabalho geralmente envolve aprendizagem convencimento e mudança pois a transparência não ocorre de um dia para o outro há um caminho a ser percorrido ACESSE No link disponível aqui você pode obter mais informações sobre as regras do jogo do SCRUM Definição de Pronto Quando o item do backlog do produto ou um incremento é descrito como pronto todos devem entender o que isso significa Embora isso varie significativamente para cada time SCRUM os integrantes devem ter um entendimento compartilhado do que significa o trabalho estar completo assegurando a transparência Essa é a definição de pronto para o time SCRUM e é usado para assegurar quando o trabalho está completado no incremento do produto Gestão de Times Métodos Ágeis 42 A mesma definição orienta o time de desenvolvimento no conhecimento de quantos itens do backlog do produto podem ser selecionados durante a reunião de planejamento da sprint O propósito de cada sprint é entregar incrementos de funcionalidades potencialmente utilizáveis que aderem à definição atual de pronto do time SCRUM No entanto é necessário considerar que Se a definição de pronto para um incremento é parte das convenções padrões ou diretrizes de desenvolvimento da organização todos os times SCRUM devem seguila como um requisito mínimo Se um incremento pronto não é uma convenção de desenvolvimento da organização o time de desenvolvimento do SCRUM deve atribuir a definição apropriada para o produto Se há múltiplos times SCRUM trabalhando no lançamento do sistema ou produto os times de desenvolvimento de todos os times SCRUM devem mutuamente estabelecer a definição de pronto Cada incremento é adicionado a todos os incrementos anteriores e completamente testados garantindo que funcionem juntos Com um time SCRUM maduro é esperado que a sua definição de pronto seja expandida para incluir critérios mais rigorosos de alta qualidade O que Significa Pronto A definição de pronto é um acordo formal entre Product Owner e time de desenvolvimento sobre o que é necessário para considerar que um trabalho realizado na sprint está pronto É um conjunto de critérios compartilhados para que quando o time de desenvolvimento ou um de seus membros afirme que um item ou o incremento do produto está pronto todos compreendam o que isso significa Gestão de Times Métodos Ágeis 43 IMPORTANTE Por meio da definição de pronto é reforçada a transparência já que ela é um pilar principal da metodologia tendo em vista que torna global o significado de done entre os membros do time A mesma definição de pronto se aplica a cada item da sprint backlog e ao incremento do produto como um todo que é o conjunto dos itens desenvolvidos na sprint Ela ajuda o time de desenvolvimento no momento de planejar o trabalho a ser realizado e guia o time de desenvolvimento durante a realização desse trabalho Figura 11 SCRUM pronto Fonte Freepik Diferentemente dos critérios e testes de aceitação a definição de pronto não é específica para um item ou para um grupo de itens ela é a mesma para todos os itens desenvolvidos Uma boa definição de pronto exige preferencialmente de forma explícita que cada item passe nos testes de aceitação acordados especificamente para o item Uma boa definição também garante que o incremento do produto tenha o nível de qualidade exigido para ser entregue Gestão de Times Métodos Ágeis 44 Como é Criada a Definição de Pronto Para a construção de uma definição de pronto efetiva é importante que se considerem as restrições organizacionais que afetam o trabalho do time de SCRUM sejam elas restrições de negócio de processo tecnológicas ou culturais Devido às restrições muitos times de SCRUM iniciam o projeto com uma definição de pronto distante da ideal algum trabalho adicional ainda será necessário para tornar o resultado da sprint o incremento do produto entregável Exemplos dessas atividades adicionais incluem diversos tipos de testes realizados por uma equipe externa como exploratórios de integração de estabilidade e de segurança e outras validações como auditorias externas integrações com outros produtos em desenvolvimento homologações por parte do cliente e alguns tipos de documentação A necessidade dessas atividades não permite que o incremento do produto pronto seja entregável A existência de um trabalho adicional ao pronto em cada sprinté uma disfunção e traz riscos consideráveis ao projeto Esse trabalho ao ser realizado em sprints seguintes desorganiza e adia a entrega de valor Uma alternativa comum é realizálo em uma sprint adicional imediatamente anterior à entrega chamada sprint de estabilização Nessa abordagem diversos problemas serão descobertos tardiamente e cada entrega poderá acumular problemas comuns a projetos em cascata Na medida do possível o time de SCRUM trabalha ao longo do projeto para reduzir a disfunção transferindo progressivamente esse trabalho para dentro das sprints e assim tornando sua definição de pronto cada vez mais estrita à medida que se consegue aproximar de fato o pronto do entregável Em casos muito particulares como projetos de alto risco em que são necessários testes adicionais e auditorias externas o trabalho adicional antes da entrega será sempre necessário e existirá durante todo o projeto Gestão de Times Métodos Ágeis 45 Figura 12 Trabalho adicional Fonte Freepik A definição de pronto pode variar de time para time e de projeto para projeto O time de desenvolvimento possui entre seus membros todas as habilidades e todos os conhecimentos necessários para entregar ao final da sprint um incremento do produto pronto de acordo com a definição de pronto Assim é fácil entender como a definição de pronto e a formação do time de desenvolvimento estão intrinsecamente relacionadas A definição de pronto geralmente se parece com uma lista de atividades ou um processo pelo qual passamos itens de trabalho na sprint Essa lista é definida de acordo com as necessidades do produto das quais a qualidades sempre faz parte e está em conformidade com as convenções e os padrões organizacionais Essas atividades incluem tudo o que deve ser realizado para construir o produto como diferentes tipos de testes documentação que faça parte do produto quaisquer integrações que devam ser realizadas etc Gestão de Times Métodos Ágeis 46 Figura 13 Pronto Fonte Elaborada pelo autor 2020 As atividades da definição de pronto portanto são utilizadas como referência quando o time de desenvolvimento indica quanto trabalho prevê que conseguirá produzir na sprint Servem da mesma forma para quando o time de desenvolvimento estabelece o plano para a sprint quebrando os itens da sprint backlog em tarefas A definição de pronto é criada compreendida e compartilhada por todos os membros do time de SCRUM Dessa forma é essencial mantêla visível para eles Gestão de Times Métodos Ágeis 47 RESUMINDO E então gostou do que estudamos neste capítulo Esperamos que sim Agora vamos recordar um pouco do que foi visto Você deve ter entendido a importância da transparência do SCRUM sabendo que há práticas para lidar com transparência incompleta e que o SCRUM Master deve ajudar todos a aplicar a prática mais apropriada na ausência de transparência plena sendo trabalho dele atuar com o time SCRUM e organizar o aumento da transparência dos artefatos Em seguida estudamos o que é a definição de pronto termo que significa o trabalho estar completo assegurando a transparência Trata se também de um acordo formal entre Product Owner e time de desenvolvimento sobre o que é necessário para considerar que um trabalho realizado na sprint está pronto É um conjunto de critérios compartilhados para que quando o time de desenvolvimento ou um de seus membros afirme que um item ou o incremento do produto está pronto todos compreendam o que isso significa Por fim vimos que a definição de pronto é criada antes do início do desenvolvimento do produto sendo suas atividades utilizadas como referência quando o time de desenvolvimento indica quanto trabalho prevê que conseguirá produzir na sprint Gestão de Times Métodos Ágeis 48 REFERÊNCIAS DOYLE D Conheça o modelo de Kano e os 3 atributos essenciais para analisar a satisfação de seus clientes Siteware 2019 Disponível em httpswwwsitewarecombrqualidademodelodekano Acesso em 20 maio 2022 FIGUEIREDO A M Gerenciamento de projetos ágeis São Paulo Golden Cross 2007 KERZNER H Project management a system approach to planning scheduling and controlling New York John Wiley Sons 2002 LESSA L O papel do PMO nas estruturas organizacionais Belo Horizonte PMI Chapter MG 2006 MONTEIRO A TOKANO M A utilização do framework SCRUM em um projeto de indicadores de negócios SINGEP 2018 Disponível em httpwwwsingeporgbr7singepresultado479pdf Acesso em 03 maio 2022 PERBIRA P et al Entendendo SCRUM para gerenciar projetos de forma ágil Curitiba Revista Mundo PM 2007 Gestão de Times Métodos Ágeis