Trabalho Scrum

UNIVERSIDADE MUNICIPAL DE SÃO CAETANO DO SUL – USCS
MBA em GESTÃO DE PROJETOS
Leandro Simonete Pansan Granço
Trabalho Final
Julio Pedro de Siqueira Junior
São Caetano do Sul

2021
UNIVERSIDADE MUNICIPAL DE SÃO CAETANO DO SUL – USCS
MBA em GESTÃO DE PROJETOS
Leandro Simonete Pansan Granço
Trabalho final
Trabalho apresentado à disciplina ‘Gestão

Ágil de Projetos (Scrum)’, do curso ‘Gestão
de Projetos’, oferecido pela Universidade
Municipal de São Caetano do Sul – USCS,
como requisito para conclusão/aprovação,
sob a orientação do docente: Prof.(ª) Julio
Pedro de Siqueira Junior.
São Caetano do Sul - SP

2021
Sumário
1 Apresentação...................................................................................................................4
2 Descrição do cliente, da empresa e do produto...............................................................4
Descrição do cliente, da empresa e do produto.................................................................................4
Product Backlog..................................................................................................................................5
Definição do time Scrum....................................................................................................................7
Definição das Sprints..........................................................................................................................7
Sprint Planning...................................................................................................................................9
Daily Meeting...................................................................................................................................10
Monitoração do Fluxo de trabalho...................................................................................................10
Definition of Done............................................................................................................................12
Sprint Review...................................................................................................................................15
Sprint Retrospective.........................................................................................................................16
3 Parecer final................................................................................................................... 16
4 Referências.................................................................................................................... 17
1 Apresentação
Este trabalho tem por objetivo apresentar um projeto de desenvolvimento de
uma ferramenta computacional voltada para o setor da engenharia civil com a
implementação da abordagem de princípios ágeis (Scrum).
2 Descrição do cliente, da empresa e do produto
Descrição do cliente, da empresa e do produto
A empresa alvo deste trabalho é uma empresa de pequeno porte voltada para
o setor da construção civil tendo como especialidade o desenvolvimento de projetos
estruturais de obras de arte especiais (pontes, viadutos, passarelas), cuja
necessidade, era desenvolver uma ferramenta computacional personalizada para o
dimensionamento mais preciso, completo e eficiente de lajes em concreto armado
que ao final do ciclo gerasse um relatório com todas as premissas de cálculo
referente a este dimensionamento.
Todo o projeto foi executado com uma equipe especializada da própria

empresa a pedido do diretor da mesma.
Para dar início ao projeto foi marcado uma reunião com o diretor da empresa
afim de investigar as necessidades técnicas do projeto e o que era esperado para os
dados de saída.
De forma sucinta, o diretor da empresa necessitava de uma ferramenta

computacional que extraísse resultados de um modelo de cálculo obtido através do
software de análise estrutural “Midas Civil” e fizesse o dimensionamento do
elemento estrutural em questão baseados em normas técnicas e ao final emitisse
um relatório descrevendo todo o processo realizado no dimensionamento.
Após o levantamento das regras e necessidades do produto formulou-se o

quadro 01 apresentado os requisitos necessários.
Quadro 01 – Descrição dos requisitos
Descrição dos requisitos Funcionais

O sistema deve receber as coordenadas de cada ponto da laje a fim de produzir um diagrama com os esforços
solicitantes no elemento.
O sistema deve receber as características geométricas de cada ponto da laje (espessura).
Entrada de
O sistema deve receber as características do material empregado na laje.
dados:
O sistema deve receber os valores de momento fletor máximo e mínimo nas direções longitudinais e
transversais.
O sistema deve receber quais elementos serão exibidos no relatório.
O sistema deve dimensionar elemento a elemento e emitir uma mensagem caso não esteja em conformidade
com as normas atuais.
Dados de
saída: O sistema deve gerar um diagrama contendo a área de aço necessária em cada ponto da laje.
O sistema deve gerar um relatório final com a descrição de cada passo do dimensionamento.

Descrição dos requisitos não funcionais
O sistema deve aceitar apenas valores numérico nas seguintes unidades: metro e tonelada força e sua derivadas como por
exemplo (tf/m²) os dados de saída podem ser na unidade que mais for conveniente para o procedimento.
A base de dados pode ser acessada por todos os usuários.
O sistema deverá ser criado na plataforma "Scia Design Forms".
Fonte: Elaborado pelo Autor, 2021
Por meio da entrevista com o diretor foi constatado o seguinte ator:
 Engenheiro de projetos: é ele quem desenvolve o modelo de cálculo,

bem como o dimensionamento da laje da estrutura.
Product Backlog
Segundo Ken (2020, p. 12) “O Product Backlog é uma lista ordenada e

emergente do que é necessário para melhorar o produto. É a única fonte de trabalho
realizado pelo Scrum Team.” Os itens que compõe esta lista também são
conhecidos como história de usuário.
 História de usuário - Entrada de dados:
→Eu como engenheiro de projetos, gostaria de entrar com as características do

material empregado na laje
Critérios de aceite:
-Deve ser possível incluir o modulo de elasticidade do material utilizado;
-Deve ser possível incluir o diagrama de tensão deformação do material utilizado.

→Eu como engenheiro de projetos, gostaria de entrar com a geometria completa de
uma laje.
-Deve ser possível incluir as coordenadas de cada ponto da laje de acordo com o
projeto estrutural;
-Deve ser possível incluir a espessura de cada elemento da laje de acordo com o
projeto estrutural.
→Eu como engenheiro de projetos, gostaria de entrar com os esforços solicitantes

para que a ferramenta dimensione a estrutura.
-Deve ser possível incluir esforços devido ao momento fletor de cálculo máximo e
mínimo na direção longitudinal;
-Deve ser possível incluir esforços devido ao momento fletor de cálculo máximo e
mínimo na direção transversal.
 História de usuário - Saída de dados:
→Eu como engenheiro de projetos, gostaria de receber um relatório com o completo

dimensionamento da estrutura, bem como os esforços, materiais e geometria que
compõe a obra.
-Deve ser possível visualizar uma planta da estrutura;
-Deve ser possível visualizar o diagrama tensão deformação dos materiais;
-Deve ser possível visualizar o completo dimensionamento da estrutura incluindo as

fórmulas utilizadas e os valores adotados.
Toadas a histórias foram validadas junto ao diretor da empresa

Definição do time Scrum
A definição do time Scrum ficou da seguinte forma:
 Product Owner:
O gerente de projetos de infraestrutura da empresa assumiu a posição de

Product Owner. Por ser uma empresa de pequeno porte este funcionário era quem
estava disponível para assumir esta posição.
 Scrum Master:
O engenheiro de projetos da empresa assumiu a posição de Scrum Master.

Este engenheiro por seu conhecimento técnico poderia ser mais eficiente orientando
e retirando barreiras que pudessem atrapalhar o projeto.
 Team:
O engenheiro de desenvolvimento da empresa assumiu a posição de Team.

Este engenheiro assumiu este posto por seu conhecimento técnico na área de
engenharia e programação.
Definição das Sprints
Para o desenvolvimento das atividades elencadas no backlog foram

necessárias basicamente duas Sprints sendo elas:
 Sprint 01
Para a Sprint 01 foi elencada a funcionalidade onde a ferramenta recebe os

esforços solicitantes, faz o dimensionamento e emite na tela uma tabela com os
resultados obtidos neste dimensionamento.
 Sprint 02
Para a Sprint 02 foi elencada a funcionalidade onde a ferramenta já possui os

resultados do dimensionamento e produz um relatório completo de como esses
resultados foram obtidos.
Como proposta para este trabalho será discutida apenas a Sprint 02. Assim
apresenta-se nas Figuras 01 a 03 o resultado da Sprint 01 já concluída.
Figura 01 – Entrada de dados referente ao material empregado na estrutura
Figura 02 – Entrada de dados referente a geometria
Figura 03 – Entrada de dados referente aos esforços

Sprint Planning
Segundo Ken (2020, p. 9) “A Sprint Planning inicia a Sprint ao definir o

trabalho a ser realizado na Sprint. Este plano resultante é criado pelo trabalho
colaborativo de todo o Scrum Team.”
O Product Owner (PO) propõe desenvolver a Sprint 02 a fim de aumentar sua

importância, para isso o PO descreve as funcionalidades que devem ser atendidas.
Todo o Scrum team participa das determinações das metas fechando este ciclo
antes do final da Sprint Planning.
Na reunião que durou cerca de 6hrs, os integrantes do Scrum Team se

apropriaram mais a fundo dos assuntos que seriam tratados na Sprint 02 tirando
algumas dúvidas com o Product Owner sobre os itens que seriam inseridos no
relatório final (memorial de cálculo) e como os diagramas de esforços deveriam ser
exibidos. Ao final, o time de desenvolvimento, baseado em experiencias anteriores,
estabeleceu em comum acordo que essa Sprint duraria três semanas.
Após argumentação feita juntamente com o PO a equipe decidiu os itens do Product

Backlog desta Sprint
Quadro 02 – Tabela elencando a Sprint 02
T-01 Estimativa: 5 hrs

Nemenclatura das variaveis existentes no relatorio
Descrição grafica das caracteristicas dos materiais existentes no relatorio
Descrição grafica das caracteristicas geometricas da laje
Descrição grafica dos esforços solicitantes na laje (momento fletor positivo na direção x-x)
Descrição grafica dos esforços solicitantes na laje (momento fletor negativo na direção x-x)
Descrição grafica dos esforços solicitantes na laje (momento fletor positivo na direção y-y)
Descrição grafica dos esforços solicitantes na laje (momento fletor negativo na direção y-y)
Descrição do dimensionamento dos esforços solicitantes na laje (momento fletor positivo na direção x-x)
Descrição do dimensionamento dos esforços solicitantes na laje (momento fletor negativo na direção x-x)
Descrição do dimensionamento dos esforços solicitantes na laje (momento fletor positivo na direção y-y)
Descrição do dimensionamento dos esforços solicitantes na laje (momento fletor negativo na direção y-y)
Descrição grafica da armadura de calculo na laje (momento fletor positivo na direção x-x)
Descrição grafica da armadura de calculo na laje (momento fletor negativo na direção x-x)
Descrição grafica da armadura de calculo na laje (momento fletor positivo na direção y-y)
Descrição grafica da armadura de calculo na laje (momento fletor negativo na direção y-y)

Após Expor as tarefas no quadro 02 a equipe fez a classificação de a cordo
com o tamanho da tarefa dividido em três categorias; Pequeno, Médio e Grande
(conforme legenda do quadro 02).
A estimativa defendida no quadro 02 (138hrs) para a História de usuário –

“Saída de dados” obtidas, em comum acordo, vão compor o acompanhamento
através do gráfico de Burndown que servirá para a verificação da evolução da sprint.
Daily Meeting
O Daily Meeting era realizado todos os dias ao final da tarde (pouco antes do
time de desenvolvimento se preparar para sair) esse horário era o melhor horário
para a participação do Product Owner que fazia questão de estar presente. Essa
reunião não passava de 10 minutos diários.
Monitoração do Fluxo de trabalho
Para o monitoramento da sprint, foi estabelecido o gráfico de burndown que

possibilitou a verificação da quantidade de trabalho restante ao longo do tempo
podendo determinar se a Sprint estava indo pelo caminho certo ou se haviam
adesivos no curso do desenvolvimento. A figura 4 apresenta o andamento dia a dia
das tarefas através do gráfico de Burndown.
Quadro 03 – Tabela elencando o trabalho planejado para a Sprint 02

Planejado
Tarefa Dia 01 Dia 02 Dia 03 Dia 04 Dia 05 Dia 06 Dia 07 Dia 08 Dia 09 Dia 10 Dia 11 Dia 12 Dia 13 Dia 14 Dia 15
T-01 5 0 0 0 0 0 0 0 0 0 0 0 0 0 0
T-02 3 0 0 0 0 0 0 0 0 0 0 0 0 0 0
T-03 6 5 1 0 0 0 0 0 0 0 0 0 0 0 0
T-04 8 8 3 0 0 0 0 0 0 0 0 0 0 0 0
T-05 8 8 8 3 0 0 0 0 0 0 0 0 0 0 0
T-06 8 8 8 8 3 0 0 0 0 0 0 0 0 0 0
T-07 8 8 8 8 7 1 0 0 0 0 0 0 0 0 0
T-08 9 9 9 9 9 9 1 0 0 0 0 0 0 0 0
T-09 9 9 9 9 9 9 9 1 0 0 0 0 0 0 0
T-10 9 9 9 9 9 9 9 9 3 0 0 0 0 0 0
T-11 9 9 9 9 9 9 9 9 9 6 0 0 0 0 0
T-12 14 14 14 14 14 14 14 14 14 14 8 0 0 0 0
T-13 14 14 14 14 14 14 14 14 14 14 14 3 0 0 0
T-14 14 14 14 14 14 14 14 14 14 14 14 14 2 0 0
T-15 14 14 14 14 14 14 14 14 14 14 14 14 14 9 0
Planejado 138 129 120 111 102 93 84 75 68 62 50 31 16 9 0

Quadro 04 – Tabela elencando o trabalho executado para a Sprint 02
Planejado
Tarefa Dia 01 Dia 02 Dia 03 Dia 04 Dia 05 Dia 06 Dia 07 Dia 08 Dia 09 Dia 10 Dia 11 Dia 12 Dia 13 Dia 14 Dia 15
T-01 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
T-02 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
T-03 5 3 0 0 0 0 0 0 0 0 0 0 0 0 0
T-04 8 8 6 3 0 0 0 0 0 0 0 0 0 0 0
T-05 8 8 8 8 0 0 0 0 0 0 0 0 0 0 0
T-06 8 8 8 8 1 0 0 0 0 0 0 0 0 0 0
T-07 8 8 8 8 8 0 0 0 0 0 0 0 0 0 0
T-08 9 9 9 9 9 7 6 4 0 0 0 0 0 0 0
T-09 9 9 9 9 9 9 9 9 0 0 0 0 0 0 0
T-10 9 9 9 9 9 9 9 9 9 0 0 0 0 0 0
T-11 9 9 9 9 9 9 9 9 9 0 0 0 0 0 0
T-12 14 14 14 14 14 14 14 14 14 10 8 8 0 0 0
T-13 14 14 14 14 14 14 14 14 14 14 14 14 0 0 0
T-14 14 14 14 14 14 14 14 14 14 14 14 14 0 0 0
T-15 14 14 14 14 14 14 14 14 14 14 14 14 14 0 0
Actual 129 127 122 119 101 90 89 87 74 52 50 50 14 0 0
Figura 04 – Gráfico de burndown Para a Sprint 02
Sprint 02
140
130 Ponto 01
120
110
100 Ponto 02
Trabalho Restante
90
80
70
60 Ponto 03
50
40
30
20
10
0
Dias da Sprint
Planejado Actual
Nota-se que nos pontos 01, 02 e 03 houve um atraso no desenvolvimento dos

trabalhos, no entanto foram compensados logo a seguir por se tratar de uma tarefa
repetitiva e que poria se aproveitar parte do código T-04 era aproveitado para T-05 a
T7, T-08 era aproveitado para T-09 a T11 e T-12 era aproveitado para T-13 a T15.
Não foi necessária nenhuma mudança na Sprint em questão.

Definition of Done
Para a finalização da Sprint foram revistos todos os itens devidamente

testados.
A seguir mostra-se o resultado da Sprint
 Item T-01 Nomenclatura das variáveis existentes no relatório
Figura 05 – Nomenclatura exibida no relatório final
1.1.1 Características geométricas da laje

bw : largura da seção do elemento;
h : espessura da parede;
k . fck / γc (MPa)
Ac : área da seção;
I : momento de inércia da seção;
I2 : momento de inércia da seção (Estádio II).
 Item T-02 Descrição gráfica das características dos materiais

existentes no relatório
Figura 06 – Gráfico do material empregado no relatorio

0.00
-0.50
-1.00
-1.50
-2.00
-2.50
-3.00
(C30-k=0.85) -3.50
-20.0
-18.0
-16.0
-14.0
-12.0
-10.0
-8.0
-6.0
-4.0
-2.0
0.0
Deformação ξ(‰)

850
 Item T-03 Descrição gráfica das características geométricas da laje
Figura 07 – Geometria da laje exibida no relatório final

850
X
850
 Item T-04 a T-07 Descrição gráfica dos esforços solicitantes na laje
Figura 08 – Gráfico de esforço solicitante exibido no relatório final

.
1.4.1 Mxx,pos / Momento fletor longitudinal positivo (kN m/m)
0.0
19.7 39.4 59.0 78.7 98.4 118.1 137.8 1

 Item T-08 a T-11 Descrição do dimensionamento dos esforços
solicitantes na laje
Figura 09 – descrição dos procedimentos de cálculo exibido no relatório final

72.0
6.0
1.5 DIMENSIONAMENTO E VERIFICAÇÃO DAS SEÇÕES PARA MOMENTO FLETOR TRANSVERSAL POSITIVO
1.5.1 Elemento na coordenada (x,y) = (3.75m , 0.25m)
78
- Croqui da seção
Moldado in loco:
Armação passiva: ϕ 20.0
100
Considerações da geometria da seção
Largura da seção / Altura da seção:
- Procedimento
bw = 1.00de
m cálculo
/ h = 0.78 m
Altura útil da armação passiva:
ds = 0.720 m
Determinação do momento fletor de cálculo
Cálculo do momento fletor mínimo (item 17.3.5.2.1 da NBR-6118):
3
Md,mín = 0.8 ∙ W0 ∙ fctk,sup = 0.8 ∙ 0.1014 m ∙ 3.8 MPa = 306 kN∙m
Comparação entre momento fletor mínimo e momento atuante
Como |Md| = |1032 kN∙m| ≥ Md,mín = 306 kN∙m, tem-se:
Md = 1032 kN∙m
Determinação e solução das equações de equilíbrio
0.85 ∙ fck
Força resultante de compressão no concreto: Rc = ∙ bw ∙ y
γc
Admitindo a seguinte equação de equilíbrio: Mres = Md
Tem-se: Rc = 1522 kN / y = 0.08 m
Posição da linha neutra: x = 1.25 ∙ y = 1.25 ∙ 0.08 m = 0.10 m
Deformação do concreto e alongamento do aço
x
Como ≤ 0.35, tem-se:
ds − x
εs = 0.0100
x 0.10 m
εc = ∙ε = ∙ 0.0100 = 0.0017
ds − x p 0.720 m − 0.10 m
Domínio de ruptura: 2
Cálculo da armação passiva
Através do gráfico presente no item 1.2.1 tem-se: σs = 435 MPa
Força resultante de tração na armação passiva: Rs = Rc = 1522 kN
Rs 1522 kN 2
Área da armação passiva de tração: As == = 35.0 cm
σs 435 MPa
Comparação de armação mínima e armação calculada
Cálculo da armação mínima:
ρmín = 0.15 % (item 17.3.5.2.1 da NBR-6118)
2 2
As,mín = ρmín ∙ Ac = 0.15 % ∙ 7800 cm = 11.7 cm
Definição da armação necessária
2 2 2
Como A s = 35.0 cm ≥ A s,mín = 11.7 cm , tem-se: As = 35.0 cm
Sendo bw = 1.00 m, a armação em uma faixa de 1.0m é dada por:
As 35.0 cm2 2
As = = = 35.0cm /m
bw 1.00 m

 Item T-12 a T-15 Descrição gráfica da armadura de cálculo na laje
(momento fletor positivo na direção x-x)
Figura 10 – diagrama da armadura exibido no relatório final
1.5.2 Diagrama dos resultados obtidos no dimensionamento

O dimensionamento da armação foi feita para todas as seções conforme procedimento exibido anteriormente.
O valor numérico presente no diagrama seguinte em cada elemento corresponde a armação necessária, de acordo
2
com o cálculo anteriormente exibido (valores expressos em cm /m).
35.0
1
0.0 3.5 7.0 10.5 14.0 17.5 21.0 24.5 28.0 31.5 35.0
Sprint Review
Na realização da Sprint Review estavam presentes o Team o PO e o Diretor

da empresa (cliente). Após apresentação do programa funcionando o cliente ficou
completamente satisfeito com o resultado não sugerindo nenhuma adequação.
Para o acompanhamento da Sprint utilizou-se o gráfico de burndown (figura

04) que demonstrou pequenos atrasos seguidos de um adiantamento de alguns
itens, mas nada que comprometesse o projeto que terminou no prazo correto.
Sprint Retrospective
Na Sprint Retrospective ressaltou-se que a utilização do gráfico de burndown

ajudou no controle do tempo e que foi possível prever que, tarefas futuras, poderiam
ter atrasos seguidos de uma retomada do calendário.
3 Parecer final
Após este estudo de caso nota-se que se bem implementado, a abordagem
de princípios ágeis (Scrum), pode colaborar de forma positiva em vários tamanhos
de projetos inclusive projetos pequenos e com equipe reduzida como foi o caso
deste estudo.
Em linhas gerais, este trabalho atingiu os objetivos propostos, uma vez que
demonstrou a eficácia da utilização do framework Scrum no cenário utilizado.
4 Referências
SCHWABER, Ken et al. O Guia Definitivo para o Scrum: As Regras do Jogo.

[eBook]. Texas: OOPSLA, 2020.

Trabalho Scrum

Enviado por

Direitos autorais:

Formatos disponíveis

Trabalho Scrum

Enviado por

Dados do documento

Descrição original:

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Trabalho Scrum

Enviado por

Direitos autorais:

Formatos disponíveis

UNIVERSIDADE MUNICIPAL DE SÃO CAETANO DO SUL – USCS

MBA em GESTÃO DE PROJETOS

Leandro Simonete Pansan Granço

Julio Pedro de Siqueira Junior

São Caetano do Sul

MBA em GESTÃO DE PROJETOS

Leandro Simonete Pansan Granço

Trabalho apresentado à disciplina ‘Gestão

São Caetano do Sul - SP

2 Descrição do cliente, da empresa e do produto

Descrição do cliente, da empresa e do produto

Todo o projeto foi executado com uma equipe especializada da própria

De forma sucinta, o diretor da empresa necessitava de uma ferramenta

Após o levantamento das regras e necessidades do produto formulou-se o

Descrição dos requisitos Funcionais

Fonte: Elaborado pelo Autor, 2021

Por meio da entrevista com o diretor foi constatado o seguinte ator:

 Engenheiro de projetos: é ele quem desenvolve o modelo de cálculo,

Segundo Ken (2020, p. 12) “O Product Backlog é uma lista ordenada e

 História de usuário - Entrada de dados:

→Eu como engenheiro de projetos, gostaria de entrar com as características do

-Deve ser possível incluir o modulo de elasticidade do material utilizado;

-Deve ser possível incluir o diagrama de tensão deformação do material utilizado.

→Eu como engenheiro de projetos, gostaria de entrar com os esforços solicitantes

 História de usuário - Saída de dados:

→Eu como engenheiro de projetos, gostaria de receber um relatório com o completo

-Deve ser possível visualizar uma planta da estrutura;

-Deve ser possível visualizar o diagrama tensão deformação dos materiais;

-Deve ser possível visualizar o completo dimensionamento da estrutura incluindo as

Toadas a histórias foram validadas junto ao diretor da empresa

A definição do time Scrum ficou da seguinte forma:

O gerente de projetos de infraestrutura da empresa assumiu a posição de

O engenheiro de projetos da empresa assumiu a posição de Scrum Master.

O engenheiro de desenvolvimento da empresa assumiu a posição de Team.

Definição das Sprints

Para o desenvolvimento das atividades elencadas no backlog foram

Para a Sprint 01 foi elencada a funcionalidade onde a ferramenta recebe os

Para a Sprint 02 foi elencada a funcionalidade onde a ferramenta já possui os

Fonte: Elaborado pelo Autor, 2021

Figura 02 – Entrada de dados referente a geometria

Fonte: Elaborado pelo Autor, 2021

Figura 03 – Entrada de dados referente aos esforços

Fonte: Elaborado pelo Autor, 2021

Segundo Ken (2020, p. 9) “A Sprint Planning inicia a Sprint ao definir o

O Product Owner (PO) propõe desenvolver a Sprint 02 a fim de aumentar sua

Na reunião que durou cerca de 6hrs, os integrantes do Scrum Team se

Após argumentação feita juntamente com o PO a equipe decidiu os itens do Product

Quadro 02 – Tabela elencando a Sprint 02

T-01 Estimativa: 5 hrs

Fonte: Elaborado pelo Autor, 2021

A estimativa defendida no quadro 02 (138hrs) para a História de usuário –

Monitoração do Fluxo de trabalho

Para o monitoramento da sprint, foi estabelecido o gráfico de burndown que

Quadro 03 – Tabela elencando o trabalho planejado para a Sprint 02

Fonte: Elaborado pelo Autor, 2021

Fonte: Elaborado pelo Autor, 2021

Figura 04 – Gráfico de burndown Para a Sprint 02

Fonte: Elaborado pelo Autor, 2021

Nota-se que nos pontos 01, 02 e 03 houve um atraso no desenvolvimento dos